JP2018512085A - データの所有者によって、選択された受信者のための許可を制御するシステムおよび方法 - Google Patents

データの所有者によって、選択された受信者のための許可を制御するシステムおよび方法 Download PDF

Info

Publication number
JP2018512085A
JP2018512085A JP2017540641A JP2017540641A JP2018512085A JP 2018512085 A JP2018512085 A JP 2018512085A JP 2017540641 A JP2017540641 A JP 2017540641A JP 2017540641 A JP2017540641 A JP 2017540641A JP 2018512085 A JP2018512085 A JP 2018512085A
Authority
JP
Japan
Prior art keywords
data
owner
organization
permissions
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
JP2017540641A
Other languages
English (en)
Other versions
JP2018512085A5 (ja
Inventor
サンダース、カーク、エル．
マクドナルド、ハミッシュ、エス．
ディキソン、リャン、エヌ．
ボクホーベン、マイケル バン
ボクホーベン、マイケル バン
Original Assignee
ザ ダイアリー コーポレーション
ザ ダイアリー コーポレーション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ザ ダイアリー コーポレーション, ザ ダイアリー コーポレーション filed Critical ザ ダイアリー コーポレーション
Publication of JP2018512085A publication Critical patent/JP2018512085A/ja
Publication of JP2018512085A5 publication Critical patent/JP2018512085A5/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/93—Document management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Z—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS, NOT OTHERWISE PROVIDED FOR
    • G16Z99/00—Subject matter not provided for in other main groups of this subclass
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Bioethics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Human Resources & Organizations (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

システム内のデータの所有者によって、選択された受信者に対する許可の付与を制御する方法が記載される。本方法は、データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、組織が有する許可を特定することと、少なくとも、所有者の各々からの招待、および組織の管理者に対する許可の対応する組み合わせを含む電子通信を送信することと、１つ以上の組織が定義したアクセスグループに対する所有者の各々の割り当てを受信することとを含む。本方法は、複数の役割に対する、選択されたスタッフメンバの割り当てを受信することと、特定の所有者および選択されたスタッフメンバを有する１つ以上のアクセスグループに従って、かつ選択されたスタッフを有する特定の所有者のための複数の役割に従って、所有者の各々のための選択されたスタッフメンバに特定の許可を付与することとを更に含む。【選択図】図１１

Description

本技術は、所有者のデータの共有を制御することに関し、特に、低レベルのデータ粒度で、選択された受信者に許可を与えることに関する。
医療記録および電子医療記録の分野は、広く実践されている。不都合なことに、この分野はまた、患者データが、手書きのメモおよびタイプ入力されたメモ、音声記録、および多様なコンピュータフォーマットを元にしており、極度に断片化されている。
医師および他のヘルスケアのプロは、データの複数のページを読み出し、何が生じているか、事象の順序、および薬または治療の変更を患者の生理学的測定値または症状に対する変更と相関付ける試行を頭の中で思い描くことを余儀なくされる。
現在の技術は、医師が、患者の関連データの時間的に相関した明確なビューを一目で見る方法を提供していない。
一般的に見られる問題は、時間の浪費、患者のチャートを読むのに必要な多大な専門知識およびトレーニング、および重傷または死亡を引き起こす間違いをあまりに頻繁に含む間違いである。
多数の健康情報技術ソフトウェアアプリケーションおよびプロジェクトによって、単に情報システムを調和させ融合させることは、必ずしも、臨床医および他のヘルスケアのプロおよびユーザによってアクセスされる情報の品質を改善するのに十分でないことが示されている。根本的問題は、患者のためのケアチーム全体が、大量のデータにアクセスする必要があるが、ほとんどの場合、データが要約され、より有用な形で提示されることを必要とすることである。データが適切に要約されず、容易に理解されない場合、ヘルスケアのプロは、これを効果的に利用することができない。
現行のシステムは、情報の全体像を誰も見ないようなものである。情報は多くの場所に多くの形態で散乱している。多くの場合、データへのアクセスまたはデータの共有を防ぐデータサイロが存在する。ヘルスケアフィールドにおいて、多くのヘルスケアシステムは他のヘルスケアシステムと通信しない。したがって、特に、データを所有しているとみなされ得る患者が、自身のデータにアクセスするのが困難である。更に、米国において、ＨＩＰＡＡに関係するプライバシー問題が存在する。別の現行の困難は、異なるケアエンティティが同じページ上にないことである。ケアチーム間に効果的な伝達が欠落している。従来の医療文化では、情報フローはトップダウンである。このため、患者は、依然として自身の健康ステータスを完全に理解せず、自身の健康状態の説明を効果的に他者に伝達することができない。望ましいのは、患者の健康状態の説明の正当な所有権が、消費者に属するシステムであり、この消費者は、次に、医者、専門家および病院にアクセスを付与することができる。
１つの態様では、少なくとも複数のコンピューティングデバイス、サーバ、ネットワークおよびデータベースを含むシステム内のデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、サーバにおいて、データベースの所有者の電子ダイアリ部分に記憶されたデータの所有者から電子認証を受信することと、サーバにおいて、所有者によって制御されるデータの特定のカテゴリにアクセスするように招待された１以上の所望の受信者の各々に対応する電子アドレスを受信することと、招待が受け入れられた場合、１以上の受信者が有することになる特定の許可を特定することであって、許可は１つ以上の特定のアクションを実行する能力を提供することと、コンピュータネットワークを介して、１以上の所望の受信者に電子通信を送信することであって、各電子通信は、通信に返答するのに用いるための一意のユニフォームリソースロケータを含むことと、コンピュータネットワークを介して、１以上の受信者の各々から招待の受入れまたは拒絶を含む電子メッセージを受信することと、所有者のデータに対する、所有者により制御された電子アクセスを容易にするために、データ構造内に、１以上の受信者の各々の識別子と、招待の受入れまたは拒絶のインジケータと、招待が受け入れられた場合、１以上の受信者の各々に付与される許可の対応する組み合わせとを記憶することとを含む、方法が存在する。
受信者のうちの１つが組織である場合、所有者および１人以上のスタッフメンバのための１つ以上の特定のアクセスグループと、１人以上のスタッフメンバのための１つ以上の役割と、特定の許可が付与されるデータの対応するカテゴリとを特定する１つ以上の電子メッセージを受信することができる。特定のスタッフメンバは、所有者およびスタッフメンバが共通のアクセスグループを共有する場合にのみ、ダイアリにアクセスすることができる。特定のスタッフメンバは、スタッフメンバが属する全ての役割からの累積的許可に基づいてダイアリにアクセスすることができる。特定の許可は、所有者のアカウントから組織に与えられる許可に制約することができる。役割は、組織が定義した許可の組み合わせとすることができる。アクセスグループは、スタッフおよび所有者をリンク付けするための組織が定義したグループとすることができる。
本方法は、所有者から、特定の受信者の合意なしで許可を追加または削除するための電子要求を受信することを更に含むことができる。本方法は、選択された受信者による付与された許可の使用を更に含み、これは、受信者のうちの特定の受信者から所有者データのグラフィカル表示のための要求を受信することと、特定の受信者のための累積的許可を決定することであって、特定の受信者が組織の一部である場合、決定することは、特定の受信者が所有者と共有されるアクセスグループに関連付けられているか否かを判断することを更に含むことと、所有者の電子ダイアリにおける累積的許可によって特定されるデータを取り出すことと、取り出されたデータのＨＴＭＬベースの画面表示を生成することとを含む。本方法は、ＨＴＭＬベースの画面表示を操作するために特定の受信者からナビゲーション要求を受信することを更に含むことができる。本方法は、ＨＴＭＬベースの画面表示を操作するために受信者のうちの特定の受信者からナビゲーション要求を受信することを更に含むことができる。画面表示は、受信者のうちの特定の受信者が許可を有するカテゴリのためのデータを含むことができ、画面表示は、受信者のうちの特定の受信者が許可を有していないカテゴリを示すことができる。ＨＴＭＬベースの画面表示を生成することは、累積的許可に対応する各カテゴリについて１つ以上の制御を適用することを含むことができ、各許可されたカテゴリのための制御は、他の許可されたカテゴリのための制御と独立することができる。ＨＴＭＬベースの画面表示を生成することは、単一のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのタイムラインビューを適用することを含むことができる。ＨＴＭＬベースの画面表示を生成することは、複数のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのタイムラインビューを適用することを含むことができる。所定のテンプレートのタイムラインビューが、ユーザに許可されていないカテゴリからのデータに対するアクセスを必要とする場合、ビューを表示しないことができ、ユーザが通知を受ける。本方法は、日、週、月または年、および集約レベル選択に対応する開始日または終了日からの集約レベル選択を含むタイムライン表示の要求を受信することと、受信した要求に従って２つの行部分を有するカレンダバーをレンダリングすることであって、最下行部分は、集約レベル選択に対応する開始日または終了日に従って日付を有する一連のブロックを表示し、最上行部分は、選択された集約レベルに一連のドットを表示し、ここで、明るいドットは、選択された集約レベルにおける期間にわたる所有者データの欠如を表し、暗いドットは、期間にわたる所有者データの存在を表すこととを更に含むことができる。カレンダバーの最上行部分は、最下行部分における日付に対応するドットにわたって強調されたブロックを更に表示することができ、カーソルが最上行部分の別の部分上をホバリングするように動かされる場合、ホバリングカーソルの位置に対応して別の強調されたブロックを表示することができ、ホバリングカーソルの位置においてクリックイベントが受信される場合、タイムラインが、クリックの日付に対応し、選択された集約レベルに従うデータを表示する。
データのカテゴリは、薬剤、運動、睡眠、病気、および性の健康を含むことができる。データのカテゴリは、医療記録、症状および／またはバイタルサイン、薬剤および／または実験結果、感情、ライフイベント、遺伝子マーカおよびライフスタイルを含むことができる。受信者は、ビジタ、スタッフメンバおよび所有者／ビジタのうちの１つとすることができる。ビジタは、読み出しおよび／または書き込み権限を有するゲスト、および／または完全な所有者権限を有する保護者のうちの一方とすることができる。スタッフメンバは組織に属するユーザとすることができる。所有者／ビジタは、ダイアリを有する所有者であり、かつ別の所有者のダイアリに対するアクセスも付与されている、ユーザとすることができる。許可ステータスは、取得、受信および受入れを含むことができる。許可の種類は、読み出し、書き込みおよびアクセスなしを含むことができる。本方法は、招待の受信した受入れまたは拒絶の確認またはキャンセルを含む電子メッセージを受信することを更に含むことができる。
別の態様では、少なくとも複数のコンピューティングデバイス、サーバおよびネットワークを含むシステム内のデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、組織が有する許可を特定することであって、許可は、１つ以上の特定のアクションを実行する能力を提供することと、コンピュータネットワークを介して、少なくとも、招待、組織の管理者に対する許可の組み合わせ、および電子通信に返答する際に用いるための一意のユニフォームリソースロケータを含む電子通信を送信することと、組織が定義したアクセスグループへの特定の所有者の割り当てを受信することと、アクセスグループに対する、特定の所有者および組織の１人以上の選択されたスタッフメンバのマッピングを受信して、特定の所有者および選択されたスタッフメンバをリンク付けすることと、組織のスタッフメンバに対応する少なくとも１つの役割の識別情報を受信することと、少なくとも１つの役割に対する、組織の１人以上の選択されたスタッフメンバの割り当てを受信することと、特定の所有者および選択されたスタッフメンバを有する特定のアクセスグループに従って、かつ選択されたスタッフを有する少なくとも１つの役割に従って、特定の所有者のための選択されたスタッフメンバに特定の許可を付与することと、所有者のデータに対する、所有者により制御される電子アクセスを容易にするために、データ構造内に、招待の受入れまたは拒絶のインジケータと、選択されたスタッフメンバの各々の識別子と、選択されたスタッフメンバの各々に付与された許可の対応する組み合わせとを記憶することとを含む、方法が存在する。
特定のスタッフメンバは、所有者およびスタッフメンバが共通アクセスグループを共有する場合にのみ所有者のダイアリにアクセスすることができる。特定のスタッフメンバは、スタッフメンバが属する全ての役割からの累積的許可に基づいて所有者のダイアリにアクセスすることができる。特定の許可は、所有者のアカウントから組織に与えられる許可に制約することができる。役割は、組織が定義した許可の組み合わせとすることができる。
本方法は、選択されたスタッフメンバによる付与された許可の使用を更に含むことができ、これは、スタッフメンバのうちの特定のスタッフメンバから所有者データのグラフィカル表示のための要求を受信することと、特定のスタッフメンバのための累積的許可を決定することであって、特定のスタッフメンバが所有者と共有されるアクセスグループに関連付けられているか否かを判断することを更に含むことと、所有者の電子ダイアリにおける累積的許可によって特定されるデータを取り出すことと、取り出されたデータのＨＴＭＬベースの画面表示を生成することとを含む。本方法は、特定のスタッフメンバから、ＨＴＭＬベースの画面表示を操作するためのナビゲーション要求を受信することを更に含むことができる。スタッフメンバは、医師、看護師、技術者、薬剤師および管理者のうちの１つを含む、組織に属するユーザとすることができる。許可の種類は、読み出し、書き込みおよびアクセスなしを含むことができる。役割は、対応するスタッフメンバがアクセスを有する選択されたデータのカテゴリを更に含み、データのカテゴリは、医療記録、症状および／またはバイタルサイン、薬剤および／または実験結果、感情、ライフイベント、遺伝子マーカおよびライフスタイルを含むことができる。
別の態様では、少なくとも複数のコンピューティングデバイス、サーバおよびネットワークを含むシステム内の所有者ダイアリ内に配列されたデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、組織が有する許可を特定することであって、許可は、１つ以上の特定のアクションを実行する能力を提供することと、コンピュータネットワークを介して、少なくとも、所有者の各々からの招待、および組織の管理者に対する許可の対応する組み合わせを含む電子通信を送信することであって、各電子通信は、通信に返答する際に用いるための一意のユニフォームリソースロケータを含むことと、１つ以上の組織が定義したアクセスグループへの所有者の各々の割り当てを受信することと、１つ以上のアクセスグループに対する、特定の所有者および組織の１人以上の選択されたスタッフメンバのマッピングを受信して、特定の所有者および選択されたスタッフメンバをリンク付けすることと、組織のスタッフメンバに対応する少なくとも１つの役割の識別情報を受信することと、少なくとも１つの役割に対する、組織の１人以上の選択されたスタッフメンバの割り当てを受信することと、特定の所有者および選択されたスタッフメンバを有する１つ以上のアクセスグループに従って、かつ選択されたスタッフを有する特定の所有者のための少なくとも１つの役割に従って、所有者の各々のための選択されたスタッフメンバに特定の許可を付与することと、各所有者のデータに対する、所有者により制御される電子アクセスを容易にするために、データ構造内に、所有者の各々のための招待の受入れまたは拒絶のインジケータと、選択されたスタッフメンバの各々の識別子と、各所有者のための選択されたスタッフメンバの各々に付与された許可の対応する組み合わせとを記憶することとを含む、方法が存在する。
特定のスタッフメンバは、対応する特定の所有者およびスタッフメンバが共通アクセスグループを共有する場合にのみ特定のダイアリにアクセスすることができる。特定のスタッフメンバは、スタッフメンバが属する全ての役割からの累積的許可に基づいて所有者のダイアリにアクセスすることができる。特定の許可は、対応する所有者のアカウントから組織に与えられる許可に制約することができる。役割は、組織が定義した許可の組み合わせとすることができる。
本方法は、選択されたスタッフメンバによる付与された許可の使用を更に含むことができ、これは、スタッフメンバのうちの特定のスタッフメンバから特定の所有者のデータのグラフィカル表示のための要求を受信することであって、データは複数のカテゴリ間でグループ化されることと、特定のスタッフメンバが特定の所有者と共有されるアクセスグループに関連付けられているか否かを判断することと、特定のスタッフメンバが特定の所有者と共有されるアクセスグループに関連付けられている場合、特定のスタッフメンバのための役割から累積的許可を決定することと、組織が所有者によって累積的許可のうちのいずれを与えられたかを判断することと、特定の所有者の電子ダイアリにおける累積的許可によって特定されるデータを取り出すことと、取り出されたデータのＨＴＭＬベースの画面表示を生成することとを含む。本方法は、特定のスタッフメンバから、ＨＴＭＬベースの画面表示を操作するためのナビゲーション要求を受信することを更に含むことができる。画面表示は、特定のスタッフメンバが許可を有するカテゴリのためのデータを含むことができ、画面表示は、特定のスタッフメンバが許可を有していないカテゴリを示すことができる。スタッフメンバは、医師、看護師、技術者、薬剤師および管理者のうちの１つを含む、組織に属するユーザとすることができる。
許可の種類は、読み出し、書き込みおよびアクセスなしを含むことができる。役割には、対応するスタッフメンバがアクセスを有するデータのカテゴリを関連付けることができ、データのカテゴリは、医療記録、症状および／またはバイタルサイン、薬剤および／または実験結果、感情、ライフイベント、遺伝子マーカおよびライフスタイルを含むことができる。役割には、対応するスタッフメンバがアクセスを有するデータのカテゴリを関連付けることができ、データのカテゴリは、身体測定値、臨床メモ、ダイアリメモ、飲酒、環境、気分、予防接種、実験結果、ライフイベント、薬剤、気分、栄養、痛み、患者ストレス、物理的アクティビティ、睡眠、喫煙、症状、治療およびバイタルサインを含むことができる。ＨＴＭＬベースの画面表示を生成することは、付与された許可に対応する各カテゴリについて１つ以上の制御を適用することを含み、各許可されたカテゴリのための制御は、他の許可されたカテゴリのための制御と独立している。制御は、取り出されたデータのソート、閲覧、色分けおよびフィルタリングの選択を含むことができる。制御は、取り出されたデータを表示するためのリストフォーマットおよびグラフィカルフォーマットを含むことができる。ＨＴＭＬベースの画面表示を生成することは、単一のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのライムラインビューを適用することを含むことができる。ＨＴＭＬベースの画面表示を生成することは、複数のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのタイムラインビューを適用することを含むことができる。所定のテンプレートのタイムラインビューが、ユーザに許可されていないカテゴリからのデータに対するアクセスを必要とする場合、ビューを表示しないことができ、ユーザが通知を受けることができる。
本方法は、所有者のデータにアクセスする人物、各人物によってとられるアクション、ダイアリに対する変更または追加が存在する場合、それらのタイムスタンプを付されたログを生成することを更に含むことができる。
本方法は、特定の所有者に対応するソース文書をスキャンすることと、スキャンされた文書から、ソース文書への参照を含む医療データを抽出することと、ソース文書を電子ストレージに記憶することと、抽出された医療データおよびソース文書への参照を、抽出されたデータのカテゴリに基づいて特定のダイアリに記憶することであって、記憶された参照は、ユーザが抽出されたデータを閲覧してソース文書にナビゲートし、ソース文書を閲覧することを可能にすることとを更に含むことができる。ソース文書は、特定のウェブページの解像度で記憶することができる。抽出されたデータは、タイムライン上で、またはデータの他の表示ページ上で閲覧することができる。
本方法は、特定のダイアリのための選択されたカテゴリにおけるデータアイテムの選択を受信することと、選択されたカテゴリにおける制御を起動して、ソース文書リンクプロセスを開始することと、電子ストレージへのユーザインターフェースを表示することと、データアイテムにリンクされるソース文書のインターフェースの使用による選択を受信することと、データアイテムのためのリンクを特定のダイアリに記録することとを更に含むことができる。
データのカテゴリは、臨床データ、ライフスタイルデータ、心理社会的データ、環境データおよび遺伝データを含むことができる。
更に別の実施形態では、少なくとも複数のコンピューティングデバイス、サーバおよびネットワークを含むシステム内のデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、組織が有する許可を特定することであって、許可は、１つ以上の特定のアクションを実行する能力を提供することと、コンピュータネットワークを介して、少なくとも、招待、組織の管理者に対する許可の組み合わせ、および電子通信に返答する際に用いるための一意のユニフォームリソースロケータを含む電子通信を送信することと、組織が定義したアクセスグループへの特定の所有者の割り当てを受信することと、アクセスグループに対する、特定の所有者および組織の１人以上の選択されたスタッフメンバのマッピングを受信して、特定の所有者および選択されたスタッフメンバをリンク付けすることと、少なくとも１つの組織の役割に対する、組織の１人以上の選択されたスタッフメンバの割り当てを受信することと、特定の所有者および選択されたスタッフメンバを有する特定のアクセスグループに従って、かつ選択されたスタッフを有する少なくとも１つの役割に従って、特定の所有者のための選択されたスタッフメンバに特定の許可を付与することと、データ構造内に、招待の受入れまたは拒絶のインジケータと、選択されたスタッフメンバの各々の識別子と、選択されたスタッフメンバの各々に付与された許可の対応する組み合わせとを記憶することと、対応する付与された書き込み許可を有する第１のユーザから所有者のデータまたは新たなデータに対する編集を受信することと、第１のユーザのアイデンティティ、編集または新たなデータの時刻および日付、更新されたタイプまたはカテゴリ、およびデータベース内の編集または新たなデータを追跡することと、更新された所有者のデータのためのバージョン識別子を変更することとを含む、方法が存在する。
本方法は、所有者のデータが、第１のユーザによってフェッチされてから第２のユーザによって変更されたか否かを判断することと、更新が否認されたことを第１のユーザに通知することとを更に含むことができる。所有者のデータが、フェッチされてから変更されたか否かを判断することは、変更されたエントリが最新バージョンであるか否かを判断することを含むことができる。所有者のデータは、医療データまたは健康関連データとすることができる。更新は、変更されたバージョン識別子を有する所有者のデータにアクセスするために対応する付与された許可を有する各後続のユーザに可視とすることができる。
本方法は、編集された所有者のデータの以前のバージョンのための変更履歴を、編集されたデータに対応するデータのカテゴリのための適切な読み出し許可を有するユーザに対し表示することを更に含むことができる。
別の態様では、データの所有者によって、選択された受信者に対する許可の付与を制御するためのシステムであって、少なくとも複数のクライアントコンピューティングデバイス、サーバ、およびデータベースを含み、サーバにおいて、データベースの所有者の電子ダイアリ部分に記憶されたデータの所有者に対応するクライアントコンピューティングデバイスから電子認証を受信する手段と、サーバにおいて、所有者によって制御されるデータの特定のカテゴリにアクセスするように招待された１以上の所望の受信者クライアントコンピューティングデバイスの各々に対応する電子アドレスを受信する手段と、招待が受け入れられた場合、１以上の受信者が有することになる特定の許可を特定する手段であって、許可は１つ以上の特定のアクションを実行する能力を提供する、手段と、１以上の所望の受信者クライアントコンピューティングデバイスに電子通信を送信する手段であって、各電子通信は、通信に返答するのに用いるための一意のユニフォームリソースロケータを含む、手段と、１以上の受信者クライアントコンピューティングデバイスの各々から招待の受入れまたは拒絶を含む電子メッセージを受信する手段と、所有者のデータに対する、所有者により制御された電子アクセスを容易にするために、１以上の受信者の各々の識別子と、招待の受入れまたは拒絶のインジケータと、招待が受け入れられた場合、１以上の受信者の各々に付与される許可の対応する組み合わせとを記憶する手段とを備える、システムが存在する。
データの特定の所有者は、特定の所有者に対応する複数のクライアントコンピューティングデバイスを有することができる。
別の態様では、所有者ダイアリ内に配列されたデータの所有者によって、選択された受信者に対する許可の付与を制御するためのシステムであって、少なくとも複数のクライアントコンピューティングデバイスおよびサーバを含み、データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、組織が有する許可を特定する手段であって、許可は、１つ以上の特定のアクションを実行する能力を提供する、手段と、少なくとも、所有者の各々に対応するクライアントコンピューティングデバイスからの招待、および組織の管理者に対する許可の対応する組み合わせを含む電子通信を送信する手段であって、各電子通信は、通信に返答する際に用いるための一意のユニフォームリソースロケータを含む、手段と、１つ以上の組織が定義したアクセスグループへの所有者の各々の割り当てを受信する手段と、１つ以上のアクセスグループに対する、特定の所有者および組織の１人以上の選択されたスタッフメンバのマッピングを受信して、特定の所有者および選択されたスタッフメンバをリンク付けする手段と、組織のスタッフメンバに対応する少なくとも１つの役割の識別情報を受信する手段と、少なくとも１つの役割に対する、組織の１人以上の選択されたスタッフメンバの割り当てを受信する手段と、特定の所有者および選択されたスタッフメンバを有する１つ以上のアクセスグループに従って、かつ選択されたスタッフを有する特定の所有者のための少なくとも１つの役割に従って、所有者の各々のための選択されたスタッフメンバに特定の許可を付与する手段と、各所有者のデータに対する、所有者により制御される電子アクセスを容易にするために、所有者の各々のための招待の受入れまたは拒絶のインジケータ、選択されたスタッフメンバの各々の識別子、および各所有者のための選択されたスタッフメンバの各々に付与された許可の対応する組み合わせを記憶する手段とを備える、システムが存在する。
データの特定の所有者は、特定の所有者に対応する複数のクライアントコンピューティングデバイスを有することができる。
いくつかの実施形態では、データの所有者はヘルスケア患者であり得る。したがって、図面が患者を指す場合、これは所有者のインスタンスを示す。
Ｌｉｆｅｔｉｍｅ Ｈｅａｌｔｈ Ｄｉａｒｙを作成し、維持し、利用するためのシステムツールの実施形態の例の図である。
図１に示すＬｉｆｅｔｉｍｅ Ｈｅａｌｔｈ Ｄｉａｒｙツールのシステム構成の実施形態の例の図である。
図２Ａに示される電子ストレージの実施形態の例の図である。
図２Ｂに示すデータボルトデータベース、コアデータベースおよびデータボルト文書ストレージ間のインタラクションの実施形態の例の図である。
特定の患者のための医療情報を処理する実施形態の例の図である。
図３に示すデータソースおよび構造化部分の実施形態の例の図である。
ダイアリのための許可を導入する図である。
患者アカウントから、所有者／ビジタ、ゲスト、および組織のスタッフメンバに与えられる許可を示す図である。
許可を与えられ得る例示的な関係者を示す図である。
許可を与えるための組織概念を示す図である。
スタッフメンバと役割との間の関係を示す図である。
スタッフメンバ、アクセスグループおよび所有者間の関係を示す図である。
所有者のアカウントへのスタッフメンバのアクセスを示す図である。
招待プロセスの実施形態の概観を示す図である。
紙文書を処理する実施形態を示すフローチャートである。
文書をリンク付けする実施形態を示すフローチャートである。
データボルトへのアクセスを示す画面表示の例である。
データボルトのためのアップロード画面を示す画面表示の例である。
データボルトのためのユーザオプションを示す画面表示の例である。
所有者とゲストとの間の招待フローを示す図である。
ゲストを招待するためのプロセスの実施形態を示すフローチャートである。
招待に返答するためのプロセスの実施形態を示すフローチャートである。
所有者が組織を招待するためのプロセスの実施形態を示すフローチャートである。
ダイアリにアクセスを付与するためのプロセスの実施形態を示すフローチャートである。
現在の招待の閲覧および招待プロセスにおいて行われる新たな招待のための画面を示す画面表示の例である。
ゲストに関する情報およびゲストに付与する許可を入力するためのインターフェース画面を示す画面表示の例である。
電子メールで送信された例示的な招待を示す画面表示の例である。
図２３の表示を用いること等により取り出された招待の詳細を示す画面表示の例である。
完了した招待を所有者およびゲストが見ることができる招待完了画面を示す画面表示の例である。
所有者のアカウントにおけるゲストによる活動の監査を示す画面表示の例である。
特定のゲストに対し、所有者のダイアリへのアクセスを与えた所有者のサマリを示す画面表示の例である。
ユーザ（例えば、所有者）がゲストに割り当てられた許可を更新することを望むときにそのユーザが見るインターフェース画面を示す画面表示の例である。
ユーザ（例えば、所有者）が組織における役割に許可を割り当てることを望むときにそのユーザが見るインターフェース画面を示す画面表示の例である。
組織の管理者が組織における役割を管理することを望むときにその管理者が見るインターフェース画面を示す画面表示の例である。
組織の管理者が組織における役割を作成することを望むときにその管理者が見るインターフェース画面を示す画面表示の例である。
組織における対応する役割に対し行うことができる動作の、組織の管理者が見るインターフェース画面を示す画面表示の例である。
スタッフメンバを管理する際に組織の管理者が見るインターフェース画面を示す画面表示の例である。
組織の役割のための役割許可を管理するために組織の管理者が見るインターフェース画面を示す画面表示の例である。
ダイアリアクセスの役割のための役割許可を管理するために組織の管理者が見るインターフェース画面を示す画面表示の例である。
所有者グループを管理するために組織の管理者が見るインターフェース画面を示す画面表示の例である。
新たなグループの名称および説明を入力するために組織の管理者が見る画面を示す画面表示の例である。
対応するグループに対し行うことができる動作を表示するために組織の管理者が見るインターフェース画面を示す画面表示の例である。
対応するグループの所有者を選択するために組織の管理者が見るインターフェースを示す画面表示の例である。
対応するグループのスタッフメンバを選択するために組織の管理者が見るインターフェースを示す画面表示の例である。
対応するグループの名称および説明を編集するために組織の管理者が見るインターフェースを示す画面表示の例である。
ユーザインターフェース要素がレンダリングされるか否かを判断するためのプロセスの実施形態を示すフローチャートである。
特定のスタッフメンバがアクセスを有するか否かを許可に基づいて判断するためのプロセスの実施形態を示すフローチャートである。
特定のゲストがアクセスを有するか否かを許可に基づいて判断するためのプロセスの実施形態を示すフローチャートである。
示されるようにいくつかの許可を設定した所有者が見るインターフェース画面を示す画面表示の例である。
所有者がプラスアイコンをクリックして、いずれのモジュールにデータを追加することができるかを見るときに、データモジュールのリストを表示するためのインターフェースを示す画面表示の例である。
ゲストが図４８のダイアリについて同じアクションを実行するが、ゲストの許可が、ゲストが喫煙モジュールのデータを入力することしか可能にしないときに、関連アイテムに制約されるモジュールのリストを表示するためのインターフェースを示す画面表示の例である。
ゲストが閲覧許可を有するモジュールのみが選択可能である、ダイアリのゲストが見るパルスページのインターフェースを示す画面表示の例である。
選択されたが、許可制限に起因して全てのモジュールのためのデータを取り出すことができず、ある特定のデータがユーザに利用可能でないことをそのユーザに知らせる有意義なメッセージを表示する、タイムラインのためのインターフェース画面を示す画面表示の例である。
所有者のデータの時間ベースのサマリを示すタイムラインページのためのインターフェース画面を示す画面表示の例である。ユーザは、（ユーザが所有者でない場合、許可の下で）いずれのモジュールを閲覧するかを選択することができ、各モジュールは異なる制御を有することができる。
各モジュールのデータと共に機能するように用いることができる、そのモジュール用のページを表示するためのインターフェースを示す画面表示の例である。
所有者のタイムラインをナビゲートするためにユーザが見るインターフェース画面の一部分を示す画面表示の例である。
可能な集約レベルの例を示すタイムラインのためのインターフェース画面のカレンダバー部分を示す画面表示の例である。
週ごとの集約レベルでタイムラインデータマップの例を示す、タイムラインのためのインターフェース画面の一部分を示す画面表示の例である。
２つの制御部を有するリストビューを示す物理的アクティビティまたは運動履歴のための例示的なウィジェットのためのインターフェース画面を示す画面表示の例である。
選択された運動タイプを含む選択された制御に応答してグラフィカルデータビューを示す例示的なウィジェットのためのインターフェース画面を示す画面表示の例である。
全ての運動タイプを含む選択された制御に応答してグラフィカルデータビューを示す、例示的なウィジェットのためのインターフェース画面を示す画面表示の例である。
選択された制御に応答してリストビューを示すいくつかの例示的なウィジェットのためのインターフェース画面を示す画面表示の例であり、ここで、各ウィジェットは異なる制御を有することができる。
自身の健康状態フィードウィジェットのための例示的なウィジェット設定およびウィジェット表示と、物理的アクティビティウィジェットのための例示的なウィジェット設定および対応するウィジェット表示とのためのインターフェース画面を示す画面表示の例である。
薬剤服用ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
睡眠ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
気分ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
痛みウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
身体測定ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
バイタルウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
飲食物ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
アクセスウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。
編集およびバージョン追跡のためのプロセスの実施形態を示すフローチャートである。
＜序論＞
本明細書において以下に示すシステムおよび方法は、ハードウェアおよびソフトウェアの様々な構成において実施することができる。システムは、以下で論考されるような様々なモジュール、ツールおよびアプリケーションから構成することができる。当業者であれば理解することができるように、モジュールの各々は、様々なサブルーチン、プロシージャ、定義文およびマクロを含むことができる。モジュールの各々は、通常、別個にコンパイルされ、単一の実行可能プログラムになるようにリンクされる。したがって、モジュールの各々の以下の説明は、好ましいシステムの機能を説明する便宜上用いられる。このため、モジュールの各々によって行われるプロセスは、他のモジュールのうちの１つに任意に再分配される場合もあるし、共に単一のモジュールに組み合わされる場合もあるし、または、例えば、共有可能なダイナミックリンクライブラリにおいて利用可能にされる場合もある。
システムモジュール、ツールおよびアプリケーションは、例えば、Ｃ、Ｃ＋＋、Ｃ＃、ＢＡＳＩＣ、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐａｓｃａｌ、Ａｄａ、Ｊａｖａ（登録商標）、ＨＴＭＬ、ＸＭＬまたはＦＯＲＴＲＡＮ等の任意のプログラミング言語で書くことができ、Ｗｉｎｄｏｗｓ、Ｍａｃｉｎｔｏｓｈ、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（登録商標）、ＶｘＷｏｒｋｓまたは他のオペレーティングシステムの変形等のオペレーティングシステムにおいて実行することができる。Ｃ、Ｃ＋＋、Ｃ＃、ＢＡＳＩＣ、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐａｓｃａｌ、Ａｄａ、Ｊａｖａ（登録商標）、ＨＴＭＬ、ＸＭＬおよびＦＯＲＴＲＡＮは、産業標準プログラミング言語であり、これらのプログラミング言語のために多くの商用コンパイラを用いて実行可能コードを作成することができる。
＜定義＞
以下は、開示されるシステムおよび方法のいくつかの実施形態を説明する際に用いられる用語の複数の有用な可能な定義を提供する。
データ（単数形）：薬もしくは治療、症状、栄養、ライフスタイルもしくはライフスタイル変化、イベント、精神状態、または生理学的測定値もしくは状態のレコードであり、タイムスタンプ、シンボル、アイコン、またはイベントを記す他の手段を含み、加えて、患者の状態または背景情報に関する数値等のオプションフィールドを含む。
データ（複数形）：複数のデータ。
データソース：限定ではないが、ヘルスケアの専門家、患者、ソフトウェアプログラム、コンピュータファイルもしくはプログラム、医療機器、またはセンサ等を含むデータ入力を、限定ではないが、手書きのメモ、キーボードによるメモ、画像、オーディオまたはビデオ記録、電子ファイル等を含む任意のフォーマットで提供する任意の手段。
構造化：データを一貫性のある標準化されたレコードフォーマットに正規化する。
追跡：構造化データ内のタイムスタンプまたは他のフィールドを用いてデータ間の相関を見つけ、この相関に対し計算を行い、この相関に基づき、この相関をグラフィック表示する。
変数：臨床試験、治療の変更、薬剤の変更、または他の試験もしくは実験において、他のデータを（達成可能な限り）不変に保ちながら、慎重に変更されるデータ。
データシンボル：データを示すグラフィックアイコン、および、限定ではないが、タイムスタンプ、数値、価格等を含む、追加の情報のオプションのテキスト描写または他の描写。
タイムライン：複数の特定の種類のデータシンボルの、それらのタイムスタンプでソートされたグラフィック描写、または限定ではないが、薬剤または治療もしくはコード番号を含む他のフィールド。
インフォグラフィック：複数の患者から集約され、タイムスタンプによってソートされたデータに対応する、テーブル、チャート、マトリクス、もしくはデータシンボルの他の表現のグラフィック描写もしくはテキスト描写、または限定ではないが、年齢、性別、所在地、職業、ライフスタイル選択、ライフイベント、既往症を含む基礎をなす健康状態、遺伝的形質識別子、症状、治療、薬もしくはヘルスケア提供者等を含む他のフィールド。
レンダリング：各々が同じ開始時間および終了時間、ならびにタイムスケールを有する、複数のタイムラインまたはインフォグラフィックを表示する。
解析：相関関係または因果関係をより良好に理解するために、単数または複数のデータを、単独で、または別の単数もしくは複数のデータとの単数もしくは複数の相関において理解し検討するプロセス。
アラート：アラートは、リアルタイムリスク評価、重大イベント、リマインダー、コンプライアンスインジケータ、汎用インジケータ、薬剤および／または治療の提案、第三者への照会、またはヘルスケアの提供に関する情報である。アラートは、限定ではないが、アイコン、時計の文字盤、ＶＵメータ、バロメータ、体温計、テキスト等の任意のグラフィックコンテンツまたはテキストコンテンツを含むことができる。
メッセージ：メッセージは、限定ではないが、ショートメッセージサービス（ＳＭＳ）、インスタントメッセージ、電子メール、ツイート、ポーク、テキスト、自動または手動の電話呼、ビデオ、オーディオ、任意の形態のコンピュータ利用通信、または情報を送信するための任意の他のフォーマット等を含む手段によるネットワークを介したアラートの送信である。
ルーティング：限定ではないが、専門知識、患者に対する関係、認証等を含む要因に基づいて、適切なケアチームメンバ、患者、または他の関連する第三者を決定し、この単数または複数の関係者にメッセージを送達する任意の手段。
ネットワーク：ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、地域ネットワーク、全国ネットワークおよび／またはグローバルネットワーク等の任意の地理的エリアにまたがるネットワークまたはネットワークの組み合わせを指すことができる。インターネットは、現在のグローバルコンピュータネットワークの例である。これらの用語は、有線ネットワーク、無線ネットワーク、または有線ネットワークおよび無線ネットワークの組み合わせを指すことができる。有線ネットワークは、例えば、光ファイバ回線、ケーブル回線、ＩＳＤＮ回線、銅線回線等を含むことができる。無線ネットワークは、例えば、セルラーシステム、パーソナル通信サービス（ＰＣＳ）システム、衛星通信システム、パケット無線システムおよびモバイルブロードバンドシステムを含むことができる。セルラーシステムは、例えば、数ある中でも、符号分割多重接続（ＣＤＭＡ）、時分割多重接続（ＴＤＭＡ）、パーソナルデジタルフォン（ＰＤＣ）、グローバルシステムモバイル（ＧＳＭ（登録商標））または周波数分割多重接続（ＦＤＭＡ）を用いることができる。
ウェブサイト：ウェブサイトは、１つ以上のウェブサーバ上の１つ以上の相互に関係したウェブページファイルならびに他のファイルおよびプログラムを指すことができる。ファイルおよびプログラムは、上記ウェブページファイルのロケーションを識別するユニフォームリソースロケータ（ＵＲＬ）を指定するハイパーテキスト転送プロトコル（ＨＴＴＰまたはＨＴＴＰＳ［Ｓ−ＨＴＴＰ］）要求を送信することによって、インターネット等のコンピュータネットワークを介してアクセス可能であり、いくつかの実施形態において、ファイルおよびプログラムは、単一の事業体によって所有、管理または権限付与される。そのようなファイルおよびプログラムは、例えば、ハイパーテキストマークアップ言語（ＨＴＭＬ）ファイル、共通ゲートウェイインターフェース（ＣＧＩ）ファイルおよびＪａｖａ（登録商標）アプリケーションを含むことができる。ウェブページファイルは、好ましくは、ウェブサイトのホームページに対応するホームページファイルを含む。ホームページは、ウェブサイト内に含まれる残りのファイルおよびプログラムに対するゲートウェイまたはアクセスポイントとしての役割を果たすことができる。１つの実施形態では、ファイルおよびプログラムの全てが、ホームページファイルと同じネットワークドメイン下で位置特定され、このドメイン内でアクセス可能である。代替的に、ファイルおよびプログラムは、いくつかの異なるネットワークドメインを通じて位置特定され、アクセス可能であってもよい。
ウェブページまたは電子ページ：ウェブページまたは電子ページは、ウェブページファイルが識別されるＵＲＬを指定するＨＴＴＰ要求に応答して標準的なウェブブラウザによって提示されるものを含むことができる。ウェブページは、例えば、テキスト、画像、サウンド、ビデオおよびアニメーションを含むことができる。
コンピュータまたはコンピューティングデバイス：コンピュータまたはコンピューティングデバイスは、パーソナルコンピュータ、ワークステーション、サーバ、クライアント、ミニコンピュータ、メインフレームコンピュータ、ラップトップコンピュータ、個々のコンピュータのネットワーク、モバイルコンピュータ、パームトップコンピュータ、ハンドヘルドコンピュータ、テレビのためのセットトップボックス、他のタイプのウェブ対応テレビ、インタラクティブキオスク、携帯情報端末（ＰＤＡ）、インタラクティブまたはウェブ対応無線通信デバイス、モバイルウェブブラウザ、またはこれらの組み合わせ等の端末デバイスを含む任意のプロセッサ制御デバイスとすることができる。コンピュータは、キーボード、マウス、タッチパッド、ジョイスティック、ペン入力パッド等の１つ以上の入力デバイスを更に保有することができる。コンピュータは、視覚ディスプレイおよびオーディオ出力等の出力デバイスも保有することができる。これらのコンピューティングデバイスのうちの１つ以上がコンピューティング環境を形成することができる。
これらのコンピュータは、ユニプロセッサまたはマルチプロセッサマシンとすることができる。更に、これらのコンピュータは、ランダムアクセスメモリ（ＲＡＭ）、電子的に消去可能なプログラマブル読出し専用メモリ（ＥＥＰＲＯＭ）、プログラマブル読出し専用メモリ（ＰＲＯＭ）、消去可能なプログラマブル読出し専用メモリ（ＥＰＲＯＭ）、ハードディスク、フロッピーディスク、レーザディスクプレーヤ、デジタルビデオデバイス、コンパクトディスク、ビデオテープ、オーディオテープ、磁気記録トラック、電子ネットワーク等の、アドレス指定可能なストレージ媒体またはコンピュータアクセス可能な媒体、ならびに、プログラムおよびデータ等によって電子コンテンツを送信または記憶する他の技法を含むことができる。１つの実施形態では、コンピュータは、ネットワークインターフェースカード、モデム、またはインターネット等の通信ネットワークに接続するのに適した他のネットワーク接続デバイス等のネットワーク通信デバイスを装備している。更に、コンピュータは、Ｌｉｎｕｘ（登録商標）、ＵＮＩＸ（登録商標）、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓのバージョンのうちの任意のもの、Ａｐｐｌｅ ＭａｃＯＳ、ＩＢＭ ＯＳ／２、ｉＯＳ、Ａｎｄｒｏｉｄまたは他のオペレーティングシステム等の適切なオペレーティングシステムを実行する。適切なオペレーティングシステムは、ネットワークにわたって渡される全ての着信および発信メッセージトラフィックを扱う通信プロトコルの実施を含むことができる。他の実施形態では、オペレーティングシステムは、コンピュータのタイプに依拠して異なることができるが、オペレーティングシステムは、適切な通信プロトコルを提供して、ネットワークとの通信リンクを確立し続ける。
コンピュータは、プログラムロジック、またはデータおよび命令を表す他の基板構成を含むことができ、これによって、コンピュータは、本明細書に記載されるように、特定の所定の方式で、専用マシンとなるように動作する。１つの実施形態では、プログラムロジックは、１つ以上のオブジェクトフレームワークまたはモジュールとして実施することができる。これらのモジュールは、アドレス指定可能なストレージ媒体上に存在するように構成することができ、１つ以上のプロセッサ上で実行されるように構成することができる。モジュールは、限定ではないが、ある特定のタスクを実行するソフトウェアまたはハードウェアコンポーネントを含む。このため、モジュールは、例として、ソフトウェアコンポーネント、オブジェクト指向ソフトウェアコンポーネント、クラスコンポーネントおよびタスクコンポーネント、プロセス、機能、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路部、データ、データベース、データ構造、テーブル、アレイおよび変数等のコンポーネントを含むことができる。
システムの様々なコンポーネントは、例として、プロセス間通信、リモートプロシージャ呼、分散オブジェクトインターフェース、および他の様々なプログラムインターフェース等のメカニズムを通じて、互いに、およびそれぞれのコンピュータを含む他のコンポーネントと通信することができる。更に、コンポーネント、モジュールおよびデータベースのために提供される機能は、より少ない数のコンポーネント、モジュールもしくはデータベースに組み合わせるか、または更なるコンポーネント、モジュールもしくはデータベースに更に分割することができる。更に、コンポーネント、モジュールおよびデータベースは、１つ以上のコンピュータにおいて実行されるように実施することができる。別の実施形態では、コンポーネント、モジュールおよびデータベースのうちのいくつかを、ウェブサイトの外部にある１つ以上のコンピュータにおいて実行されるように実施することができる。この例において、ウェブサイトはプログラムロジックを含み、このプログラムロジックは、ウェブサイトが、外部で実施されるコンポーネント、モジュールおよびデータベースと通信し、本明細書に開示される機能を実行することを可能にする。
＜概観＞
本明細書に記載のシステムおよび方法は、完全に所有者中心であり、粒度の細かいユーザ間データ共有を容易にする。いくつかの実施形態では、最終的な許可制御は常に所有者または所有者の代理人に留まる。未成年者および無資格者（ｉｎｃａｐａｂｌｅ）には保護者関係が存在することができる。組織は、スケーリング可能な許可管理構造物を用いて、所有者によって与えられたアクセスを、自身の組織内のスタッフに容易にかつ精密に割り当てることを可能にする能力を有する。
システムおよび方法は、所有者が、自身のデータダイアリの全てのエリアに対し、アクセスなし、読み出しアクセスまたは書き込みアクセスを選択することができる粒度の細かいアクセスを定義する能力を提供する。各所有者は、自身のダイアリを潜在的に閲覧する権利を有する全てのユーザのリストを見て、いずれのユーザが自身のデータへのアクセスを有するかを見る能力／可視性を有する。各所有者は、自身のダイアリ全体にわたって、いつ、どのユーザによって、何の変更／追加が行われたかを見る能力／可視性も有する。
＜説明＞
次に、添付の図面を参照して実施形態を説明する。ここで、全体を通じて、類似の番号は類似の要素を指す。本明細書に提示される説明において用いられる用語は、いくつかの特定の実施形態の詳細な説明に関連付けて利用されていることに単に起因して、何らかの制限または制約された方式で解釈されることを意図するものではない。更に、実施形態は、いくつかの新規の特徴を含むことができ、それらのうちのいずれも、その所望の属性について全責任を負うものではなく、本明細書に説明される発明を実施するのに不可欠なものでもない。
いくつかの実施形態は、ヘルスケア提供者が、薬の履歴、相関、治療、栄養、ライフスタイルの選択、患者の生理学的値（例えば、血圧）および症状を、これらの全てに対する変更を含めて迅速に理解することができるように、チャートに対する関連医療データを提供するためのシステムおよび方法を含む。これらのシステムおよび方法は、ヘルスケア提供者、ならびに訓練および専門知識が少ない患者および他のケアチームメンバが、このデータを的確に読み出し、解析することを可能にする。更に、誤りのリスクも最小限になる。他の実施形態では、システムおよび方法は、データの所有者が許可によるデータへのアクセスの制御を望む他の分野で使用されてもよい。
図１を参照すると、システム１００の実施形態は、個人に関する記憶された医療データを作成、維持および利用するためのシステムツール１７８を含む。そのようなデータ集合は、Ｌｉｆｅｔｉｍｅ Ｈｅａｌｔｈ Ｄｉａｒｙ（ＬＨＤ）と呼ぶことができ、ダイアリと呼ぶこともできる。システム１００のいくつかの実施形態は、以下で図２Ａと併せて説明されるようなネットワークを利用する。いくつかの実施形態は、以下の関係者、すなわち、所有者または患者１８６（患者の代理人を含むことができる）、身内１８８（家族、隣人、保護者等も含むことができる）、医師１８０（かかりつけの医師および／または専門医を含むことができる）、看護師１９０、薬剤師１８２（臨床薬剤師を含むことができる）、および以前に列挙していない他の医療従事者１８４のうちの１つ以上のためのツールにアクセスを提供するためのウェブページを有するウェブサイトを利用することができる。いくつかの実施形態では、システム１００は、患者の制御下で全ての関係者によって閲覧され、いくつかの関係者によって埋められる共通患者データセット１９８等の医療情報のレンダリング、解析および表示のためのツール１７８と共に機能するＬＨＤデータベース１９６を含む。いくつかの実施形態では、システム１００は、１つ以上の健康または監視デバイス１９２（例えば、血圧モニタ、電子はかり）と通信し、他のデータベース１９４と通信する。
システム１００は、データ仲介者を利用して、与えられた例示的なデータソース（例えば、薬剤師または医師）が、ダイアリにデータを直接入力することができないが、このデータを、代替的な経路を介して、例えば医師または薬剤師のレコードから電子的に取り込むことができることを示すことができる。このいくつかの実施形態は、図４と併せて等で以下に説明される。
本明細書に記載される方式でディスプレイ上に関連医療データを提供するためのシステムおよび方法は、ヘルスケア提供者にも患者にも、多くの利点を有する。例えば、システムおよび方法の実施形態は、以下の特徴および利点のうちの１つ以上を提供することができる。
・異種のソースからのデータを照合し、この医療情報の単一のデータベースを作成することによって、全ての関連するコンテキストデータの容易で迅速な解析が可能になる。
・データを共通の構造化フォーマットおよび共通のデータフォーマットに変換する。
・患者の健康全体の、理解が容易なグラフィック解析を提供する。
・可能性のある薬に対する患者の反応、またはそれらの投薬計画の変化の、理解が容易なグラフィック解析を提供する。
・可能性のある禁忌、および可能性の高い有害作用源を示す、理解が容易なグラフィック解析を提供する。これは、特定の薬剤投与計画を開始した後に現れるかまたは消失する可能性がある新たな副作用および／または治効から、患者の既存の症状および病状を切り離すことを含むことができる。
・健康治療の代替的な形式は、個々の患者について、または公衆の健康に基づいて、より容易に従来の治療計画と比較することもできる。
・患者から、または患者のケアに関与する医療専門家から、背景健康情報を利用する能力を提供する。これは、時間相関により順序付けすることができ、特定の薬剤投与計画との直接比較および相関を可能にする。
・薬、医療および健康情報データ、患者データ、およびデータのプロの健康所見間の関係を発見することを可能にする。
・不適切な処方を低減する。
・薬剤の間違いおよび見落としを低減する。
・患者の忠実性、健康成果および利用を改善する。
・薬剤計画のコスト効率を増大させる。
・様々な薬剤計画のコストの容易な要約および理解を可能にする。
・理解が容易な薬剤計画をリアルタイムで適切な関係者に送信する。
・異なるデータタイプ間の相関を特定する能力を提供する。
・閲覧者が、ダイアリが表す個人（所有者）の状態／履歴に迅速に精通する能力を提供する。
・データ表示が、現在の閲覧者の目標／関心を満たすように容易に構成されるための能力を提供する。
・健康履歴の任意のポイントにおける任意の特定のデータに容易に／迅速にナビゲートする能力を提供する。
従来技術の医療データ収集および表示システムを上回るこれらの利点は、データをリアルタイムで有意義な方式で受信し表示することができるため、更に向上させることができる。「リアルタイム」という用語は、ここでは、完全に同時のデータ収集、処理および表示を示すために用いられない。そうではなく、いくつかの実施形態では、リアルタイムとは、データ収集、処理および表示が、実際に追跡されているイベントに対し、治療決定が継続的に有利な方式で行われることを可能にするのに十分近い時点にあることを意味する。これは通常、データをヘルスケア提供者のデータベース等に入力するための従来のタイムスケジュール、および監視されている状態に何が適しているかのユーザの判断に基づく表示の頻度を考慮に入れる。例えば、リアルタイムとは、監視されている条件に依拠して、時間ごと、シフトベース、日ごと、週ごと、月ごとの更新および／または表示閲覧を含むことができる。
そのようなリアルタイムプロセスは、臨床現場で医療専門家によって患者に対し、より総合的で、応答性が高く、および／またはコスト効率の良いケア（ケア最適化）を提供することができることを意味する。多くの場合、これによって、以前は複雑で難解であった情報を、薬理学者等の専門家に送信し、対応する時間および支出を要して解読および解釈する必要を回避することができる。
実施形態は、単一の臨床現場における２つ以上のソースからの患者健康情報データを照合し、解析し、表示するための健康調整ツールを含むことができる。いくつかの実施形態では、タイムラインは、特定の所有者のダイアリを含むデータの、時間的に照合され、集約されたビューである。タイムラインの表示域（現在表示されている領域）は、ズームインおよびズームアウトすることができ（例えば、日−週−月−年）、時間を通じて前後にパンすることもできる。ダイアリデータの任意のサブセットを、閲覧のために、閲覧者の需要に合う順序で選択することができる。
いくつかの実施形態は、図１、図２Ａ、図２Ｂおよび図２Ｃに示す例示的なオープンシステム統合アーキテクチャに基づく。図２Ａ〜図２Ｃにおいて、例示的なオープンシステム統合アーキテクチャは、例えば、ウェブアプリケーション１５０’、アプリケーションプログラミングインターフェース（ウェブまたはその他）１５０’’’および統合システム１５０等のローカルまたはリモートのアプリケーションシステム上で実行される、ローカルまたはリモートデータリポジトリ、およびローカルまたはリモートアプリケーションとインタラクトするユーザインターフェースに基づくことができる。いくつかの実施形態では、ウェブアプリケーション１５０’、アプリケーションプログラミングインターフェース（ＡＰＩ）１５０’’および統合システム１５０はそれぞれ、１つ以上のサーバ、または１つのサーバにおいて動作することができる。図２Ａ〜図２Ｃは、本明細書に記載のいくつかのシステムおよび方法を実施するのに用いることができる例示的なシステム１００のブロック図である。コンピューティングシステム１００のコンポーネントおよびモジュールにおいて提供される機能は、より少ない数のコンポーネントおよびモジュールに組み合わせるか、または更なるコンポーネントおよびモジュールに更に分割することができる。ネットワーク化された環境において通信する様々な他のタイプの電子デバイスを用いることもできる。
いくつかの例示的なコンポーネントの簡単な概観は以下のとおりである。
・統合システム：このシステムは、様々なインバウンドデータ経路を監視し、所有者のダイアリに追加するためにインバウンドデータを処理する。例えば、ＣＣＤ（Ｃｏｎｔｉｎｕｉｔｙ ｏｆ Ｃａｒｅ Ｄｏｃｕｍｅｎｔｓ、ＸＭＬベースの医療履歴文書）はこのようにしてインポートすることができ、注釈付きのスキャンされた紙文書が、ダイアリおよびデータボルトにインポートされ追加されることを可能にするフォーマットも存在する。このシステムは、内部使用のためのみにあり、いかなる他のアプリケーションによっても直接アクセス可能でない。
・通知サービス：このサービスは、Ｎｏｔｉｆｉｃａｔｉｏｎｓ（通知）データベースを監視し、第三者システム（例えば、電子メール、ＳＭＳ）に送信される必要がある通知が生じるとき、このシステムはデータを取り出し、通知テキストをレンダリングし、要求された方法により通知を送信する。これはアウトバウンド経路のみであり、メッセージングシステムを呼び出す。いかなる他のアプリケーションもこれにコンタクトすることはできない。
・ウェブアプリケーション：一般的にダイアリと呼ばれる。これは、所有者が、自身のダイアリデータを用いて作業し、自身のユーザプロフィールを維持し、自身のダイアリを閲覧するように他の人を招待すること等のために、ウェブブラウザを介してログインするウェブサイトおよびその支援コード（ｂａｃｋｉｎｇ ｃｏｄｅ）である。
・管理サイト：システムオペレータスタッフが、ユーザを追加／維持すること、レポートを実行すること等を含む、システムを管理することを可能にする。システムオペレータスタッフまたは所有者でない人には利用可能でない。
・アプリケーションプログラミングインターフェース：外部アプリケーション、例えば、ｉＯＳアプリケーション、Ａｎｄｒｏｉｄアプリケーション、様々な試験システムにダイアリデータベースアクセスを提供する。いくつかの実施形態では、第三者アプリケーションへのアクセスがないが、他の実施形態では、第三者アプリケーションへのアクセスがある。
・ＩＩＳ：いくつかの実施形態における様々な認証サービスと共に、ダイアリウェブアプリケーション、管理サイトおよびＡＰＩをホスティングするＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｍａｔｉｎｏ Ｓｅｒｖｅｒ。
ＡＰＩ１５０’’は、第三者外部アプリケーションおよびシステム１００のオペレータによって作成された外部アプリケーションの双方がシステムと通信することができるインターフェースを提供する。ＡＰＩ１５０’’は、ストレージ１５４のデータベースへの経路と、データベースからのデータをフォーマットして、これらの外部クライアントによる消費に適したものにし、同様に外部クライアントからのデータをフォーマットし、データベースに送信するのに適したものにする機能とを提供する。ＡＰＩ１５０’’は、外部アプリケーションおよびそのユーザ（存在する場合）が、ユーザが有するべきデータのみにアクセスを有するようにセキュリティを提供する。ＡＰＩ１５０’’は、ユーザまたはシステムが自身のアカウントおよび自身の医療データを更新することを可能にし、供給されるウェブユーザインターフェースを用いることなくアカウントおよび医療データを取り出すことを可能にする。いくつかの実施形態では、ＡＰＩ１５０’’は、ＡＰＩ内のダイアリデータの所有者として認証をサポートする（例えば、あるユーザは、例えば、ビジタとしてログインすることができず、別の所有者のダイアリデータを見ることができない）。他の実施形態では、あるユーザは、ビジタとしてログインし、適切な許可を用いて別の所有者のダイアリデータを見ることが可能であり得る。
図２Ａを参照すると、ここで、ネットワークを用いるシステム１００の実施形態のコンポーネントの例示的な構成が説明される。いくつかの実施形態では、モバイルまたは固定コンピューティングデバイス１１０がユーザ１３０によって操作される。他の実施形態では、コンピューティングデバイス１１０は、明示的なユーザを有しないサーバとすることができる。そのようなサーバは、例えば、システム１００のオペレータまたは統合第三者システムのオペレータによって所有することができる。他のモバイルまたは固定コンピューティングデバイスが存在し得る。コンピューティングデバイス１１０は、ハンドヘルドコンピューティングデバイス、またはＰａｌｍ、ポケットパーソナルコンピュータ（ＰＣ）、Ｌｉｎｕｘ（登録商標）ベースのハンドヘルド、ＰＤＡ等の他のポータブルコンピューティングデバイス、ｉＰｈｏｎｅ（登録商標）等のスマートフォン、ｉｐａｄ（登録商標）等のタブレットコンピュータ、またはディスプレイを有するＰＣとすることができる。他の実施形態では、コンピューティングデバイスは、限定ではないが、ＰＣ、モバイルデバイス、ＰＤＡ、ラップトップ、タブレット、チップ、キーボード、音声オーディオおよびビデオソフトウェア、マウス、キーパッド、タッチパッド、トラックボール、マイクロフォン、ビデオ、ストレージデバイス、ネットワークデバイス、データベース、スキャナ、コピー機、デジタルペン、画像認識ソフトウェアおよびデバイス、画面および他の形態のディスプレイ、ネットブックおよび他の形態のコンピュータハードウェアを含む、任意の形態のインターネット接続デバイスとすることができる。いくつかの実施形態では、特定のユーザが、ユーザに対応する複数のコンピューティングデバイスを有し、使用することができる。そのような複数ユーザデバイスの状況では、システム１００は、特定のユーザに対応する各デバイス間でデータを同期することができる。いくつかの実施形態におけるコンピューティングデバイス１１０は、例えばサーバであるとき等、スタンドアロン（独立）方式で動作する。他の実施形態では、コンピューティングデバイス１１０は、ウェブアプリケーション１５０’および／またはＡＰＩ１５０’’とネットワーク１４０を介して通信する。他の実施形態では、他の数のサーバを利用することができる。サーバは、１つ以上のプロセッサ１５２、メモリ１５８、プロセッサによって実行されるシステムソフトウェア１５６、および入力または出力デバイス１６０を含むことができる。いくつかの実施形態では、データストレージサブシステム１５４は、統合システム１５０、ウェブアプリケーション１５０’およびＡＰＩ１５０’’とデータ通信し、ＬＨＤデータベース１９６（図１）等のシステムによって用いられる１つ以上のデータベースを記憶する。プロセッサ１５２’は、構造化されたクエリ言語（ＳＱＬ）またはオープンデータベース接続性（ＯＤＢＣ）等のデータベースインターフェースを介してデータベースと通信することができる。いくつかの実施形態では、データストレージ１５４は、データベースインターフェースを介してサーバとデータ通信する。コンピューティングデバイス１１０からネットワーク１４０への接続は、無線もしくは衛星接続１４４、または有線もしくは直接接続１４２とすることができる。統合システム１５０、ウェブアプリケーション１５０’およびＡＰＩ１５０’’がシステムソフトウェアおよびデータと共に動作するサーバは、専用マシンとして機能する。いくつかの実施形態では、サーバは、イントラネットまたはインターネット等におけるウェブサイトの一部である。
コンピューティングデバイス１１０がサーバに接続されるとき、ウェブサイトは、新たな特徴に対する更新をオプションで提供することができる。別の実施形態では、コンピューティングデバイスは、サーバに接続されたときのみ実行される。
コンピューティングデバイス１１０は、プロセッサ１１２と、メモリ１２２と、ディスプレイ１１４と、１つ以上の入力デバイス１１６とを備える。サーバとして動作するとき、ディスプレイ１１４および入力デバイス１１６はオプションとすることができる。プロセッサはデータストレージ１１８とデータ通信する。いくつかの実施形態では、データストレージ１１８は、ユーザおよび／または他のデータもしくはソフトウェアのレコードを記憶することができる。システムソフトウェア１２０は、プロセッサ１１２によって実行される。システムソフトウェア１２０は、アプリケーショングラフィカルユーザインターフェース（ＧＵＩ）を含むことができる。アプリケーションＧＵＩは、コンピューティングデバイスのデータストレージ１１８へのデータベースインターフェースを含むことができる。いくつかの実施形態では、ソフトウェアは、データストレージ１１８からロードされる。いくつかの実施形態では、ソフトウェアは、モバイルアプリケーションとすることができる。実施形態では、コンピューティングデバイス１１０がウェブサイトと通信する場合、プロセッサは、ソフトウェア１２０の代わりにまたはソフトウェア１２０に加えてブラウザソフトウェアを利用する。ネットワークブラウザは、例えば、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）、Ａｐｐｌｅ Ｓａｆａｒｉ（登録商標）、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ（登録商標）、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（商標）、Ｏｐｅｒａ Ｓｏｆｔｗａｒｅ（商標）からのブラウザ等とすることができる。コンピューティングデバイス１１０は、システムソフトウェアおよびデータと共に、専用マシンとして動作することができる。プリンタ等のオプションの出力デバイス１２９は、コンピューティングデバイス１１０に接続される。
モバイルアプリケーションの例は、Ｄｉａｒｙ ｉＯＳアプリケーションを含む。Ｄｉａｒｙ ｉＯＳアプリケーションは、アプリケーション、ＬＨＤデータベース１９６およびＨｅａｌｔｈＫｉｔフレームワーク間の三方向同期を含むことができる。
データＸ１７０の外部ソース、健康または監視デバイス１７１、およびデータＮ１７２の外部ソースは、有線または無線接続を用いて、ネットワーク１４０および／またはコンピューティングデバイス１１０のうちの１つ以上と通信する。データの外部ソースは、限定ではないが、診療所、病院、ヘルスケアネットワーク、保険、調剤、薬局、地域健康局、薬剤給付管理会社、公衆健康エンティティ、政府および民間機関、救急医療士、研究者、健康指導者、薬理学者、医師および他の医療専門家、患者ネットワーク、教育機関、雇用主、研究所、従来の補完代替医療従事者、医薬品、臨床研究組織、遠隔の薬品提供者、関連保険機構、介護者および介護者組織を含む。外部デバイス１７０、１７１、１７２のうちの１つ以上が、ＡＰＩ１５０’’を利用してデータを同期するか、またはコンピューティングデバイス１１０を介してこれを行うことができる。外部データソース１７０、１７２はホストハードウェアを含むことができ、ホストハードウェアは、いくつかの実施形態では、利用可能性をもたらすために、完全に冗長なハードウェアインフラストラクチャ（例えば、並列のサーバまたは負荷平衡スワップサーバ）を用いるか、または自身のアクティブシステムおよびパッシブスタンバイシステムとしての別のマルチプロセッサのためのマルチプロセッサシステムを実施することにより自身のデータシステムのためのスケーラビリティを得る。外部データソース１７０、１７２は、ソフトウェアプラットフォームを提供するためのオペレーティングシステム（例えば、マルチプロセッシング、マルチユーザ、マルチタスクおよびリアルタイム）も含むことができ、このソフトウェアプラットフォーム上で、外部エンティティのアプリケーションプログラムを実行することができ、同時に実行中の異なるプログラムおよびユーザが互いに干渉しないことを確実にすることができる。オペレーティングシステムは、認可されていないユーザが外部データソース１７０、１７２にアクセスしないことを確実にする等の、セキュリティも担当する。外部データソース１７０、１７２は、Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎからのリレーショナルデータベース等のデータベースも含むことができる。リレーショナルデータベースは、情報を安全に確立し、データ品質を確保し、常に利用可能なアクセスを提供し、ユーザが要求する応答時間をもたらすように調整し、ダウンタイムを低減し、管理タスクを自動化し、スケーラビリティを通じて動作コストを低減する。データの外部ソースは、医療データの処理のために統合システムおよびウェブアプリケーションに関連付けられたサーバに、更なる処理を必要とする処理済みのまたは未処理のデータをプッシュすることができる。処理済みデータは、システムＬＨＤデータベースを更新するのに用いられる。例えば、統合システム１５０は、システム内部データ経路によって提供されるデータを消費することができ、データベースに書き込む。そこから、クライアントデバイスはウェブアプリケーションまたはＡＰＩを介してデータを消費することができる。
図２Ｂを参照すると、ここで、ストレージサブシステム１５４の実施形態のコンポーネントの例示的な構成が説明される。ストレージサブシステム１５４は、データボルトストレージ１６１と、サマリデータベース１６２を含むデータベースの組と、コアデータベース１６３と、統合データベース１６４と、管理データベース１６５と、データボルトデータベース１６６と、セキュリティデータベース１６７と、通知データベース１６８と、他のデータベース１６９とを含むことができる。データボルトストレージ１６１は、データボルトのためのバルクデータストアであり、ディスク上の単一のディレクトリ、または第三者バルクデータリポジトリとすることができる。いくつかの実施形態では、データボルトストレージ１６１は、単純なファイル名以外によってインデックス付け可能である必要も検索可能である必要もない。データボルトデータベース１６６は、データボルトストレージ１６１に記憶されたデータをダイアリ内の所有者ユーザに関係付け、タグ、作成日等の他のメタデータを保持するローカルデータベースである。
サマリデータベース１６２は、タイムラインにより消費される、ダイアリカテゴリまたはモジュールごとの、また将来的には、必要に応じて他のシステムの、経時的に集約されたデータを保持する。コアデータベース１６３は、ユーザ／ログイン、ダイアリデータ等を含む全てのコアデータを含む。統合データベース１６４は、外部システムとの統合に固有のデータ、例えば到来するデータの記録状態を含む。管理データベース１６５は、管理ユーザ（例えば、サポート）のためのログインおよび役割データを保持する。データボルトデータベース１６６は、データボルト文書のためのメタデータを含むが、実際のバイナリデータを記憶しない。セキュリティデータベース１６７は、支援用の記憶されたプロシージャを含み、将来的には、アプリケーションセキュリティのために、おそらく関連するテーブルを含む。通知データベース１６８は、使用者のための通知およびメタデータ、例えば、送信されようとしているかまたは送信された電子メール、画面上の（ウェブ）通知、ＳＭＳ通知等を含む。通知データベース１６８は、通知サービスによって通知を送信し、コアアプリケーションによって送信用の通知をキューに入れ、コアアプリケーションによって画面上の通知を示すのに用いられる。
コアデータベース１６３は、ユーザ／ログイン、ダイアリデータ等を含む全てのコアデータを含むことができる。いくつかの実施形態では、コアデータベース１６３は以下のものを記憶することができる。
・所有者固有のダイアリデータ、例えば、運動、喫煙および睡眠の記録。
・これらによって参照される静的データ、例えば、異なるタイプの運動、薬剤、状態のリスト。
・ログイン認証情報データ
・パーソナル／プロフィールデータ（名前、住所、社会保障番号，．．．）
・許可−許可の定義、およびビジタ／組織／役割．．．のための許可、招待
いくつかの実施形態では、サマリデータベース１６２は、完全に派生データとすることができる。データは、需要に応じて再作成することができるため、任意の時点でドロップすることができる。いくつかの実施形態では、これは単なるキャッシュであり、大量のデータの再計算を回避する。この計算されたデータは、経時的なダイアリエントリのグループを表す。例えば、データは、日単位、週単位、月単位および年単位での所有者の運動アクティビティのサマリを含むことができる。
サマリデータベース１６２は、タイムラインにより消費される、ダイアリカテゴリまたはモジュールごとの、また将来的には、必要に応じて他のシステムの、経時的に集約されたデータを保持することができる。これは、日ごと、週ごと、月ごと、年ごと等の期間にわたってそのモジュール内に保持されるデータを反映するモジュールごとのレコードからなる。各レコードは少なくともインデックスからなる。このインデックスは、いずれのタイプの期間が要約されているかを示し、サマリデータを直接含むこともできるし、または当該のモジュールの要件に依拠して、サマリデータを含むサブレコードを有することもできる。例えば、スリープモジュールは、複数タイプの睡眠の概念がないため、インデックスしか必要としない場合がある。一方、症状モジュールは、（集約されている期間のレコードを提供するための）インデックスおよび複数のサマリサブレコードを必要とする場合があり、１つはその期間中に生じた症状の各タイプを要約するものである。
サマリデータベース１６２のデータは、コアデータベース１６３から構築される。サマリインデックスは、以下のようなモジュールごとの中央エンティティである。
・［Ｉｄ］［ｉｎｔ］ＩＤＥＮＴＩＴＹ（１，１）ＮＯＴ ＮＵＬＬ：インデックスレコードのＩＤ。
・［ＰａｔｉｅｎｔＩｄ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：コアデータベースにおける、データが属する所有者のＩＤ
・［ＰｅｒｉｏｄＴｙｐｅＩｄ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：このサマリがカバーする期間のタイプ（以下を参照）。
・［ＳｔａｒｔＤａｔｅ］［ｄａｔｅ］ＮＯＴ ＮＵＬＬ：期間が始まる日付。
・［ＥｎｄＤａｔｅ］［ｄａｔｅ］ＮＯＴ ＮＵＬＬ：期間が終了する日付。
・［Ｃｏｕｎｔ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：この集約に寄与したレコード数。
期間タイプは以下のとおりである。
・Ｉｄ
・値
・１ 日ごと
・２ 週ごと
・３ 月ごと
・４ 年ごと
各インデックステーブルは、そのデータタイプに固有のより多くの列を有することができるか、またはモジュール固有のテーブルとそのＩＮＤＥＸとの間の多対１の関係が存在する場合がある。例えば、症状のインデックステーブルは、上記で列挙した列のみを有するが、サブテーブルＳｙｍｐｔｏｍＳｕｍｍａｒｙを有する。
・［Ｉｄ］［ｉｎｔ］ＩＤＥＮＴＩＴＹ（１，１）ＮＯＴ ＮＵＬＬ：このサマリのＩＤ
・［ＳｙｍｐｔｏｍＩｎｄｅｘＩｄ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：このサマリが属する症状インデックス（上記）。
・［ＳｙｍｐｔｏｍＩｄ］［ｉｎｔ］ＮＵＬＬ：要約されている症状。例えば、単一の月期間において、いくつかの症状が生じる場合がある。各々が独立して要約され、このため、自身の頭痛が今月深刻であったが、背部痛は大きく改善されたことを知ることができる。
・［Ｄｅｓｃｒｉｐｔｉｏｎ］［ｎｖａｒｃｈａｒ］（２５５）ＮＵＬＬ：症状の平文説明。
・［ＭｉｎＳｅｖｅｒｉｔｙ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：この期間中に記録されたこの症状の最小深刻度。
・［ＡｖｇＳｅｖｅｒｉｔｙ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：この期間中のこの症状の平均深刻度。
・［ＭａｘＳｅｖｅｒｉｔｙ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：この期間中に記録されたこの症状の最大深刻度。
・［ＲｅｃｏｒｄＣｏｕｎｔ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ：この期間中に記録されたこの症状のインスタンス数。
一方、いくつかのモジュールは、期間中に生じ得る異なるデータタイプの概念を有しない。例えば、ストレスは単純であり、任意の時点があるレベルのストレスを有するが、ストレスの種類に区別がない。このため、インデックステーブルは以下のように見え得る。
上記のインデックスにおけるような標準的なフィールド：
・［Ｉｄ］［ｉｎｔ］ＩＤＥＮＴＩＴＹ（１，１）ＮＯＴ ＮＵＬＬ
・［ＰａｔｉｅｎｔＩｄ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ
・［ＰｅｒｉｏｄＴｙｐｅＩｄ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ
・［ＳｔａｒｔＤａｔｅ］［ｄａｔｅ］ＮＯＴ ＮＵＬＬ
・［ＥｎｄＤａｔｅ］［ｄａｔｅ］ＮＯＴ ＮＵＬＬ
および、上記のサマリと同様の目的を有するフィールド：
・［Ｍａｘ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ
・［Ｍｉｎ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ
・［Ａｖｅｒａｇｅ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ
・［ＲｅｃｏｒｄＣｏｕｎｔ］［ｉｎｔ］ＮＯＴ ＮＵＬＬ
いくつかの実施形態では、データボルトデータベース１６６は、データボルト文書のためのメタデータを含有し、以下のフィールドを含む：
・ＵＩＤ：文書を一意に識別するＧＵＩＤ
・ＦｉｌｅＮａｍｅ：文書のユーザフレンドリなファイル名
・ＦｉｌｅＳｉｚｅ：バイト単位での文書のサイズ
・ＰｅｒｓｏｎＩｄ：この文書の所有者を（コアデータベースからの）その所有者のＩＤによって識別する
・ＣｒｅａｔｅｄＤａｔｅ：この文書が最初にアップロードされた日付
・ＭｏｄｉｆｉｅｄＤａｔｅ：この文書の最後の変更の日付
・Ｎｏｔｅｓ：自由形式のテキストメモ
・ＤａｔａＳｏｕｒｃｅＩｄ：この文書の発生源、例えば、ウェブアプリケーション、ＡＰＩ（モバイルアプリケーション）、統合システムを識別する
・ＤａｔａＳｏｕｒｃｅＲｅｆ：外部アプリケーションによって用いるように利用可能な自由形式のテキストフィールド
・ＥｎｃｒｙｐｔｉｏｎＴｙｐｅ：（ディスク上のフラットファイルについて現在アクティブである）この文書において用いられる暗号化のタイプ
更に、文書との多対多の関係で記憶されたタグが存在する。
・ＵＩＤ：タグを一意に識別するＧＵＩＤ
・Ｎａｍｅ：タグのテキスト名
・ＰｅｒｓｏｎＩｄ：このタグの所有者を（コアデータベースからの）その所有者のＩＤによって識別する
統合データベース１６４は、外部システムとの統合に固有のデータ、例えば、着信データの記録状態を含む。このデータは、現在サポートされている統合の種類を詳述し、統合システム１５０に、各統合タイプに対応するコードを参照させる。このようにして、統合経路は、データベースを介して開始および停止することができる。このデータベースは、全ての統合アクションのログを記録し、用いられている統合メッセージを統合パイプラインに記憶する。
管理データベース１６５は、管理ユーザ（例えば、サポート）のためのログインデータおよび役割データを保持する。これは、各管理ユーザが、管理ウェブアプリケーションのいずれのエリアを閲覧／使用することを許可されるかを制限するのに用いられる。
いくつかの実施形態では、セキュリティデータベース１６７は、アプリケーションセキュリティ（許可）のためのアシスタントストアドプロシージャのみを含む。セキュリティデータベース１６７は、他の形式のテーブルまたはデータを含まない。他の実施形態では、セキュリティデータベース１６７は、許可関連テーブルを含むことができる。
通知データベース１６８は、ユーザのための通知およびメタデータ、例えば、送信されようとしているかまたは送信された電子メール、画面上（ウェブ）通知、ＳＭＳ通知等を含む。通知データベース１６８は、通知サービスによって通知を送信し、コアアプリケーションによって送信用の通知をキューに入れ、コアアプリケーションによって画面上の通知を示すのに用いられる。
通知データベース１６８は、通知を作成するのに用いられるテンプレートおよび作成された通知の双方のテンプレートを含むことができる。通知テンプレートは以下のとおりである。システムは、現在、複数のタイプの通知を生成することができる。
・パスワードリセット
・新規所有者確認電子メール
・新規所有者歓迎
・新規ゲスト確認電子メール
・新規ゲスト歓迎
・新規アカウント電子メールが存在する
・新規ゲストを招待
・新規ユーザを招待
・招待が送信された
・招待が受け入れられた
・招待が拒否された
・許可が変更されたゲスト
・許可が変更された所有者
・アカウントフィールドが変更された
・ゲストが排除された
・ゲストが他のゲストを排除した
・ゲストが去った
・ゲストが他のゲストを招待した
・人物が新たな電子メールを追加
・ゲストが招待を受入れ
・フリーの新規所有者歓迎
新たなタイプの通知を定期的に追加することができる。各通知タイプが１つ以上のテンプレートを有し、各々が所与の言語のコンテンツを表す。次に、各テンプレートは、複数のコンテンツタイプ、例えば、平文、ＨＴＭＬを有する。このようにして、送信されなくてはならない通知のタイプを選択することによって、システムは、独自の言語でそのユーザに通信を送信することができる。テンプレートは不変であり、コンテンツを更新しなくてはならない場合、レコードの新たな組が追加される。これによって、古い通知が、厳密に元々送信されたときに出現したとおりに再生されることが可能になる。
通知インスタンスは以下のとおりである。システムが通知を生成するとき、この通知は、パラメータの組、およびテンプレートへの参照として記憶される。このようにして、いくつかの実施形態では、大量の複製ボイラープレートテキストがデータベースに記憶されることがない。
通知分布は以下のとおりである。通知データベース１６８は各通知のステータスを記憶することができる：
・未送信（送信を待機）
・リトライ
・送信済み
・失敗
これは、通知Ｗｉｎｄｏｗｓサービスおよび他の通知消費者によって要求に応じて更新される。
通知テンプレートオーサリングツールは以下のとおりである。通知システムは、管理者が通知を更新するのを容易にするツールを含む。管理サイトにおいて、管理ユーザは、通知テンプレートを変更することができる。データベースは、テンプレートパラメータのサンプル値を保持し、通知システムが、更新されているテンプレートからの通知をレンダリングして、ユーザに自身の通知の現実的な例を提供することができるようにする。
システムは、複数のバッキングストア（ｂａｃｋｉｎｇ ｓｔｏｒｅ）にわたってデータボルトデータを広める能力を含む。いくつかの実施形態では、データは、ローカル（ディスク上のフラットファイル）ストレージおよびバルクデータストレージプロバイダ、例えばＡｍａｚｏｎ ＡＷＳ Ｓ３にわたって広がっているが、システムは、必要なだけ多くのストアをサポートすることができるように設計される。従来、データボルトは、自身のファイルをローカルまたはネットワーク共有ドライブにのみ記憶していた。これは、柔軟性がなく、高価であり、アプリケーションサーバ（ウェブまたはＡＰＩ）がアップロードまたはダウンロード（例えば、暗号化）時に多くの作業を行うことを必要とするため、長期間において機能可能でなかった。第三者サービスがバルクデータストレージのために存在し、このため、これらの裏方のサービスを利用可能であることは利点を提供する。なぜなら、全てのネットワークトラフィック、およびデータのストレージに関係する他のオーバーヘッドを、ダイアリサーバからストレージプロバイダのサーバに肩代わりさせることができるためである。他の利点は以下を含む：
・システムは、複数のバッキングストアを一度に扱うことができる。ユーザが文書をアップロードすることを選択すると、システムは、いずれのプロバイダおよびいずれのサイトを使用するか判断することができる。
・複数のサービスレベルがサポートされる。例えば、これらのユーザのためのバッキングストアをより高速に、もしくはよりセキュアにすることができるか、またはデータのための他のアクセス方法を提供することができる場合、プレミアムサービスを提供することができる。
データボルトデータベース１６６は、ＤｏｃｕｍｅｎｔＳｔｏｒｅと呼ばれるテーブル内に、現在サポートされているバッキングストアのリストを含む。データボルトデータベース文書テーブルは、ストアテーブルに対する外部キーを設定されたＳｔｏｒｅＩｄ列を有する。遠隔のバッキングストアにおいて、ファイルは環境（例えば、これがそのデータボルトであるダイアリシステム）およびユーザ（以下で示すように、ＵＲＮ）によって記憶され、元のファイル名が維持される。このようにして、ユーザがバッキングストアから直接ファイルをダウンロードするとき、ダウンロードされた文書のファイル名は正しい。
いくつかの実施形態において、ダイアリインスタンス内で、データベースエンティティは、整数ＩＤによってのみ識別される。これらは、データベース内であっても一意でなく、特定のテーブルのコンテキスト内でのみ意味を有する。これは大きな制限ではない。一方、複数のダイアリシステムにわたって一意にエンティティを識別できる必要がある場合、各システムが、ｉｄ１を有するエンティティ、ｉｄ２を有するエンティティ等の独自のローカルバージョンを有する可能性が高いので、これは問題となり得る。この例は、いくつかの実施形態においてＬｉｆｅｔｉｍｅ Ｈｅａｌｔｈ Ｄｉａｒｙとすることができるシステム１００のオペレータによる認証システムの実施において見られる。いくつかの実施形態では、ＴｈｉｎｋｔｅｃｔｕｒｅＩｄｅｎｔｉｔｙＳｅｒｖｅｒ３（ＯＡｕｔｈ）に基づく認証システムを利用することができる。ユーザがログオンすると、認証システムの実施は、このユーザのエンティティの整数ＩＤが何であるかを知らせるのみでなく、このユーザのエンティティ（およびデータ）がいずれのダイアリインスタンス内に存在するかも知らせることが可能でなくてはならない。そのために、任意の所与のデータベース行／エンティティの正確なロケーションを指定する標準的な表記が定義された。ダイアリ内のコードを書くとき、通常、エンティティユニフォームリソース名（ＵＲＮ）を利用する必要がない。グローバル単位でエンティティを参照する必要があり得る場合、エンティティＵＲＮを用いてこれを行うことができる。ＥｎｔｉｔｙＵＲＮＳｅｒｖｉｃｅおよび関連するインターフェースが実施された。
エンティティＵＲＮは以下のフォーマット：ｕｒｎ：＜ｉｎｓｔａｎｃｅ＞：＜ｄｂ＞：＜ｔｙｐｅｎａｍｅ＞−＜ｉｄ＞に従う。
Figure 2018512085
上記のテーブルにおける例の結果として、ＵＲＮ ｕｒｎ：ｉｎｓ２：ｃｏｒｅ：Ｐｅｒｓｏｎ−４４が得られる。
図２Ｃを参照すると、図２Ｂに示すデータボルトデータベース、コアデータベースおよびデータボルト文書ストレージ間のインタラクションの実施形態の例が説明される。データボルトデータベース１６６は、コア人物ＩＤ、ストアＩＤ、文書ＩＤ、文書名および他のデータ／列／フィールドを有する文書テーブル２６６を含む。データボルトデータベース１６６は、ストア名、ストアロケーション、ストアＩＤおよび他のデータ／列／フィールドを有する文書ストアテーブル２６７も含む。コアデータベース１６３は、コア人物ＩＤおよび他のデータ／列／フィールドを有する人物テーブル２６３を含む。文書テーブル２６６は、文書の所有者およびその厳密なストレージロケーションを特定するフィールドを含む。コア人物ＩＤフィールドは、特定の文書が属するコアＤＢ１６３内の人物テーブル２６３内のユーザを示す。ストアＩＤ、文書ＩＤおよび文書名フィールドは、文書を見つけることができるロケーションを定義する。ストアＩＤは、いずれのストア（データボルトローカルストア２６０、データボルト遠隔ストア１ ２６１、データボルト遠隔ストア２ ２６２、および２６４によって表される更なるストア）に文書を見つけることができるかを示す。ストア内のファイルのロケーションは、文書ＩＤ、文書名、または文書テーブル２６６内のレコードから派生する他のメタデータの何らかの組み合わせによって定義することができる。文書テーブルレコードの、ストア内のロケーションへのマッピングは、ストア単位で定義され、このため、方式はストアごとに異なることができる。
いくつかの実施形態では、データボルトは、Ａｍａｚｏｎ ＡＷＳ Ｓ３データストアに文書を書き込む。一方、他の実施形態では、利用可能なストレージロケーション間で選択する他の要因は、以下を含むことができる。
・ローカル法的要件
・ビジネス要件
・セキュリティ要件
・地理（物理／ネットワーク近接性）
・ユーザアカウントタイプ−例えば、フリー、標準、プレミアムアカウントは、異なるレベルのストレージを提供することができる。
文書を読むために、データボルトは、ダウンロードを発呼側クライアント（ＡＰＩの場合）にプロキシするか、またはダウンロードされたＵＲＬを、リダイレクトにより、もしくは特定の要求に応じて提供する。
データベースエンティティは、３つの方法で識別することができる。
・整数ＩＤは、特定のデータベースインスタンス内でローカルでのみエンティティを識別する。例えば、ｉｄ４４を有する人物が、双方の製造インスタンス（ｉＯＳ／フリーアカウントデータベース、および支払い済みアカウントデータベース）に存在する場合がある。整数ＩＤのみを指定しても、いずれのデータベースにおいてエンティティを見つけることができるかは示されない。
・ＵＩＤはグローバル一意であり、このため、このように識別されたエンティティに曖昧性は存在しない。一方、依然として、ＵＩＤのみから、いずれのデータベースにおいて所与のエンティティを見つけることができるかを知ることはできない。
・ＵＲＮは、マルチパート識別子であり、エンティティのロケーションを完全に、例えば、いずれのシステム、いずれのインスタンス、いずれのタイプおよびいずれのレコードが要求されているかを指定する。これは全く曖昧性がなく、エンティティへの完全なパスを提供するが、他の２つのＩＤタイプのように良好に機能しない場合がある。
いくつかのエンティティは、３つ全てのＩＤタイプの使用を必要とする可能性がある。例えば、人物は、データベース内の参照整合性を強制するために整数ＩＤを用い、これを統合インポートのためのターゲットとして識別するためにＵＩＤを用い、グローバル認証システムによって参照されるとき、ＵＲＮを用いる。
＜医療情報の提示＞
通常、患者医療情報は、ＸＭＬデータエクスポートファイルを用いて、カンマ区切り（ＣＳＶ）ファイル内に収集され、次に、スプレッドシートにおいて手作業で表示される。そのようなスプレッドシートの異なるビューは、時間相関を極端に困難にする。なぜなら、日付は、薬品名でソートされた場合、順序がバラバラである可能性があるためであり、用量および薬剤の任意の変更についても同様である。他方で、他のソート順は、薬品名が混ざって、ビューが一層混乱することを意味する。最新技術の全体的影響により、判定および判断が、時間がかかり、直観的でなく、複雑で、通常特殊な専門知識を要するものとなる。対照的に、システム１００は、関連データを、特に直観的であり、全てのケアチームメンバにとって有用なものとするように提供するフォーマットを表示する。
データ収集の観点で、データは、ＸＭＬデータエクスポートファイル（または任意の他の適切なフォーマット）として引き出してシステム内に入れることができ、システムはこのデータを構造化し表示する。医療データは、多岐にわたるソースからインポートすることができる。これらのソースは、紙の記録、音声記録、コンピュータ化された電子医療記録等の、今日の患者に関するデータを収集もしくは記憶するシステム、または患者の身体に埋め込まれ、無線通信方法を用いて周期的に生理学的測定値を送信するナノマシン等の、将来的に開発され得るシステムを含む。データは、一貫したフィールド、一貫した値の単位（例えば、グラム）等を有する一貫したコンピュータレコード構造に入れられるように構造化される。
データは、生理学的測定値、薬、用量、開始および停止等を示すシンボルの一貫した組を用いて表示することができる。いくつかの実施形態では、一連の垂直方向に位置合わせされた水平の線が引かれ、これらの線は、開始時点（データが利用可能である最初の時点またはユーザによって選択された任意の他の時点とすることができる）において開始し、終了時点（現時点、またはオプションで、ユーザによって選択された任意の以前の時点とすることができる）において終了する。各線は、１つの変数（例えば、薬）のためのデータを含むことができるか、またはオプションで、１組の関連変数を含むことができる。これらの線の組は、画面上またはページ上に表示される（これは、ユーザによって選択された患者またはサブセットのための全てのデータの完全な組とすることができる）。これらの線は、全てが同じ開始時点、終了時点およびタイムスケールを有するように同期させることができる。これによって、ユーザは、データにわたる相関および他の関係を見ることが可能になる。従来のシステムでは、これらの相関および関係は、異なるソースによって提供され、別個に記憶されるデータから到来するため、理解するのが困難であるかまたは不可能であった。
図３を参照すると、特定の所有者または患者のための医療情報を処理するプロセス３００の実施形態の例が説明される。上記で説明したようなデータソース３１０は、患者の背景／履歴情報３１２等の医療情報、および治療および／または薬剤情報３１４等の進行中のデータを、特定の患者のための任意の他の以前に述べた医療情報と共に提供する。いくつかの実施形態では、情報３１２および情報３１４は、構造化プロセス３１６、構造化プロセス３１８およびデータボルト３２１のうちの１つ以上にルータ３１５によってルーティングされる。データボルトは、スキャンされたレコード、メモ等を含む様々な患者情報、ならびに画像、オーディオおよびビデオデータ等を、例えばその捕捉されたフォーマットで記憶することができる。以下の図４に関連してルータが更に説明される。１つの実施形態では、患者の背景情報は、構造化プロセス３１６によって構造化され、治療および／または薬剤情報を含む進行中の患者データは、構造化プロセス３１８によって構造化される。他の実施形態では、或る特定の医療情報を構造化するための他の構成を用いることができる。情報を一貫した標準化されたレコードフォーマットに正規化することを含むことができる、医療情報の構造化の後、情報はデータベース３１９内の特定の患者のためのダイアリに記憶される。
患者のダイアリからの情報には、データ間の複雑な関係を処理することによって解析を行う解析プロセス３２０によってアクセすることができる。患者背景、治療および／または薬剤情報、ならびに他の患者データのこの解析は、限定ではないが、色、蛍光ペン、矢印またはインジケータの形態を含めて、プロセス３５０において画面上に視覚的にレンダリングすることができる。解析は、ヘルスケアのプロが薬もしくは治療、または臨床試験もしくは実験に変更を加えることを提案するように、システムおよび方法によって用いることもできる。所望の場合、解析プロセス３２０を用いて、リスクもしくは重大なイベントが存在するか否か、または薬剤および／もしくは治療もしくは第三者への参照の提案が適切であるか否かを判断することもできる。判断手段は、患者のデータを検討する経験則またはアルゴリズムを含む。このプロセスの出力は、送信されるアラートをメッセージとして含むことができる。いくつかの実施形態では、解析プロセス３２０は、所有者（患者）が一定の目標に到達するのにどのくらい長くかかるかを判断すること、有害な傾向を特定すること等の傾向検出を含むことができる。
患者データの解析は、再現システムを含むことができる。再現システムは、データベースパターンを用いる。これは、例えば、以下のようにこの事象が生じた場合に、再現データを表すものとしてテーブル列の組を認識することを含む。
・特定の時点に１回生じるか？
・特定の時点から開始して、いくつかの定期的に生じる時点に繰り返し生じるか？
・特定の時点から開始して、ある期間にわたって絶えず生じるか？
・および、事象が定期的にまたは長期間にわたって生じたとき、その期間がいつ終了したか、または依然として進行中であるか？
再現システムは、コアデータベース１６３およびアプリケーションサーバコードのためのデータベース方式の一部である。
解析プロセス３２０の出力は、レンダリングプロセスおよび／または介入もしくは治療変更状態３７０に送信することができる。いくつかの実施形態は、人物の専門知識、患者との関係、レンダリングプロセス３５０から入力を受信するルーティングプロセス３６０における認証情報および他の関連情報、またはイベント情報３５５に基づいて、各メッセージを受信する適切な人物を決定することができる。ルーティングプロセスは、メッセージが全ての適切な受信者に送信されるが、他の人には送信されないことを確実にすることができる。潜在的な受信者は、限定ではないが、患者３６２、薬剤師３６４、看護師および／または医師３６６、および介護者３６８を含み、これらは全て、集学的ケアチームの一部である。ルーティングプロセス３６０は、集学的ケアチームの任意のメンバから情報を受信し、この情報を介入または治療変更状態３７０にルーティングすることもできる。任意の介入または介入変更情報は、例えば、新たなデータソースとして構造化プロセス３１８に送信することができる。
解析プロセス３２０の出力は、集約プロセス３３０に送信することもできる。集約プロセス３３０は、タイムスタンプ、または限定ではないが、年齢、性別、所在地、職業、ライフスタイル選択、ライフイベント、既往症を含む基礎健康状態、遺伝的形質識別子、症状、治療、薬剤もしくはヘルスケア提供者を含む他のフィールドによって、異種のソースからのデータをソートすることを含むことができる。集約は、複数の患者に対応するデータを集約するオプションのステップを含むように拡張することができ、そのケアは、特定のヘルスケアのプロ、ヘルスケア施設、領域、国、および／または、個体群または個体群の個々に標的にされたサブセットにわたる任意の特定の形態の治療提供によって提供される。集約プロセス３３０の出力は、解析プロセス３２２に送信され、解析プロセス３２２は、ユーザが処方され実行された薬剤および治療を相関付け、薬剤の過剰処方または処方不足、治療の有効性、特定の症状または疾患の優れた診断または劣った診断、禁忌の認識等を含む、これらのケア提供者に関する複数の要素を決定することを可能にする。これは、ヘルスケア提供者の専門知識の特定の分野、および／または特定の治療計画の有効性、および／または更なる訓練もしくは教育が必要とされる分野を判断するのに有用とすることができる。解析結果は、例えば、構造化プロセス３１８を通じてＬＨＤデータベース３１９に記憶することができる。
集約プロセス３３０の出力は、特定のヘルスケアのプロ、ヘルスケア施設、領域、国、および／または、個体群、個体群の個々に標的にされたサブセット、または特定の患者にわたる任意の特定の形態の治療提供によって処方されるような薬剤または治療の結果を追跡、監視および測定する、測定および追跡プロセス３４０にも送信される。測定および追跡プロセス３４０の出力は、上記で説明したレンダリングプロセス３５０への入力として用いることができる。
システムおよび方法は、様々な異なるソースから捕捉された異なるタイプのフィールドから複数のタイプのデータを捕捉する。システムおよび方法は、任意の種類のソースからの任意の種類の医療データを、患者および家族介護者を含むケアチームにとってより有用で有意義なものにするために、グラフィカルサマリページ上で別の用途に使う。
下記のテーブル１における以下のデータは、データ捕捉元のいくつかの例を示す。これらは単に例示的なものであり、右の列におけるデータソースは、列挙された様々なデータソースの任意の組み合わせとすることができる。データフィールドのうちの任意のもののために用いられ得る更なるソースは、電子医療記録（ＥＭＲ）である。ＥＭＲ、薬局管理ソフトウェア（ＰＭＳ）またはＬａｂＦｅｅｄからのデータフィードからのデータ抽出は、ＨＬ７に準拠したＸＭＬデータとすることができる。システムおよび方法は、全ての異種データを、全てのケアチームメンバが共有し洞察を得るための、標準的で一貫した理解が容易な単一のフォーマットに効率的に標準化する。
Figure 2018512085
ここで図４を参照すると、図３に示す、患者履歴データ３１２、患者の進行中データ３１４、ルータ３１５、および構造化３１６および３１８の例示的な構造および構成が更に説明される。いくつかの実施形態では、患者履歴データ３１２は、紙ベースのレコード４１０および電子レコード４１２を含む。紙ベースのレコード４１０は、手動データ入力４２０によって処理することができ、電子レコード４１２は、自動インポート動作４２２によって処理することができる。更に、紙ベースのレコード４１０および電子レコード４１２は、ルータ３１５によって、例えば紙ベースのレコード４１０のスキャンとすることができるインポートプロセス４３２等の処理動作４３０にルーティングすることができる。電子レコード４１２（例えば、デジタル写真）等の他の情報を、最小処理でインポートすることができる。処理４３２の出力はデータボルト３２１に記憶される。データボルトにおける情報の記憶は以下で更に説明される。
いくつかの実施形態では、患者の進行中データ３１４は、マニュアルデータソース４１４、および健康または監視デバイス等の電子データソース４１６を含む。マニュアルデータソース４１４はマニュアルデータ入力４２４によって処理することができ、電子データソース４１６は自動インポート動作４２６によって処理することができる。
いくつかの実施形態では、マニュアルデータ入力４２０の出力は、構造化プロセス３１６のマニュアルインポートプロセス４４０にルーティングされる。自動インポート動作４２２の出力は、構造化プロセス３１６の電子レコード変換プロセス４４２にルーティングすることができる。マニュアルデータ入力４２４の出力は、構造化プロセス３１８のダイアリマニュアルデータ入力プロセス４４４にルーティングすることができる。自動インポート動作４２６の出力は、構造化プロセス３１８の電子データストリーム変換プロセス４４６にルーティングすることができる。この情報が構造化プロセス３１６および３１８によって共通フォーマットに構造化された後、この情報はダイアリデータベース３１９に記憶され、解析プロセス３２０において解析することができる。
更なる説明において、データ文書は、ダイアリにインポートすることができる。いくつかの実施形態では、ダイアリは、健康または医療情報の多くのカテゴリ、タイプまたはモジュールを含む。これらは、履歴データ（多くの場合、病院、一般開業医（ＧＰ）、または他のリポジトリからのバルクデータ）または通常、単一の動作（例えば、薬局における処方箋の調合）に固有の進行中のデータのいずれかとすることができる。これらは、１）ダイアリデータ、例えば、対応するダイアリモジュールのための入力を作成するのに用いられる医療処方、および２）ダイアリモジュールに固有の情報を含まず、データボルト内にのみ現れる非ダイアリデータ、例えば、Ｘ線画像、とすることができる。他の実施形態では、情報のカテゴリ、タイプまたはモジュールは、非医療データに関するものとすることができる。
いくつかの実施形態において、ダイアリに到来する全てのデータ文書が所有者のデータボルトに記憶される。任意の文書が、１つ以上のダイアリデータを含むことができる。例えば、ＧＰからのレコードは、複数の状態、症状および治療を含むことができる。いくつかの実施形態では、パートナがパースされた医療データを処理し、次にこれを、ＰＤＦフォーマットでスキャンされた文書と共に、合意されたフォーマットでダイアリに送信する。パースされたデータと共に、データアイテムごとのインデックスも含まれる。このインデックスは、添付のＰＤＦにおけるデータソースを示し、いずれの文書がそれを含むか、およびその文書における関連ページを示す。
システム１００の使用者は、１）ダイアリのインスタンスを有するデータ（例えば、健康情報データ）の所有者、２）ダイアリを有しないが、（例えば、親、きょうだい、友人等のために）所有者のダイアリへの選択アクセスを与えられ得るビジタ、３）組織に属するスタッフメンバ（例えば、医者、看護師、技術者、管理スタッフ）、および４）ダイアリを有するが、別の所有者のダイアリにもアクセスを与えられている所有者／ビジタを含むことができる。ビジタは、読み出しおよび／または書き込み特権を有することができるゲストとして、または完全な所有者特権を有してダイアリを用いることができる保護者（例えば、子供または能力のない人物のダイアリを、所有者であるかのように管理する実証可能な法的権限を有する大人）として更に分類され得る。
図５を参照すると、例示的なダイアリ許可が説明される。許可は、特定の動作を実行する能力とみなすことができる。特定の患者のための例示的な患者アカウント５１０が、管理プロフィール、管理招待、および管理商品を、薬剤、運動、睡眠および病気に関する情報のカテゴリ、タイプまたはモジュールと共に含む様々な態様を有するものとして示される。これらの様々な態様は、特定の許可によってセキュアにされる。
図６および図７を参照すると、許可発行の例が説明される。許可は、例示的な患者アカウント５１０から、別の患者／所有者、ビジタ、ゲスト、および組織のスタッフメンバのうちの１つ以上に与えられる。患者／ビジタは、ダイアリ内の所有者のレコードを閲覧する／更新する許可を有する第三者の患者／所有者である。
単一の許可は、所有者のためのダイアリによって保持される情報のタイプ、または所有者もしくは組織に関する特徴へのアクセスを制御する。許可によって制御される情報の例は、運動レコード、処方および治療である。許可によって制御される特徴の例は、ユーザプロフィールおよび他のユーザへの招待の送信である。
許可は、プライベートの読み出し専用（情報の追加、更新または削除が許可されないことを意味する）とすることもできるし、またはフルアクセス（情報の追加、更新または削除が許可される）を与えることもできる。
いくつかの実施形態において、許可は組単位で適用される。許可の組は、許可の任意の組み合わせを含むことができ、それらの各々が個々に、読み出し専用、完全、またはプライベートであり得る。これらの組は、招待を介して所有者によって第三者に与えることができる。
許可は、階層構造であり、例えば（読み出し専用の概念を除いて）、１）所有者の全体アカウントに対する許可、２）所有者のダイアリデータの全てに対する許可、３）運動データに対する許可等である。
この場合、ＬＨＤアプリケーションの任意のユーザが、特定の所有者のための運動データを見るように試み、上記のリストにおける許可を一切有しない場合、この動作は阻止される。ユーザは、運動データにアクセスを有するには、これらの許可のうちの任意の１つを有しなくてはならない。ユーザが許可３のみを有し、運動データ以外の任意のダイアリデータへのアクセスを試行する場合、アクセスは拒否される。ユーザが許可２または１を有する場合、これは、全てのダイアリデータ許可をカプセル化することになるため、全てのダイアリデータへのアクセスが許可される。
「読み出し専用」とは、任意の許可に適用することができる概念である。上記のリストにおいて、ユーザは、タイプ１、２または３の読み出し専用許可を与えられ得る。ユーザがタイプ２「所有者のダイアリデータの全てに対する許可」の読み出し専用アクセスを有する場合、ユーザは、全てのダイアリデータにアクセスすることができるが、それに対し変更を加えることができない。更に、このユーザは、タイプ３「運動データに対する許可」の完全な非読み出し専用許可を有する可能性がある。この場合、ユーザは、運動データに対し変更を加えることが可能であるが、全ての他のダイアリデータはそのユーザに対し読み出し専用のままである。
所有者は、招待を介して別の個人（ゲストと呼ばれる）に自身のデータに対する許可を与えることができる。招待プロセスが完了すると、ゲストは、所有者のダイアリから選択されたデータを見ることができる。ゲストは、ダイアリの所有者がゲストに対応する許可を与えた場合にのみ、特定のデータを見るかまたは更新することができる。
図８を参照すると、組織概念の例が説明される。組織は、例えば、機関、事業または診療所とすることができる。スタッフ人員は、組織によって雇用されるかまたは組織と提携するユーザとすることができる。患者／所有者は、組織がアクセスを与えられたダイアリアカウントの所有者である。許可は、システム内の動作を実行する権利とすることができる。役割は、許可の組織により定義された組み合わせとすることができる。アクセスグループは、スタッフおよび患者をリンクさせる、組織により定義されたグループとすることができる。
図９を参照すると、組織の役割の例が説明される。いくつかの例では、役割の目的は、多数のスタッフメンバにわたる許可のより容易な管理を可能にすることである。スタッフメンバが得る許可は、そのスタッフメンバが属する全ての役割を蓄積したものである。役割は、各組織によって定義することができる。図９に示される例は、管理役割、セキュアな臨床的役割および一般的な臨床的役割を示し、スタッフメンバＡおよびＢは管理役割に割り当てられ、スタッフメンバＢはセキュアな臨床的役割に割り当てられ、スタッフメンバＢおよびＣは一般的な臨床的役割に割り当てられる。
図１０を参照すると、組織アクセスグループの例が説明される。図１０に示す例は、グループＡおよびグループＢを示し、ここで、スタッフメンバＡは、グループＡおよびＢの双方に割り当てられ、スタッフメンバＢはグループＢにのみ割り当てられ、患者ＡはグループＡに割り当てられ、患者ＢおよびＣは共にグループＢに割り当てられる。
このため、所有者がゲストに許可を与える方法と同様にして、所有者によって組織に許可を与えることができる。組織はアクセスグループを生成することができる。次に、組織は、自身の所有者または患者を、適切である場合にアクセスグループに割り当てることができる。所有者は、一度に２つ以上のグループのメンバであり得る。同様に、組織は、自身のスタッフメンバをアクセスグループに割り当て、そのグループのメンバと連携するスタッフメンバを表すことができる。スタッフメンバは、同じ組織内の２つ以上のグループに属することができる。
組織は、独自のスタッフメンバのグループである役割を作成することができる。次に、これらの役割に、組織によって許可を配分することができる。次に、そのグループ内のスタッフメンバは、１）所有者が組織に対応する許可を与えた場合、および２）組織が、スタッフの役割に同じ（または更に上の）許可を与えた場合、および３）所有者が、スタッフメンバが属するアクセスグループ内にいる場合にのみ、所有者のダイアリからのデータを見るかまたは更新することができる。
組織の管理機能に対するアクセスを制御するための役割も用いられる。管理的役割および／または健康／医療の役割間に区別が存在する。
図１１を参照すると、アクセスグループ／スタッフ役割の概念を含む、所有者に対するスタッフメンバのアクセスの例が説明される。組織は、所有者を１つ以上のアクセスグループ内に配置し、スタッフを１つ以上の役割に配置することができる。所有者は、組織に許可を与えることができ、組織は、いずれの許可が各役割に展開されるかを指定することができる。このようにして、患者（ＬＨＤエコシステムにおいて所有者と呼ばれる）は、全ての時点においてそれらのレコードへのアクセスに対し完全な制御を有する。組織は、そのスタッフメンバに与えられるアクセスのレベルを指定し、いずれのスタッフメンバが各アクセスグループに対するアクセスを有するかを指定することができる。
図１１の例において、所有者Ａは、組織ＸＹＺに固有の許可を与える。組織ＸＹＺは、所有者ＡをアクセスグループＡグループに配置する。組織ＸＹＺは、スタッフメンバＡＢＣをアクセスグループＡに配置する。組織ＸＹＺはスタッフメンバＡＢＣを役割ＡおよびＢに配置する。スタッフメンバは、所有者およびスタッフメンバが共通のアクセスグループを共有する場合にのみ所有者のアカウントを閲覧することができる。スタッフメンバが所有者のアカウントにアクセスすることができる度合いは、スタッフメンバが属する全ての役割からの累積的な許可によって決定される。次に、これらの許可は、所有者のアカウントから組織に与えられたもののみに制約される。
図１２を参照すると、招待の例が示される。所有者は、所有者のダイアリレコードにアクセスするようにゲスト（第三者）を招待することができる。このプロセスは、ダイアリアプリケーション内で管理される。プロセスは、招待された人が現在のユーザであるか否かに依拠して変動する。
所有者のアカウントの共有を開始するために、所有者のアカウントから招待が生成される。招待は、この招待が受け入れられる場合に受信者が有することになる許可の組み合わせからなる。単一の招待を、患者、ビジタまたは組織とすることができる単一の受信者に送信することができる。スタッフメンバは、所有者のアカウントへの招待を直接受信することができない。
＜データボルトおよびモジュールデータの作成＞
モジュールデータおよびデータボルトコンテンツは、以下を含むいくつかの方法、すなわち、
１）紙の文書から、ダイアリの所有者、またはＬＨＤおよび／またはその設計されたパートナによって行われるスキャンおよびデータ入力プロセスによって、
２）第三者データリポジトリから、履歴インポートとしてバルクで、またはライブデータを用いてダイアリを更新する進行ベースで、
３）バイタルサインモニタ、電子はかり、運動モニタ等のデバイスから、
ａ）ＬＨＤのモバイルまたはデスクトップアプリケーションによるデバイスとの統合によって、
ｂ）デバイスベンダーのバックエンドシステムとダイアリのバックエンドシステムとの統合によって、
ｃ）任意の他の媒介によって、
４）ダイアリのユーザインターフェースのうちの１つへの、所有者またはその代理人による直接データ入力によって、
生成することができる。
任意の着信データは、データボルトに記憶されるデータおよび／またはダイアリモジュールデータを組み込むことができる。全てのデータが双方を含むわけではない。双方が含まれる場合、ダイアリのユーザは、閲覧されているダイアリデータのアイテムから、データボルト内の関連付けられたデータに直接ナビゲートすることができる。可能な場合、このリンクは、ダイアリおよびデータボルトコンテンツが作成されるのと同時に自動的に作成することができる。
図１３は、ダイアリに履歴紙文書をインポートするのに用いられる全体プロセス１３００を示す。同様のプロセスは、文書（履歴、更新、紙および電子）からの任意のデータをインポートするために用いられる。ダイアリのユーザが、既存のモジュールデータと、データボルト内の文書との間のリンクを確立することも可能である。モジュールデータおよびデータボルト文書は、ユーザによって、または何らかの自動化されたプロセスによって作成された場合があり、このプロセスは、これらのアイテムの元のソースに依拠しない。
状態１３１０から開始して、ソース紙文書が受信され、次に、状態１３２０において、既知のスキャナのうちの任意のものによってスキャンされた。状態１３３０に移り、スキャンされた文書がパースされ、ダイアリモジュールのうちの１つ以上について、対応するソース文書への参照を含むデータが抽出された。
文書が状態１３２０においてスキャンされると、プロセス１３００は状態１３４０において文書をアーカイブし、ダイアリに送信される準備ができているようにする。いくつかの実施形態では、スキャンされた文書は、限られた数のページ、または最大ファイルサイズ等を有する、バルクＰＤＦになるようにコレートされる。例えば、状態１３２０において４００ページが到来する場合、これらは、状態１３４０において各々が１００ページの４つのＰＤＦになるようにコレートされ得る。状態１３３０および１３４０が完了した後、プロセス１３００は状態１３５０に進み、状態１３５０において、ＰＤＦが利用可能にされ、パースされたダイアリデータ（テキスト／数値）およびＰＤＦを組み込むデータの単一のチャンクを、所有者のダイアリに含めるようにダイアリシステムに送信することができるようにされる。状態１３５０において、ダイアリデータおよび文書がパッケージ化される。状態１３６０に進むと、パッケージが受信され、ダイアリによってアンパックされる。ダイアリデータは、データボルト内の対応する文書へのリンクを含んで、状態１３７０においてダイアリモジュールに加えられる。加えて、文書が状態１３８０においてデータボルトに加えられる。
図１４は、文書をリンク付けするためのプロセス１４００の実施形態を示すフローチャートである。いくつかの実施形態では、プロセスは、図２Ａに示すシステム１００において実行することができる。状態１４１０において開始して、ユーザはモジュールデータアイテムにナビゲートする。状態１４２０において、ユーザは、文書リンクプロセスを開始する制御をアクティベートする。状態１４３０において、データボルトブラウザユーザインターフェースがユーザに対し示される。状態１４４０において、ユーザは、リンク付けする文書（およびオプションでページ）を選択する。状態１４５０において、ダイアリはそのモジュールデータアイテムに対して現れるリンクを記録する。
モジュールデータのアイテムとデータボルト文書との間にリンクが存在すると、そのモジュールのデータアイテムの詳細が閲覧されるところにはどこでもリンクが現れる。クリックされると、（ページインデックスが含まれ、閲覧され得る正しいページまで）文書が開くか、または文書がアプリケーションの環境（ウェブブラウザ、モバイルアプリケーション等）内で閲覧可能でない場合、ユーザは文書を外部から通常の方式でダウンロード／閲覧するようにプロンプトされる。これは、例えば、ＰＤＦのための、規格に準拠した方式のリンク：ｈｔｔｐｓ：／／ｗｗｗ．ｌｈｄｓｅｒｖｅｒ．ｃｏｍ／ＤａｔａＶａｕｌｔ／ｍｅｄｉｃａｌｄｏｃｕｍｅｎｔ．ｐｄｆ＃ｐａｇｅ＝５０を実装することによって達成することができる。許可システムによって仲介される文書へのアクセスによりセキュリティが維持される。
図１５は、データボルトへのアクセスを示す画面表示の例である。いくつかの実施形態では、図１５は、メインデータボルトページの実施形態を示す。このページは、日付によるソートおよびフィルタのオプションを示す。これは、単に、ユーザインターフェース／ＡＰＩとデータベースとの間の通常のインタラクションにより行われる。バッキングストアへの参照は必要とされない。
図１６は、データボルトのためのアップロード画面を示す画面表示の例である。図１５のファイルアップロードボタンをクリックすると、ユーザは、図１６に示すアップロードダイアログを見る。ユーザ（例えば、所有者）は、自身のデータボルトにアップロードするファイルを選択するためのファイル選択ボタンを選択することができる。ローカル／ディスク／フラットデータボルトファイルの場合、アップロードは、ウェブアプリケーションのＨＴＴＰサーバに対し直接行われ、ファイルは、サーバに対しローカルに、またはネットワーク共有として、ディスクに書き込まれる。遠隔データボルトの場合、以下が実行される。
・クライアント（ウェブまたはＡＰＩ）が、自身がデータボルト文書をアップロードする準備ができていることをアプリケーションに通知する。
・アプリケーションは、発呼側のクライアントが文書をアップロードするのに用いるためのＵＲＬを生成する。これは、通例、バルクデータストレージプロバイダ、例えば、Ａｍａｚｏｎ ＡＷＳ Ｓ３によって提供されるツールによって作成される。一方、アプリケーションがアップロード自体をプロキシするか、またはファイルがローカルに記憶される場合、これはローカルＵＲＬとすることができる。
・アプリケーションは、上記で生成したＵＲＬ、および必要な場合がある他のメタデータ（ヘッダー、ＨＴＴＰアクション等）を用いてクライアントに応答する。
・クライアントは、特定のＵＲＬに対しＨＴＴＰアップロード（通常、ＰＯＳＴ）を実行する。
・クライアントは、アプリケーションを呼び出し、このアプリケーションに、アップロードの完了に成功したことを通知する。ここで、文書はデータボルトにおける使用のために利用可能である。
図１７は、データボルトのためのユーザオプションを示す画面表示の例である。ユーザは、選択されたファイルのためのコンテキストメニューを見るために、コンテキストメニュー制御（ファイルの入力の右にある３つのバーアイコン）をクリックすることができる。「詳細を閲覧する」オプションにより、ファイルの詳細の読み出し専用ビューが生じる。更に、ユーザは、適宜、許容可能であれば、ファイルを編集、ダウンロードまたは削除することができる。
データボルト文書を取り出すことは、以下の２つのプロセスのうちの１つを含む。
・クライアントは、アプリケーションサーバから文書をダウンロードすることを試みる。次に、アプリケーションサーバは、要求に応じて、ファイルをサービングするか、または第三者バルクデータストレージ施設へのリダイレクトで応答する。
・クライアントは、文書をダウンロードするＵＲＬを要求する。次に、アプリケーションは、要求に応じて、ローカルＵＲＬ、または第三者バルクデータストレージ施設を参照するＵＲＬを送信する。
以前からのＡＰＩクライアントをサポートするために、旧式の直接アップロード／ダウンロードＡＰＩ機能を依然としてサポートすることができる。それらが呼び出された場合、アプリケーションは、クライアントの代わりに上記のステップを実行し、アップロードまたはダウンロードを効率的にプロキシする。
図１８は、所有者とゲストとの間の招待フロー１８００を示す図である。いくつかの実施形態では、プロセスは、図２Ａに示すシステム１００において実行することができる。招待フローのステップは以下の通りである。
１．所有者が招待を発行
・ゲストに通知が送信される−＊メモ：電子メールはリンクを含まない
・所有者のアカウントにおいて招待がリストされる−Ｐｅｎｄｉｎｇ，ｓｔａｔｕｓ＝“Ｓｅｎｔ”
・ゲストアカウントにおいて招待がリストされる−Ｐｅｎｄｉｎｇ，ｓｔａｔｕｓ＝“Ｓｅｎｔ”
２．ゲストが招待を受入れまたは拒絶
ａ．受入れ−
・ゲストアカウントにおいて招待がリストされる−ａｃｔｉｏｎ／Ｐｅｎｄｉｎｇ．ｓｔａｔｕｓ＝“Ａｃｃｅｐｔｅｄ”
・所有者のアカウントにおいて招待がリストされる−Ｐｅｎｄｉｎｇ，ｓｔａｔｕｓ＝“Ａｃｃｅｐｔｅｄ”
ｂ．拒絶−
ゲストアカウントにおいて招待がリストされる−／Ｉｎｖｉｔａｔｉｏｎ／Ｃｏｍｐｌｅｔｅｄ，ｓｔａｔｕｓ＝“Ｒｅｊｅｃｔｅｄ”
所有者のアカウントにおいて招待がリストされる−／ｌｎｖｉｔａｔｉｏｎ／Ｃｏｍｐｌｅｔｅｄ，ｓｔａｔｕｓ＝“Ｒｅｊｅｃｔｅｄ”
招待ワークフロー完了−アクセスが付与されない
＊招待拒絶を知らせる通知が所有者に送信されない
３．所有者が招待を確認またはキャンセルする
ａ．確認−
所有者アカウントにおいて招待がリストされる−Ｉｎｖｉｔａｔｉｏｎ／Ｃｏｍｐｌｅｔｅｄ，ｓｔａｔｕｓ＝“Ｃｏｎｆｉｒｍｅｄ”
ゲストアカウントにおいて招待がリストされる−／Ｉｎｖｉｔａｔｉｏｎ／Ｃｏｍｐｌｅｔｅｄ，ｓｔａｔｕｓ＝“Ｃｏｎｆｉｒｍｅｄ”
招待ワークフロー完了−ここでゲストは所有者アカウントにアクセスすることができる
ｂ．キャンセル−
所有者アカウントにおいて招待がリストされる−Ｉｎｖｉｔａｔｉｏｎ／Ｃｏｍｐｌｅｔｅｄ，ｓｔａｔｕｓ＝“Ｃａｎｃｅｌｌｅｄ”
ゲストアカウントにおいて招待がリストされる−／Ｉｎｖｉｔａｔｉｏｎ／Ｃｏｍｐｌｅｔｅｄ，ｓｔａｔｕｓ＝“Ｃａｎｃｅｌｌｅｄ”
招待ワークフロー完了−アクセスが付与されない
＊招待拒否を知らせる通知がゲストに送信されない
図１９は、ゲストを招待するためのプロセス１９００の実施形態を示すフローチャートである。いくつかの実施形態では、プロセスは、図２Ａに示すシステム１００において実行することができる。
状態１９０５から開始して、プロセス１９００は、状態１９１０に進み、非所有者、例えば、ゲストの電子メールアドレス等の電子アドレスの入力を受信する。プロセス１９００が決定状態１９１５に移り、状態１９１０において入力された電子アドレスを有するゲストとの既存の接続があるか否かを判断する。いくつかの実施形態では、このチェックが常に行われる。これによって、新たな招待が、既に接続または招待を有する人に送信されることを防ぎ、ユーザは、新たな招待を送信する代わりにこれらを編集しなくてはならない。この時点後、プロセス１９００は、招待された人が、最初にアカウントを作成するように招待されるか、または自身の現在のアカウントを用いて接続を形成するかに関する既存のユーザ制御についてチェックする。判定状態１９１５において既存の接続が存在すると判断される場合、プロセス１９００は状態１９２０に移り、フレーズ「このゲストとの接続が既に存在する」等の検証メッセージ、および既存の許可を編集ページへのリンクを介して編集するか、またはこの招待をキャンセルし、これによりオーバーレイを閉じるかのオプションを表示する。
判定状態１９１５において判断される既存の接続が存在しない場合、プロセス１９００は判定状態１９２５に移り、既存の招待が存在するか否かを判断する。既存の招待が存在する場合、プロセス１９００は状態１９２０に移り、フレーズ「このゲストへの招待は既に存在する」等の検証メッセージ、および既存の招待を編集する（未解決の招待を編集する）かまたはこの招待をキャンセルする（これによりオーバーレイを閉じる）かのオプションを表示する。状態１９２０の完了後、次に、プロセス１９００は、ゲストのための電子アドレスを入力するための状態１９１０に続く。
判定状態１９２５において既存の招待がないと判断される場合、プロセス１９００は状態１９３０に進み、データの所有者がゲストに付与される許可を割り当てる。許可の割り当てについては、以下で更に詳細に説明する。状態１９３５に続き、招待情報を有するフォームが、ユーザがダイアログ上のＯＫボタンをクリックしたとき等にサブミットされる。このダイアログは、状態１９１０および１９３０において完了するフィールドを有し、招待される人および与えられる許可を特定する。状態１９３５において、プロセス１９００はこのデータをＬＨＤウェブアプリケーションサーバ１５０’に送信し、このＬＨＤウェブアプリケーションサーバ１５０’は、情報の有効性（例えば、良好に形成された電子メールアドレスを有する）をチェックし、ユーザが見つかった任意の問題を解決するようにプロンプトする。判定状態１９４０に移り、プロセス１９００は、フォームが有効であるか否かを判断する。フォームが判定状態１９４０において有効でないと判断される場合、状態１９２０において検証メッセージが表示され、次にゲストのための電子アドレスを入力するためのプロセス１９００が状態１９１０において継続する。判定状態１９４０においてフォームが有効であると判断される場合、プロセス１９００は、既存のユーザが存在するか否かを判断する判定状態１９４５に進む。既存のユーザが存在する場合、プロセス１９００は、状態１９５０に移り、例えば、フレーズ「＜ユーザ＞こんにちは、＜所有者＞が…に加わるようにあなたを招待しました」を含む単純な招待を送信する。電子メッセージと共に、プロセス１９００によって更新が行われ、これによって、招待が送信されたことの（所有者に対する）通知および招待が受信されたことの（ゲストのための）通知が生成される。
一方、判定状態１９４５において既存のユーザが存在しないと判断される場合、プロセス１９００は、新たなアカウントのための招待を送信するための状態１９５５に進み、例えば、フレーズ「こんにちは、＜所有者＞が…に加わるようにあなたを招待しました」を準備し、アカウントを作成するためのリンクを追加する。招待は、電子メールアドレスに関連付けられ、このため、システムは未解決の招待の通知を表示することができる。次に、プロセス１９００は状態１９６０において継続し、このため、ユーザはアカウントを作成することができる。状態１９５０または状態１９６０の完了時、プロセス１９００は状態１９６５に進み、状態１９６５において、招待ステータスレコードが作成され、コアデータベース１６３に記憶される（図２Ｂ）。状態１９７０に進むと、個人向けのメッセージ、要求に返答するための一意のユニフォームリソースロケータ（ＵＲＬ）、およびシステム１００に関連付けられたよくある質問（ＦＡＱ）ページへのリンクを含む招待が受信者に送達される。
図２０は、ＵＲＬを介して招待に返答するためのプロセス２０００の実施形態を示すフローチャートである。プロセス２０００において、ユーザはゲストである。いくつかの実施形態では、プロセスは、図２Ａに示すシステム１００において実行することができる。開始状態２００５から始まり、プロセス２０００は、ユーザがログインしているか否かを判断するための判定状態２０１０に進む。ユーザがログインしている場合、プロセス２０００は、状態２０１５に移って招待ページを表示する。判定状態２０１０においてユーザがログインしていないと判断される場合、プロセス２０００は状態２０２０に移り、ユーザがログインするか、または新たなログインのためのプロセスを開始することを要求する。状態２０２０の完了後、ユーザはログインし、招待ページを表示するための状態２０１５に進む。
判定状態２０２５に進むと、プロセス２０００は、招待が受け入れられたか否かを判断する。招待が受け入れられた場合、プロセス２０００は、状態２０３０において、受け入れられた招待について、システム１００の適切なユーザに通知する。ユーザは、（所有者が自身の独自のダイアリへの招待を送信した場合）招待者となることができるか、または（ゲストが、自身が介護者である人のダイアリへの招待を送信した場合）招待ゲストおよび所有者の双方となることができる。一方、判定状態２０２５において招待が受け入れられない場合、プロセス２０００は、状態２０３５において、システム１００のユーザに、拒否された招待について通知する。状態２０５０において、プロセス２０００は、拒絶電子メールを招待者に送信し、（所有者のための）招待拒絶および（ゲストのための）招待拒絶の通知を生成し、状態２０５５に移って、招待の拒絶に関連付けられたステータスメッセージを表示する。
一方、招待が受け入れられ、ユーザが状態２０３０において通知を受ける場合、プロセス２０００は状態２０４０に進み、招待に対応する許可が、許可データベース等において更新される。状態２０４０において許可が更新される場合、プロセス２０００は状態２０５５に進み、招待者に確認電子メールを送信することを含めて、適切なユーザに招待の受入れを通知し、所有者およびゲストのために、招待が確認されたことの通知が生成される。プロセス２０００は、状態２０３０において受け入れられた招待に関するステータスメッセージを表示し、プロセス２０００は終了する。
図２１は、データの所有者が組織を招待するためのプロセス２１００の実施形態を示すフローチャートである。いくつかの実施形態において、プロセスは、図２Ａに示されるシステム１００において実行することができる。開始状態２１０５から開始して、所有者は、状態２１１０において組織の名前を入力するか、または状態２１１５において医者の名前を入力し、ここで、医者が属する組織は、例えば、状態２１２０〜２１３０において判断することができる。状態２１２０において、プロセス２１００は組織のアカウントをルックアップする。状態２１２５に進むと、組織のルックアップの結果がプロセス２１００によって表示され、所望の組織の選択が状態２１３０において受信される。判定状態２１３５に進むと、プロセス２１００は、選択された組織がシステム１００によって認識されるか否かが判断される。組織が認識されない場合、プロセス２１００は状態２１４５に移り、可能なオプションを所有者に表示する。判定状態２１３５において組織が認識されることが判断される場合、プロセス２１００は判定状態２１４０において継続し、組織が所有者のアカウントに対し既存のアクセスを有するか否かが判断される。組織が既存のアクセスを有する場合、プロセス２１００は状態２１５５に移り、既存のアクセスに関するインラインメッセージを所有者に表示する。メッセージが表示された後、プロセス２１００は、状態２１１０または２１１５において組織または医者の名前を入力することができる画面に戻る。
判定状態２１４０を継続すると、既存のアクセスが存在しない場合、プロセス２１００は許可を組織に委譲するための状態２１５０に移る。許可を委譲するためのパスと並行して、状態２１６０は、所有者が、組織に対する電子メールメッセージを個人向けにすることを可能にする。状態２１５０における許可の委譲後、プロセス２１００は状態２１６５に進み、状態２１６５において、許可を有するフォームがサブミットされ、判定状態２１７０において有効性についてチェックされる。フォームが有効でない場合、プロセスは状態２１５５に移り、対応するインラインメッセージを所有者に表示する。判定状態２１７０においてフォームが有効であると判断される場合、プロセス２１００は状態２１７５に進み、状態２１７５において、コアデータベース１６３の招待テーブル等において招待ステータスレコードが作成される。状態２１８０に進むと、状態２１６０からの個人向けにされた電子メールメッセージが通知の一部として送信され、送信された通知によりプロセス２１００が終了する。
図２２は、ダイアリへのアクセスを付与するプロセス２２００の実施形態を示すフローチャートである。いくつかの実施形態では、プロセスは、図２Ａに示すシステム１００において実行することができる。状態２２０５から始まり、プロセス２２００は状態２２１０に移り、電子メール等の電子通信において人物またはエンティティの名前を入力する。状態２２１５に進むと、プロセス２２００は、子が提案した（child proposed）許可レコードを用いて招待レコードを作成する。状態２２２０に続き、プロセス２２００は、招待電子メールを人物またはエンティティに送信する。状態２２２５に続き、招待された人は、電子メール内のＵＲＬをクリックし、プロセス２２００は、判定状態２２３０において、ログインまたはアカウント作成アクションが必要であるか否かを判断する。招待された人がシステム１００でのアカウントを有していない場合、プロセス２２００は機能２２３５に移り、機能２２３５において、招待された人のためのアカウントが作成され、アカウントが作成された後、ログインを行うことができる。判定状態２２３０において、招待された人が、システム１００でのアカウントを有すると判断される場合、プロセス２２００は機能２２４０に移り、機能２２４０において、招待された人はシステムにログインすることができる。機能２２３５または２２４０の完了時に、プロセス２２００は、招待された人によって招待が受け入れられたかまたは拒絶されたかを判断する。招待が拒絶された場合、プロセス２２００は状態２２５０に続き、状態２２５０において、拒絶に基づいて招待ステータスレコードが更新され、プロセスが終了状態２２５５において終了する。
一方、判定状態２２４５において、招待が受け入れられると判断される場合、プロセス２２００は状態２２６０に進み、コアデータベース１６３内の招待テーブルを、ユーザ識別情報で更新する。状態２２６５に続き、プロセス２２００は、受入れ通知を元の要求側の所有者に電子通信チャネル（例えば、電子メール）を介して送信する。状態２２７０に移り、要求側の所有者は、電子メールにおいて招待された人に対応するＵＲＬを選択し、次に、判定状態２２７５において、招待された人による受入れを承諾もしくは確認するか、または招待をキャンセルするかを判断する。招待がキャンセルされる場合、プロセス２２００は状態２２５０に進み、状態２２５０において、招待レコードが、キャンセルを反映するように更新される。判定状態２２７５において、招待が承諾されると判断される場合、プロセス２２００は状態２２８０に進み、アクセスレコードを作成し、提案される許可レコードをコアデータベース１６３内の明示的な許可テーブルにコピーする。プロセス２２００は、終了状態２２８５において終了する。
図２３〜図２９は、招待ユーザインターフェースからの例を示す。図２３は、現在の招待を閲覧するための、および招待プロセスにおいて新たな招待を行うための画面を示す画面表示の例である。所有者は、自身の現在の招待を閲覧することができる。このページ上で、所有者は、自身のダイアリを閲覧する新規ゲストを招待するか、または所有者のヘルスケアに参加する組織を招待することもできる。
図２４は、ゲストに関する情報およびゲストに付与する許可を入力するためのインターフェース画面を示す画面表示の例である。「ゲストを招待」ボタンをクリックすると、ダイアログが示され、ここに所有者は、招待する人物の詳細、およびその人物に与えることを望む許可を入力することができる。例えば、所有者は、アカウント、アクセス、ダイアリおよびデータボルトグループの見出しから、プライベート（なし）、閲覧（読み出し）およびアクセス（書き込み）許可間で選択することができ、ここで、いくつかの実施形態では、ダイアリはデータの複数のカテゴリ／タイプ／モジュールを有し、各々がプライベート、閲覧およびアクセス許可のオプションを有する。
図２５は、電子メールで送信された例示的な招待を示す画面表示の例である。詳細が完成し、許可が選択されると、図２４の表示画面において送信ボタンをクリックすることができ、これにより、図２５に示される例示的な電子メール等の、招待された人に対する招待電子メールが送信される。招待された人には、強力なパスワードを作成し、システム１００の使用のための条項および条件を読むように要求することができる。
図２６は、図２３の表示を用いること等によって取り出された招待の詳細を示す画面表示の例である。招待は、未解決ページ（図２３を参照）の送信済み招待パネルに現れることができる。各招待の詳細は、所有者および招待された人によって取り出し、閲覧することができる。
図２７は、完成した招待を所有者およびゲストが見ることができる、招待が完成した画面を示す画面表示の例である。招待プロセスが完了すると、所有者およびゲストは、図２７に示されるこれらの招待を閲覧することができる。
図２８は、所有者のアカウントにおけるゲストによるアクティビティの監査を示す画面表示の例である。所有者のアカウント上でゲストによって行われるアクションの監査は、所有者によって閲覧することができる。
図２９は、特定のゲストに対し、所有者のダイアリへのアクセスを与えた所有者のサマリを示す画面表示の例である。ゲストは、所有者のダイアリへのアクセスをゲストに与えた所有者のサマリを見ることができる。
ダイアリは、所有者が自身のダイアリデータへのアクセスを制御することを可能にする、使用が容易なインターフェースを実施する。図３０は、ユーザ（例えば、所有者）がゲストに割り当てられる許可を更新することを望むときにこのユーザが見るインターフェース画面を示す画面表示の例である。図３０の例は、ウェブアプリケーションのユーザが割り当てられたゲスト許可を更新することを望むときにそのユーザが見るインターフェースである。ゲストの情報は、このポップアップダイアログの最上部に示される。この例において示される４つの許可グループ、すなわち、アカウント、アクセス、ダイアリおよびデータボルトが存在する。各々が、１つ以上のより粒度の細かい許可を含む。所有者は、許可ごとの３つの設定間で以下のように選択することができる。
・プライベート−この許可によって制御されるデータは、このゲストによってアクセスすることができない。
・閲覧−この許可によって制御されるデータは、このゲストによって閲覧することのみが可能である（読み出し専用）。ゲストは、このデータまたはこのデータに関連付けられたメタデータのいずれについても追加、編集または削除を行うことができない。
・アクセス−この許可によって制御されるデータは、このゲストによって、閲覧、追加、編集または削除することができる。
図３１は、ユーザ（例えば、所有者）が組織における役割に許可を割り当てることを望むときにそのユーザが見るインターフェース画面を示す画面表示の例である。組織の管理に特に関係する許可が存在する。これらは、役割にのみ割り当てることができ、それによってこれらをスタッフメンバに渡すことができる。
組織は、アクセス（患者）グループおよび役割を作成および削除し、それらのメンバシップを制御することができる。
＜役割＞
図３２は、組織の管理者が組織における役割を管理することを望むときにその管理者が見るインターフェース画面を示す画面表示の例である。図は、組織の管理者が見ることができる役割のリストの例を示す。このページから、管理者は、新規の役割を追加し、役割を削除し、役割の許可を編集し、いずれのスタッフメンバが役割に属するかを選択することができる。
図３３は、組織の管理者が組織における役割を作成することを望むときにその管理者が見るインターフェース画面を示す画面表示の例である。図３２に示す新規の役割ボタンをクリックすることにより、図３３に示されるようなダイアログが得られる。このダイアログボックスにおいて、ユーザはこの時点において名前を選択し、この新規の役割のための説明を入力することができる。ユーザは、役割がダイアリアクセスの役割（許可に応じて所有者のダイアリへのアクセスを可能にする）であるか、または組織の役割（この組織のための管理機能へのアクセスを可能にする）であるかを選択しなくてはならない。この選択は、いずれの種類の許可をこの役割に割り当てることができるかを制御する。
図３４は、組織内の対応する役割に対し行うことができる動作の、組織の管理者が見るインターフェース画面を示す画面表示の例である。メニュー制御をクリックすることによって、例えば、メンバの管理、許可の管理、役割の編集、または役割の削除等の、対応する役割において実行することができる動作のメニューが現れる。
図３５は、スタッフメンバを管理する際に組織の管理者が見るインターフェース画面を示す画面表示の例である。図３４の表示において「管理メンバ」を選択することにより、結果として、図３５に示されるような例示的なダイアログが得られる。ここで、メンバの横の「Ｘ」制御をクリックして、このメンバをその役割から外すことが可能である。「役割にスタッフを追加」ボタンは、ユーザが役割に追加するスタッフメンバを特定し選択することを可能にする制御を示す。
図３６は、組織の役割のための役割許可を管理するために組織の管理者が見るインターフェース画面を示す画面表示の例である。これは、いずれのオプション（ダイアリアクセスまたは組織）が図３３に示されるダイアログ内で選択されるかに依拠して到達される。役割は、ダイアリアクセスまたは組織のいずれかのためのものであり、適切な許可のみを配分され得る。図３４のメニューの「許可を管理」アイテムを選択することにより、組織がこの役割のメンバシップにより組織のスタッフメンバに委譲することができる許可のリストが得られる。この場合、組織役割の例において、許可（例えばアクセス）は図３６に示されるとおりである。
図３７は、ダイアリアクセスの役割のための役割許可を管理するために組織の管理者が見るインターフェース画面を示す画面表示の例である。ダイアリアクセスの役割の場合、ダイアリの複数のカテゴリのための例示的な許可（例えばプライベート）は図３７に示すとおりである。
＜アクセスグループ＞
図３８は、所有者グループを管理するために組織の管理者が見るインターフェース画面を示す画面表示の例である。組織の管理者が見ることができる所有者グループのリストが図３８に表示されている。このページから、管理者は新たなグループを追加し、グループを削除し、いずれの所有者およびスタッフメンバがグループに属するかを選択することができる。
図３９は、新たなグループの名称および説明を入力するために組織の管理者が見る画面を示す画面表示の例である。図３８における「新たなグループ」ボタンをクリックすることによって、新たなグループの名称および説明を入力するためにユーザを招待する図３９のダイアログが示される。
図４０は、対応するグループに対し行うことができる動作を表示するために組織の管理者が見るインターフェース画面を示す画面表示の例である。メニュー制御をクリックすることによって、対応する役割に対し実行することができる動作のメニューが示される。例えば、動作は、ユーザ（グループ）の管理、グループの編集およびグループの削除を含むことができる。
図４１は、対応するグループの所有者を選択するために組織の管理者が見るインターフェースを示す画面表示の例である。「グループ所有者の管理」動作は、ユーザ（例えば、組織の管理者）が、いずれの所有者が対応するグループ内に入るかを選択することを可能にする。表示は、システム１００内の追加の所有者をルックアップするオプションを含む。
図４２は、対応するグループのスタッフメンバを選択するために組織の管理者が見るインターフェースを示す画面表示の例である。「グループスタッフの管理」動作は、ユーザ（例えば、組織の管理者）が、いずれのスタッフメンバが対応するグループ内に入るかを選択することを可能にする。表示は、システム１００内の追加のスタッフをルックアップするオプションを含む。
図４３は、対応するグループの名称および説明を編集するために組織の管理者が見るインターフェースを示す画面表示の例である。図４０に示す「グループ編集」動作は、ユーザ（例えば、組織の管理者）が、例えば、グループの名称および説明を変更することを含めて、対応するグループを編集することを可能にする。
図４４は、ユーザインターフェース要素がレンダリングされるか否かを判断する、すなわち、特定のユーザインターフェース要素の可視性を判断するためのプロセス４４００の実施形態を示すフローチャートである。いくつかの実施形態では、プロセスは図２Ａに示すシステム１００に対して実行することができる。ＸＭＬ定義ファイル（例えば、以下に説明されるサイトマップ）は、プロセス４４００の一部として利用される。いくつかの実施形態では、各ＵＩ要素は、レンダリングされるべきであるか否かに関して条件チェックを必要とする。
各ユーザインターフェース（ＵＩ）要素のための開始状態４４１０において始まり、プロセス４４００は、対応する特徴が有効にされているか否かを判断する判定状態４４２０に進む。アプリケーションは、ユーザ単位でオンまたはオフにすることができる複数の特徴を有する。いくつかの実施形態では、これらの特徴は、言語選択、ケアチームおよび実験結果の文書リンクであるが、更なる特徴が追加されてもよい。これらのユーザへの割り当ては、例えば、単純なリンクテーブルＰｅｒｓｏｎＡｐｐｌｉｃａｔｉｏｎＦｅａｔｕｒｅに記録される。チェックプロセスは以下のとおりとすることができる。
・所与のＵＩ要素がアプリケーション特徴の一部であるか否かを判断する。一部でない場合、このチェックにパス（チェックを通過）する。
・現在のユーザがＵＩ要素のアプリケーション特徴へのアクセスを割り当てられているか否かを判断する。割り当てられている場合、このチェックにパス（チェックを通過）する。
・そうでない場合、チェックは失敗し、プロセスはレンダリングしない状態４４６０に移る。
要素はチェックにパス（チェックを通過）する場合にのみ示される。
判定状態４４３０に進むと、プロセス４４００は、ＵＩ要素が現在のアプリケーションモードについて有効であるか否かを判断する。ユーザのためのアプリケーションコンテキストは、複数のモードのうちの１つであり得る。これは、そのモードに必要な機能に適したＵＩを有するユーザを表す。いくつかの実施形態では、モードは、患者、スタッフおよびビジタである。このシステムは、一度に複数のモードがユーザセッションについてサポートされることが要件となった場合にこれが可能であるように設計される。チェックプロセスは以下のとおりである。
・この要素がいかなるモードにも固有でない場合、チェックにパス(チェックを通過)する。
・この要素のモードがユーザの現在のモードに対応する場合、チェックにパス(チェックを通過)する。
・そうでない場合、チェックは失敗し、プロセスはレンダリングしない状態４４６０に移る。
要素はチェックにパス(チェックを通過)する場合にのみ示される。
判定状態４４４０に進むと、プロセス４４００は、現在のユーザが十分な許可を有するか否かを判断する。各ユーザは、ダイアリ（医療／健康）データ、データボルト文書、組織構成設定、ユーザプロフィール設定等を含む、データに対する１組の許可を有する。いくつかの実施形態では、ユーザは、自身の独自のデータと共に機能する許可を暗示しており、他のユーザのデータにアクセスし、これを更新する許可を有する場合がある。この要素が、（上述したｓｉｔｅｍａｐ．ｘｍｌファイルにおいて）特定のタイプの許可に関連するものとして記録される場合、現在のユーザは、ＵＩ要素を見ることができるようになるために、その許可を必要とする。組織メンバおよびゲストのための許可決定は、以下で更に説明される。ユーザが十分な許可を有する場合、プロセス４４００は状態４４５０に進み、ＵＩ要素をレンダリングする。そうでない場合、チェックは失敗し、プロセスは、レンダリングしない状態４４６０に移る。プロセス４４００は、ユーザインターフェースを完成するように他のＵＩ要素について繰り返される。
許可計算プロセスの説明が、以下に説明される図４５および図４６と併せて提供される。このセクションは、許可関連データを記憶するのに用いられる例示的なデータベース構造を扱う。許可システムにおける許可テーブルは、割り当てることができる許可の組を定義する。このデータは、通常、静的である。例示的な許可テーブルは以下のとおりである。
Figure 2018512085
ＰａｒｅｎｔＰｅｒｍＩｄフィールドは、要求された許可を含む許可を識別するのに用いることができる親許可識別子を示す。例えば、喫煙の親許可識別子は、ダイアリであるＩｄ１２であり、Ｉｄ２８の喫煙を含む。全ての許可が使用可能であるかまたは可視であるわけではない場合があり、「可視」列がこれを制御する。
許可は、リンクテーブルを介して他のエンティティに以下のように割り当てることができる。
・ＥｘｐｌｉｃｉｔＰｅｒｍｉｓｓｉｏｎ：Ｉｄ、ＰｅｒｓｏｎＩｄ、ＰａｔｉｅｎｔＩｄ、ＰｅｒｍｉｓｓｉｏｎＩｄ、ＲｅａｄＯｎｌｙ。特定の所有者（ＰａｔｉｅｎｔＩｄ）からのデータを用いる許可（ＰｅｒｍｉｓｓｉｏｎＩｄ）を、完全なまたは読み出し専用アクセス（ＲｅａｄＯｎｌｙ）を有するダイアリの所与のユーザ（ＰｅｒｓｏｎＩｄ）に割り当てるのに用いられる。
・ＯｒｇａｎｉｚａｔｉｏｎＥｘｐｌｉｃｉｔＰｅｒｍｉｓｓｉｏｎ：Ｉｄ、ＯｒｇａｎｉｚａｔｉｏｎＩｄ、ＰａｔｉｅｎｔＩｄ、ＰｅｒｍｉｓｓｉｏｎＩｄ、ＲｅａｄＯｎｌｙ。完全なまたは読み出し専用アクセス（ＲｅａｄＯｎｌｙ）を有する所与の組織（ＯｒｇａｎｉｚａｔｉｏｎＩｄ）に特定の所有者（ＰａｔｉｅｎｔＩｄ）からのデータを用いる許可（ＰｅｒｍｉｓｓｉｏｎＩｄ）を割り当てるのに用いられる。次に、この許可によって許されるデータは、この組織のＳｔａｆｆＭｅｍｂｅｒｓが自身の役割を介して組織による適切な許可を与えられている場合、このＳｔａｆｆＭｅｍｂｅｒｓによってアクセスされ得る。
・ＰｒｏｐｏｓｅｄＰｅｒｍｉｓｓｉｏｎ：Ｉｄ、ＩｎｖｉｔａｔｉｏｎＩｄ、ＰｅｒｍｉｓｓｉｏｎＩｄ、ＲｅａｄＯｎｌｙ。招待が（別のユーザまたは組織に）送信されるとき、提案される許可の組がこれに関連付けられる。このテーブルは、招待に対する許可のマッピングを含む。招待プロセスの完了に成功すると、これはＥｘｐｌｉｃｉｔＰｅｒｍｉｓｓｉｏｎまたはＯｒｇａｎｉｚａｔｉｏｎＥｘｐｌｉｃｉｔＰｅｒｍｉｓｓｉｏｎに変換される。
・ＲｏｌｅＰｅｒｍｉｓｓｉｏｎ：Ｉｄ、ＲｏｌｅＩｄ、ＰｅｒｍｉｓｓｉｏｎＩｄ、ＲｅａｄＯｎｌｙ。許可を役割に割り当てる。役割の組織は、役割と許可との間のこのマッピングを制御する。これは、いずれのスタッフメンバがいずれの役割のメンバであるか、およびいずれのスタッフメンバがいずれの患者グループに属するかも制御する。
・ＰａｔｉｅｎｔＧｒｏｕｐ：Ｉｄ、Ｎａｍｅ、ＯｒｇａｎｉｚａｔｉｏｎＩｄ、ＵＩＤ、Ｄｅｓｃｒｉｐｔｉｏｎ。ＰａｔｉｅｎｔＧｒｏｕｐは単一の組織（ＯｒｇａｎｉｚａｔｉｏｎＩｄ）に属する。組織は、いずれの患者（所有者）が各患者グループに属するかを制御する。
・ＰａｔｉｅｎｔＴｏＰａｔｉｅｎｔＧｒｏｕｐＬｉｎｋ：ＰａｔｉｅｎｔＩｄ、ＰａｔｉｅｎｔＧｒｏｕｐＩｄ。患者グループに対する患者（所有者）の（患者グループを所有する組織によって行われる）割り当てを記録するリンクテーブル。
・ＳｔａｆｆＭｅｍｂｅｒＴｏＰａｔｉｅｎｔＧｒｏｕｐＬｉｎｋ：ＳｔａｆｆＭｅｍｂｅｒＩｄ、ＰａｔｉｅｎｔＧｒｏｕｐＩｄ。患者グループに対するスタッフメンバの（患者グループを所有する組織によって行われる）割り当てを記録するリンクテーブル。スタッフメンバは、自身が共通患者グループを共有している場合にのみ所有者（患者）のデータにアクセスすることができる。
・ＳｔａｆｆＭｅｍｂｅｒＴｏＲｏｌｅＬｉｎｋ：ＳｔａｆｆＭｅｍｂｅｒＩｄ、ＲｏｌｅＩｄ。役割へのスタッフメンバの（役割を所有する組織によって行われる）割り当てを記録するリンクテーブル。スタッフメンバは、自身の役割から、アクセスすることを望むデータに適した許可を継承する場合にのみ、所有者の（患者）のデータにアクセスすることができる。
＜許可階層＞
いくつかの実施形態では、許可階層は以下のとおりである。
組織
患者管理
スタッフ管理
システム管理
報告
患者
プロフィール
通信
アカウント
アクセス
管理アカウントアクセス
ダイアリ
アレルギー
飲酒
身体活動
環境
状態
予防接種
実験結果
ライフイベント
薬剤
気分
栄養
痛み
ダイアリメモ
患者ストレス
睡眠
喫煙
症状
治療
バイタルサイン
臨床メモ
バイタル
身体測定値
感情
データボルト
文書アクセス
＜許可計算＞
ダイアリのユーザが所有者のダイアリ内のデータを閲覧または変更することを望むとき、アプリケーションは、現在のユーザが、これを行う許可を有するか否かをチェックする必要がある。ダイアリ許可は、アクセスされるデータの種類、そのアクセスが閲覧のみを要求するか否か、またはダイアリに対する変更（レコードの作成、更新または削除）を伴うか否かを指定する。アプリケーションは、どの種類のデータがアクセスされるか、およびユーザが編集しているか、閲覧しているのみであるかを計算すると、以下のプロセスを辿り、アクセスが可能にされるべきか否かを判断することができる。ユーザはスタッフメンバまたはゲストのコンテキストで役割を務めることになり、プロセスはこの区別に基づいて異なる。
図４５は、組織の特定のスタッフメンバが所有者のデータにアクセスを有するか否かを許可に基づいて判断するためのプロセス４５００の実施形態を示すフローチャートである。いくつかの実施形態では、プロセスは、図２Ａに示すシステム１００において実行することができる。このプロセス４５００は、組織のスタッフメンバ（例えば、医者）が所有者からの任意のダイアリデータにアクセスを試行するときに辿られる。
所与の組織のスタッフメンバが所有者のダイアリからのデータのアイテムへのアクセスを試行するときの開始状態４５１０から始まり、プロセス４５００は判定状態４５２０に移り、この判定状態４５２０において、スタッフメンバおよび所有者がアクセスグループを共有するか否かの判断が行われる。このアクセスグループは、いくつかの実施形態では患者グループである。スタッフメンバは、所与の所有者（患者）を含むアクセスグループに割り当てられなくてはならない。割り当てられない場合、組織は、そのグループ（したがって、その患者）にアクセスする権限をスタッフメンバに与えておらず、このため、状態４５６０において許可が拒絶される。
判定状態４５３０に進むと、プロセス４５００は、役割が許可を有するか否かを判断する。スタッフメンバが属する役割ごとに、組織が要求に合致する許可を与えたか否かをチェックする。これは、特定の許可が与えられたか、または上記で説明したような、要求された許可を含む任意の許可が与えられたことを意味する。役割が許可を有していない場合、状態４５６０においてアクセスが拒絶される。
状態４５４０に進むと、プロセス４５００は、組織が許可を有するか否かを判断する。所有者が、要求に合致する許可を特定の組織に与えたか否かのチェックが行われる。これは、特定の許可が与えられたか、または要求された許可を含む任意の許可が与えられたことを意味する。組織が許可を有していない場合、状態４５６０においてアクセスが拒絶される。判定状態４５２０、４５３０および４５４０における全ての以前の要件が満たされている場合、スタッフメンバは、所有者および組織の両方によってアクセスを付与される。したがって、これらのスタッフメンバは要求されたデータを閲覧することを許可される。判定状態４５２０、４５３０および４５４０におけるチェックは任意の順序で行うことができることに留意されたい。
図４６は、特定のゲストが所有者のデータに対するアクセスを有するか否かを許可に基づいて判断するためのプロセス４６００の実施形態を示すフローチャートである。いくつかの実施形態では、プロセスは、図２Ａに示すシステム１００において実行することができる。このプロセス４６００は、ゲストが所有者からの任意のダイアリデータにアクセスを試行するときに辿られる。
ゲストが所有者のダイアリからのデータのアイテムへのアクセスを試行するときの開始状態４６１０から始まり、プロセス４６００は判定状態４６２０に移り、この判定状態４６２０において、ゲストが許可を有するか否かの判断が行われる。プロセス４６００は、ゲストが所有者によって、要求に合致する許可を与えられているか否かをチェックする。これは、特定の許可が与えられているか、または要求された許可を含む任意の許可が与えられていることを意味する。判定状態４６２０において、ゲストが許可を有すると判断される場合、プロセス４６００は状態４６３０に進み、ゲストは所有者によってアクセスを付与される。ゲストは、要求されたデータを閲覧することを許可される。判定状態４６２０においてゲストが許可を有していないと判断される場合、プロセス４６００は状態４６３４に進み、アクセスが拒絶される。ゲストのためのこのプロセス４６００は、スタッフメンバのためのプロセスよりも単純である。なぜなら、許可が所有者によって直接ゲストに与えられ、それらの間にリンクを形成するためである。
＜実施の詳細および動的ユーザインターフェース＞
許可ベースのセキュリティが複数の層において実施される。いくつかの実施形態では、ユーザインターフェースが、ユーザに利用可能なオプションのみを示すことが意図され、例えば、現在のユーザがデータボルトを見る許可を有していない場合、ナビゲーションバーにおけるデータボルト制御は可視であるべきでない。
いくつかの実施形態では、サイトレイアウトは、ＸＭＬにおいて定義されるフレキシブルサイトマップによって定義される。例示的なサイトマップ（簡略化されたもの）は以下のとおりである。
<sitemap>
<group title="Diary" resourcekey="Navigation_Diary" modes="Patient">
<item title="Pulse" resourcekey="Navigation_Pulse" controller="Pulse"
action="Index" area="PatientDiary" cssclass="pulse">
<systemmoduleitems />
</item>
<item id="Timeline" title="Timeline" resourcekey="Navigation_Timeline"
controller="Timeline" action="Index" area="PatientDiary" cssclass="timeline"/>
<item title="Data Vault" resourcekey="Navigation_DataVault" controller="DataVault"
action="Index" area="PatientDiary" cssclass="datavault"/>
</group>
<group title="Connections" resourcekey="Navigation_Connections">
<item title="User Management" controller="Users" action="Index"
area="Organization" modes="Staff" permission="StaffManagement"
cssclass="user-management">
<linkeditem controller="PatientGroups" action="Index" area="Organization" />
<linkeditem controller="Roles" action="Index" area="Organization" />
<linkeditem controller="Staff" action="Index" area="Organization" />
</item>
<item title="Invitations" controller="Invitation" action="Index"
area="Organization" modes="Staff" permission="PatientManagement"
cssclass="invitations">
<linkeditem controller="Invitation" action="Completed" area="Organization" />
</item>
<item title="Owners" controller="StaffProfile" action="Owners" area="Organization"
modes="Staff" permission="PatientManagement" cssclass="owners"/>
<item title="Guests" controller="AccessGiven" action="Index" area="PatientAccount"
modes="Patient" permission="PatientAccess" cssclass="guests">
<linkeditem controller="AccessGiven" action="Friends" area="PatientAccount"/>
</item>
<item title="Owners" controller="AccessReceived" action="Index"
area="PatientAccount" modes="Patient" permission="PatientAccess" cssclass="owners"/>
<item title="Care Team" resourcekey="Navigation_CareTeam" controller="CareTeam"
action="Index" area="PatientDiary" cssclass="careteam"
requiresenabledfeature="CareTeam"/>
</group>
<group title="Admin" permission="StaffManagement" modes="Staff" >
<item title="Organization Profile" controller="Profile" action="Index"
area="Organization" permission="SystemManagement" cssclass="organization-profile"/>
</group>
<group title="Account" resourcekey="Navigation_Account">
<item title="Profile" controller="Profile" action="Index" area="Visitor"
modes="Visitor" cssclass="profile">
<linkeditem title="Password" controller="Profile" action="ChangePassword"
area="Visitor"/>
</item>
<item title="Profile" controller="MinimalProfile" action="Index"
area="PatientAccount" modes="Patient" permissionabsent="Profile" cssclass="profile"/>
<item title="Notification" controller="Notification" action="Index"
area="PatientAccount" modes="Patient" permission="Profile" disabled="true"
cssclass="notification"/>
<item title="Preferences" controller="Settings" action="Index"
area="PatientAccount" modes="Patient" permission="Profile" cssclass="preferences"/>
</group>
</sitemap>
サイトマップは、ユーザインターフェースの各部分が示されるべきときを定義する。サイトマップは、アイテムごとに、タイトルテキスト、（エリア、コントローラ、およびアクション属性を介した）対応するアクション、およびいずれの状況においてこのアイテムが示されるべきかを定義する。エリア、コントローラおよびアクションという用語は、全て、ＡＳＰ．Ｎｅｔ ＭＶＣ規格の用語であり、例えば以下のように用いられる。＜ｉｔｅｍ ｔｉｔｌｅ＝“Ｕｓｅｒ Ｍａｎａｇｅｍｅｎｔ” ｃｏｎｔｒｏｌｌｅｒ＝“Ｕｓｅｒ” ａｃｔｉｏｎ＝“Ｉｎｄｅｘ” ａｒｅａ＝“Ｏｒｇａｎｉｚａｔｉｏｎ” ｍｏｄｅｓ＝“Ｓｔａｆｆ” ｐｅｒｍｉｓｓｉｏｎ＝“ＳｔａｆｆＭａｎａｇｅｍｅｎｔ” ｃｓｓｃｌａｓｓ＝“ｕｓｅｒ−ｍａｎａｇｅｍｅｎｔ”＞。コアアプリケーション機能は、複数のエリアに分割される。（ここで示す）エリアの例は「組織」である。このエリアは、組織ユーザに固有の全ての機能を含む。この場合、このアイテムは、（この組織のための）ユーザ、すなわち、患者グループ、役割およびスタッフの管理を含む。現在のログインが組織のコンテキストで動作していない場合、組織エリアは関連していないので、このアイテムは示されない。「ユーザ」は組織エリア内のこの特定のコントローラの名称であり、インデックスは、このコントローラに対するアクションである。ユーザコントローラは、組織エリア内の全てのユーザベースの機能の管理者ある。インデックスは、このコントローラに対する特定のアクションであり、この場合、ユーザがアプリケーションのこのエリアに入るときに示されるメインのデフォルトページである。まとめると、現在のユーザがＳｔａｆｆＭａｎａｇｅｍｅｎｔ許可（ｐｅｒｍｉｓｓｉｏｎ＝“ＳｔａｆｆＭａｎａｇｅｍｅｎｔ”）を有するスタッフメンバである場合（ｍｏｄｅ＝“Ｓｔａｆｆ”）、これらのユーザは、エリア「組織」においてコントローラ「ユーザ」に対するアクション「インデックス」を見ることができる。
「モード」は、例えば以下の、現在ログインしているユーザのタイプに基づいて可視性を制御する。
・患者：所有者が自身のダイアリを閲覧している
・ビジタ：ゲストが所有者のダイアリを閲覧している
・スタッフ：スタッフメンバがアプリケーションを使用しており、（適切な許可を有する）組織管理機能を見ることが可能であり得る
可視性は許可の存在によっても制御される。「ｐｅｒｍｉｓｓｉｏｎ」および「ｐｅｒｍｉｓｓｉｏｎａｂｓｅｎｔ」属性を用いて、それぞれ所与の許可が存在しているかまたは不在であるときにのみユーザインターフェース特徴を示すことができる。いくつかのアプリケーション特徴が現在有効にされているか否かに基づいて、ユーザインターフェースコンポーネントの可視性を制御する「ｒｅｑｕｉｒｅｓｅｎａｂｌｅｄｆｅａｔｕｒｅ」属性にも留意されたい。
＜バックエンド許可強制＞
ユーザに対し、関連する特徴組のみを提示するために、ＵＩを変更することに加えて、バックエンドは許可制限を強制する。これは、主に、以下の例等におけるＡＳＰ．ＮＥＴフレームワークにおけるＭＶＣコントローラへの属性の適用によって主に達成される。
[PatientRequired]
[PatientAuthorize(PermissionsIdentity.Profile, true)]
public class PatientProfileController:
PasswordEnabledMultiModelDomainController<Patient, PatientListViewModel,
PatientSummaryViewModel, PatientSummaryViewModel>
{
...
}
ＰａｔｉｅｎｔＲｅｑｕｉｒｅｄ属性は、現在のユーザが現在の患者コンテキストを有しなくてはならないという要件を強制する。自身のダイアリを閲覧している所有者または別の所有者のダイアリを閲覧しているゲストは、この要件を満たす。唯一の許可が組織管理に関連する許可であるスタッフメンバは、患者のコンテキスト内で動作せず、このためこの例においてアクセスを拒否される。
ＰａｔｉｅｎｔＡｕｔｈｏｒｉｚｅ属性は、現在のユーザが進むために現在のダイアリについて有しなくてはならない許可を指定する。この場合、「プロフィール」許可が存在しなくてはならない。更に、ユーザが完全な許可を有しなくてはならず、読み出し専用では十分でないことが指定される（この例では、第２のパラメータ「真」）。
更に、ＭＶＣコントローラにおけるある特定のアクションが、コントローラが読み出し専用許可しか必要としない場合、フルアクセスを必要とすることが起こり得る。以下の例を参照されたい。
[PatientAuthorize(PermissionsIdentity.LabResults, false)]
public class LabResultController : PatientDataControllerBase<PatientTestResultLog,
LabResultListModel, LabResultViewModel, LabResultViewModel>
{
...

public override ActionResult Index()
{
return View(UserApplicationContext.State.SelectedPatient.PatientId);
}

[NoCache]
[HttpGet]
[LHDAuthorizeRequireWrite]
public override ActionResult Edit(int id)
{
return HttpNotFound();
}

...
}
上記の例では、ＬａｂＲｅｓｕｌｔＣｏｎｔｒｏｌｌｅｒのアクションへのアクセスは、デフォルトで、読み出し専用であろうと、フルアクセスであろうと、「ＬａｂＲｅｓｕｌｔｓ」許可のみを必要とする。一方、Ｅｄｉｔアクションがユーザにアクセス可能になるには、フルアクセス「ＬａｂＲｅｓｕｌｔｓ」許可が存在しなくてはならず、読み出し専用バージョンは十分でなく、結果としてアクションが拒絶される。
＜許可に基づくユーザインターフェースの更新＞
所有者のダイアリのビューは、誰が閲覧しているかに依拠して異なることができる。ダイアリの所有者は、制約なしでダイアリ全体を見ることができる。招待を介してダイアリを閲覧するユーザ（例えば、ゲストおよび組織のスタッフメンバ）は、所有者によって（およびスタッフメンバの場合、組織によって）設定された許可によってダイアリのサブセットに制約された自身のビューを有することができる。これは、各事例において、異なるユーザインターフェース（ＵＩ）エクスペリエンスとして現れる。
＜ユーザインターフェースに対する影響＞
図４７は、示されるようにある特定の許可を設定した所有者が見るインターフェース画面を示す画面表示の例である。図４７の例において、所有者はある特定の許可を設定した。アクセスが睡眠および喫煙モジュールにのみ与えられることに留意されたい。睡眠は読み出し専用であり、完全な書き込みアクセスが喫煙に与えられる。このゲストがこのダイアリを閲覧することを選択するとき、ＵＩにおいてこのゲストが見るオプションは制限されている。
図４８は、所有者が「プラス」アイコンをクリックして、いずれのモジュールに自身がデータを追加することができるかを見るときに、データモジュールのリストを表示するためのインターフェースを示す画面表示の例である。図４８は、所有者が「プラス」アイコンをクリックするときに示される例示的なリストの一部分を示す。全てのモジュールは図４８に示すドロップダウンリストに示される。他の実施形態では、プラスアイコンは、新たなデータの入力等のための入力画面を開く。
図４９は、ゲストが図４８のダイアリについて同じアクションを実行するときに関連アイテムに制約されたモジュールのリストを表示するためのインターフェースを示す画面表示の例である。全てのモジュールは図４８に示すドロップダウンリストに示される。一方、ゲストがこのダイアリについて同じアクションを実行する場合、ゲストの許可は、ゲストが喫煙モジュールのためのデータを入力することのみを可能にし、このためリストは関連アイテムに制約される。
図５０は、ダイアリのゲストが見るパルスページのためのインターフェースを示す画面表示の例である。モジュールからのデータを閲覧するとき、同様のルールが適用される。いくつかの実施形態において、パルスページは、所有者のダイアリのためのダッシュボードであり、ユーザが自身のダイアリの重要な態様を１つのページに配置することを可能にする。このため、所有者およびゲストは、アプリケーションを通じてナビゲートする必要なく、自身に何が関連しているかを一目で見ることができる。図５０のこのダイアリのためにゲストが見るパルスページにおいて、ゲストが閲覧許可を有するモジュールのみを選択することができる。
図５１は、選択されたが、許可制限に起因して全てのモジュールについてデータを取り出すことができないタイムラインのためのインターフェース画面を示す画面表示の例である。図５１のタイムラインビューにおいて、選択されたが、許可制限に起因してデータを取り出すことができない任意のタイムラインモジュールが、ある特定のデータがユーザに利用可能でないことをそのユーザに通知するメッセージを表示する。
図５２は、所有者のデータの時間ベースのサマリを示すタイムラインページのためのインターフェース画面を示す画面表示の例である。ユーザは、（ユーザが所有者でない場合、許可の下で）いずれのモジュールを閲覧するかを選択することができる。タイムラインページは、所有者のデータの時間ベースのサマリを示す。データは、線形のカレンダ状のビューで示され、Ｘ軸上に時間を有し、Ｙ軸上に異なるモジュール（およびモジュール内のデータ）を有する。
タイムラインは、特定のダイアリを含むデータの、時間的に相関した集約したビューである。タイムラインの表示域（現在表示されている領域）は、（例えば、日、週、月および年によって）ズームインおよびズームアウトすることができ、時間を通じて前後にパンすることもできる。ダイアリデータの任意のサブセットを閲覧用に、閲覧者の需要に合う順序で選択することができる。ある特定の実施形態では、モジュールは、ユーザによって選択された順序で、例えば、ドラッグアンドドロップ再順序付けまたは他の再順序付け方法等で配置することができる。
タイムラインは、異なるデータタイプ間の相関を特定する能力を提供し、閲覧者が、ダイアリが表す個人の状態／履歴に迅速に精通する能力を提供する。タイムラインは、データ表示が、現在の閲覧者の目標／関心を満たすように容易に構成されるための能力も提供し、健康履歴の任意の時点において任意の特定のデータに容易に／迅速にナビゲートする能力を提供する。
通常、患者の医療情報は、ＸＭＬデータエクスポートファイルを用いて、カンマ区切り（ＣＳＶ）ファイル内に収集され、次に、スプレッドシートにおいて手作業で表示される。そのようなスプレッドシートの異なるビューは、時間相関を極端に困難にする。なぜなら、日付は、薬品名でソートされた場合、順序がバラバラである可能性があるためであり、用量および薬剤の任意の変更についても同様である。他方で、他のソート順は、薬剤名が混ざって、ビューが一層混乱することを意味する。最新技術の全体的影響により、判定および判断が、時間がかかり、直観的でなく、複雑で、通常特殊な専門知識を要するものとなる。
対照的に、図５１および図５２に示すのは、関連データを、特に直観的であり、全てのケアチームメンバにとって有用なものとするように提供する表示フォーマットの例である。タイムラインは、所有者のための各モジュール、およびゲストまたは組織におけるスタッフメンバが許可を付与されたモジュールを表示する。各モジュールは、リストビューまたはグラフビュー等の更なる制御、ならびに例えば、１）ソート基準（Sort by）、２）ビュー基準（View by）、および３）色分け基準（Color by）等のドロップダウンメニューを有することができる。
モジュールデータは、生理学的測定値、薬、投与量、開始および停止等を示すシンボルの一貫性のある組を用いて表示することができる。いくつかの実施形態では、各行は、１つの変数（例えば、薬）、またはオプションで、１組の関連する変数のためのデータを含む。他の実施形態では、１つの変数のためのデータを複数の行に表示することができる。これらの行の組は、付与された許可に従って画面またはページ上に表示される。これらの行は、全てが同じ開始時間、終了時間およびタイムスケールを有するように同期させることができる。これは、ユーザがデータ間の相関および他の関係を見ることを可能にする。従来のシステムでは、これらの相関および関係は、異なるソースによって提供され別個に記憶されるデータから得られるため、理解するのが困難または不可能であった。
タイムライン表示は、所有者の制御の下で細かい粒度での３つの制御レベル、すなわち、１）招待の送信および受入れ、２）グループレベルにおける、およびモジュール（カテゴリまたはタイプ）レベルまでのアクセスタイプ（なしもしくはプライベート、読み出し、または編集）の選択、および３）モジュールレベルまでの許可、を有する。更に、ユーザ（例えば、ゲスト）は、表示のための時間枠を選択する際、タイムラインレベルの制御を有し、例えば、リストまたはグラフビュー、ならびにフィルタリング用のメニュー、すなわち、ビュー基準、色分け基準、およびソート基準を選択する際、モジュールレベルの制御を有する。いくつかの実施形態では、データフィルタリングは、例えば、機密データ、臨床医が入力したデータ対非臨床医が入力したデータ、および／または特定のユーザによって入力されたデータのフィルタリング等のオプションを含む。他の実施形態では、他のフィルタリングオプションを用いることができる。いくつかの実施形態では、モジュールのための「ソート基準」ドロップダウンは、例えば、名前、日付、昇順または降順のためのオプションを含むことができる。モジュールのための「ビュー基準」ドロップダウンは、例えば、平均、最小値または最大値のためのオプションを含むことができる。モジュールのための「色分け基準」ドロップダウンは、例えば、そのセル内に表現される様々な量に依拠してセルを色分けするためのオプションを含むことができる。
したがって、所有者は、自身のデータに誰がアクセスすることができるか、アクセスのタイプおよび許可の全てを、粒度のカテゴリまたはモジュールレベルまで制御する。ユーザが少なくとも閲覧の許可を有していないモジュールが、ユーザがモジュールデータを閲覧する許可を有していないことの記述を表示することができる。
いくつかの実施形態では、表示画面は、患者が服用している薬剤、および薬剤投与計画に対する変更に関する明確な情報を提示する。これらの画面は、複雑な薬剤投与計画をより良好に習得し、閲覧し、解析するための方法、および経時的なそれらの相対的変化を示す。
これらの実施形態において、薬剤の開始日、およびいくつかの実施形態では、薬剤の停止日が示され、薬剤名、薬剤量、および薬剤変更のうちの１つ以上と相関付けられることに留意することができる。これによって薬剤データの読み出し、理解および判断を行うのが、大幅に容易にかつ迅速になる。これは、専門家（希少で高価な臨床薬理学者等）のみでなく、医者、臨床医、経験の浅いスタッフ、研究者、介護者、患者および患者の家族、ならびに任意の他の招待および許可された関係者もデータを閲覧し理解するのを可能にすることができる。
いくつかの実施形態では、限定ではないが、患者の年齢、性別、所在地、職業、ライフスタイル選択、ライフイベント、既往症を含む基礎健康状態、遺伝的形質識別子、症状、治療、薬、または他の健康関連の変数を含むデータを示すタイムラインまたは他のグラフィックを表示するステップが提供される。他の実施形態では、データは、ライフスタイルデータ、心理社会的データ、環境データおよび遺伝データと共に臨床データを含む。このステップは、上述した患者変数にわたって薬剤または治療の成功を評価し、禁忌を発見し、または他の形で薬剤の有効性および／または患者の反応を評価する際に有用とすることができる。
例示的なタイムライン画面表示は、特定の患者のための医療情報のサマリページを示し、これは、時間相関を用いて、患者の背景／症状情報に対しプロットすることができる。そのような表示の利点は、限定ではないが、患者の履歴の臨床的理解を高め、見落としおよびミスを低減し、健康転帰および患者の関与を改善することを含む。図５２は、可能な薬またはそれらの投薬計画における変更に対する患者の反応の、理解が容易なグラフィック解析を含むことができる。そのようなグラフィック解析は、生じ得る禁忌および可能性の高い有害作用源を特定するのに役立つ。
健康治療の代替的な形式は、図５２に示すような個々の患者について、または公衆健康単位で（図示せず）、従来の治療計画とより容易に比較することができる。システムおよび方法によって可能にされる最適化のための他の分野は、限定ではないが、栄養食品および栄養、ライフイベント、ライフスタイル、従来の補完代替医療、治療計画、患者の入力およびフィードバック、ならびに他の医療専門家の入力およびフィードバックの最適化を含む。
様々なデータセット（例えば、臨床試験、薬剤、バイタルサイン、症状等）が、各特定の患者のための単一のページサマリ上にレンダリングされる。データセットは、異なる色または他のしるしで示された異なる関係者が発生源のデータを用いてグラフィックで要約することができる。
タイムラインページが画面サイズよりも大きい場合であっても、ユーザは、関連する遅延および隣接部分の閲覧の困難を伴って他のウェブページへの追加のリンクをナビゲートしなくてはいけないのではなく、全ての所望のデータを表示するのにスクロールさえすればよい。好ましくは、上述したモジュールまたは医療情報のカテゴリの全てがページ上に提供されるが、いくつかの場合、そのようなデータのサブセットが提示されてもよい。
システムおよび方法は、分散したデータセット内で容易に見ることができない場合がある問題を強調する。理解がより容易な表示は、患者薬剤投与計画、バイタル、実験結果、兆候および症状、ならびに他の背景健康情報データのより迅速でより総合的な理解を支援する。
システムおよび方法の利点は、患者および介護者（例えば、家族および他の主要な介護者）を含む、適切な許可を有するヘルスケアチーム（集学的ケアチーム）の全てのメンバ、ならびに自動医療データフィードが、全て、自身のそれぞれのデータを入力することができ、依然としてこれを同じ単一のサマリページ上に揃えて表示することができることである。この機能は、基本的に、そのケアチームの全てのメンバが、任意のタイムスケールにわたって全てのデータを参照して患者の状態を全体として閲覧する能力を変更する。
システムおよび方法は、患者または患者の家族がケアチームの一部になることを可能にすることを含む、集学的ケアチームのための協働ツールとしての役割を果たす機能を有し、患者または患者の家族に、患者の状況にとって重大なリスクおよび変更を警告する。
患者の同意を通じて、患者のケアチームの複数のメンバを患者のレコードに招待し、全ての権限付与されたチームメンバが、（付与された許可レベルに依拠して）患者の医療ステータスの一部または全てを閲覧することを可能にする。この招待機能は、単一のページにおける全てのケアチームメンバのデータ入力をレンダリングおよび表示するシステムおよび方法の機能と組み合わせて、個々の決定および協調を通じた決定の双方にとって、ケアチームの協調および有効性を大幅に増大させる。
図５３は、各モジュールのデータと共に機能するように用いることができる、そのモジュール用のページを表示するためのインターフェースを示す画面表示の例である。各モジュールは、そのモジュールのデータと共に機能する、例えば、新たなエントリを追加する、フィルタを介してエントリを突き止める、以前のエントリを削除または変更するように用いることができる対応するページを有する。
図５４は、所有者のタイムラインをナビゲートするためにユーザが見るインターフェース画面の一部分を示す画面表示の例である。いくつかの実施形態では、この部分は、ユーザが、日、週、月または年、および集約レベル選択に対応する開始日または終了日から集約レベルを選択することを可能にする。他の実施形態では他の集約レベルを用いることができる。
図５５は、可能な集約レベルの例を示すタイムラインのためのインターフェース画面のカレンダバー部分を示す画面表示の例である。日、週、月または年、および集約レベル選択に対応する開始日または終了日からの集約レベル選択を含むタイムラインディスプレイに対する要求を受信した後、システムはカレンダバーをレンダリングする。これは、受信した要求に従って、２つの行部分を有するカレンダバーをレンダリングし、集約レベル選択に対応する開始日または終了日に従って、最下行部分が日付を有する一連のブロック（例えば、日ごとの集約レベルの場合、１２月２９日、週ごとの場合、９月２５日〜３１日、月ごとの場合、５月、年ごとの場合、１９９４年）を表示するようにすることを含むことができる。これは、選択された集約レベルに一連のドットを表示するように最上行部分をレンダリングすることを更に含むことができる。ここで、明るいドットは、選択された集約レベルにおける期間にわたる所有者データの欠如を表し、暗いドットは、その期間にわたる所有者データの存在を（例えば、日ごと、週ごと、月ごとまたは年ごとに）表す。ある特定の集約レベルにおいて、データの存否についてタイムフレームを特定するために対応する月または年もドットで表示され、例えば、日ごとの集約レベルの場合、月の組が表示され、週ごとまたは月ごとのレベルの場合、年の組が表示される。レンダリングは、カレンダバーの最上行部分が、最下行部分における日付に対応するドットにわたって強調されたブロックを表示するようなレンダリングを更に含むことができ、それによって、カーソルが最上行部分の別の部分の上をホバリングするように動かされるとき、ホバリングカーソルの位置に対応して別の強調されたブロックが表示され、ホバリングカーソルの位置において（例えば、マウスまたはパッドを用いた）クリックイベントが受信される場合、タイムラインが、クリックの日付に対応し、選択された集約レベルに従うデータを表示する。ダイアリはデータイベントの厳密な日付の入力をサポートする。ダイアリは、データイベントのための厳密な日時を入力する。したがって、他の実施形態では、タイムラインは、時間ごとのまたは１日のタイムスケールの他の部分におけるデータアイテムを表示することができる。
図５６は、週ごとの集約レベルでタイムラインデータマップの例を示す、タイムラインのためのインターフェース画面の一部分を示す画面表示の例である。データマップは、選択された集約レベルにおける一連のドットを表示することができ、ここで、明るいドットは、選択された集約レベルにおける期間にわたる所有者データの欠如を表し、暗いドットは、その期間にわたる所有者データの存在を表す。この例では、対応する年も、データの存否についてタイムフレームを特定するドットと共に表示される。タイムラインデータマップの最下の２つの例は、データマップの別の部分上をホバリングするハンドアイコン（カーソルを表す）を示し、ホバリングカーソルの位置に対応する別の強調されたブロックが表示され、ホバリングカーソルの位置においてクリックイベントが受信される場合、タイムラインが、クリック日時に対応し、選択された集約レベルに従うデータを表示するようになっている。
＜バージョン追跡＞
システム１００は、各所有者のデータのバージョン識別子を追跡する。ユーザが、データのある特定のタイプまたはカテゴリについて書き込み許可を有するとき、システムは、様々な情報を記録する。いくつかの実施形態において、誰が何のデータを編集したか、およびその編集が何であったか、および全ての認可されたユーザからのこれらの変化は、各ダイアリにおける編集／バージョン追跡システムにおいて全て恒久的に記録される。これらの変化は、データを閲覧する許可の正しいレベルを有すると仮定して、特定の所有者のダイアリの各ユーザに可視である。更に、編集のための書き込み機能を有するユーザは、更なる編集を設け、全ての権限付与されたユーザが見ることができるように、同様にログを取られた結果を有することができる。いくつかの実施形態では、コアデータベースは、変更されたエンティティが現在最新バージョンであるか否かを検証する機能を提供する。そのエンティティがフェッチされてから変更されている場合、ユーザは通知を受け、保存が否認され得る。
図７０は、編集およびバージョン追跡のためのプロセス７０００の実施形態を示すフローチャートである。いくつかの実施形態において、プロセスは、図２Ａに示すシステム１００において実行することができる。このプロセス７０００は、ユーザ、例えばデータの所有者、ゲスト、または医者等の組織のスタッフメンバが、所有者のためのダイアリデータの任意の部分に対し追加または編集を行うときに辿られる。
編集／バージョン追跡は、コアデータベースにおいてサポートされるが、編集プロセス中のバージョン識別のメンテンナンス、および関連する警告／エラーのユーザへの提示を含む様々な理由でユーザインターフェースによってハンドリングされる。
状態７０１０において開始して、適切な書き込み許可を有するユーザは、所有者のデータのエンティティの編集を開始する。状態７０２０に進み、プロセス７０００は、コアデータベースからエンティティを取り出す。バージョン番号および全ての他のデータ（例えば、改版のデータおよび時点、ならびに編集を実行している人物の識別子）が、コアデータベースにおけるエンティティ自体の一部として記憶される。いくつかの実施形態では、エンティティは、例えば、モジュール（カテゴリ）データ等のデータベースにおける任意のデータアイテムとすることができる。エンティティをバージョン管理可能にするために行う必要があるのは、コアデータベース内に要求されたコラムを追加することのみである。構築システムは、これらのフィールドが存在することを認識し、その時点以降、そのエンティティのためのバージョン管理サポートを導入する。いくつかの実施形態では、バージョン番号はエンティティごとである。
状態７０３０に続き、ダイアログボックスまたはウィンドウが、エンティティ改版番号と共にエンティティ編集データで開放される。状態７０４０において、ユーザは、エンティティを編集し（例えば、変更し、一部分を削除し、またはデータを追加する）、このエンティティをダイアログ内に保存する。状態７０５０に移り、エンティティは変化し、サーバにおいて元の改版番号が受信される。判定状態７０６０に進み、プロセス７０００は、改版番号がデータベースとダイアログとで一致するか否かを判断する。一致しない場合、プロセス７０００は状態７０７０に移り、ユーザに、（所有者のデータの）エンティティが第１のユーザによってフェッチされてから別のユーザによって変更されたことを警告し、変更を中止する。一方、判定状態７０６０において判断されるように、改版番号がコアデータベースとダイアログとの間で一致する場合、プロセス７０００は状態７０８０に進み、変更を保存し、改版番号をインクリメントする。
エンティティについての編集関連データを記憶した結果として、システムは、エンティティアイテムに対応するデータのカテゴリのための適切な読み出し許可を有する任意のユーザに対し、そのデータの全ての以前の改版の変更履歴を表示することができる。
＜ウィジェット＞
ウィジェットは、ユーザのオプションで表示画面上に示すかまたは隠すことができ、タイムラインおよびパルスページの双方においてコンポーネントを参照するのに用いることができる、システムにおける主要コンポーネントである。いくつかの実施形態では、ウィジェットは、ユーザが、例えば、糖尿病、体重減少および高血圧から選択することができるテンプレート化されたビュー（データ結合）の所定のリストを提供する。通常、このアプリケーション内において、ウィジェットは、ページに追加するかまたはページから除去することができるユーザインターフェースコンポーネントである。上述したように、いくつかの実施形態では、パルスページは、所有者のダイアリのためのダッシュボードであり、ユーザが１つのページに自身のダイアリの重要な態様を配置することを可能にする。これは、所有者およびゲストが、アプリケーション全体にわたってナビゲートする必要なく、何が自身に関連しているかを一目で見ることを可能にする。ウィジェットは、ユーザが、自身の独自の需要に固有であり、ウィジェットライブラリから自身のビューに追加することができる複数のビューを保存することを可能にする。ユーザは、所望に応じて、ウィジェットを自身のビューの各々に対し追加し、順序付けし、除去することができる。
いくつかの実施形態では、ダイアリ内に含まれるモジュールの各々をレンダリング出力することができるウィジェットの所定の組が存在する。基本的なウィジェットタイプは、比較可能な日付−時間データウィジェット（例えば、運動ログ、薬剤ログ）、比較不可能な日付−時間データウィジェット（例えば、ライフイベント、メモ）、時間範囲データウィジェット（例えば、病気）およびアバターウィジェットを含む。進化したモジュールに固有のウィジェットは、後の時点において展開および追加することができる（例えば、投薬計画）。更に、複合ウィジェット（例えば、複数のデータソースを共に表示するウィジェット）は、後の時点で展開および追加することができる。システムは、各ウィジェットの表示モードを構成する能力を提供することができる（例えば、直線グラフ、バーグラフまたはデータ）。システムは、例えば、強度および／または持続時間を示すデータの部分次元を構成する機能も提供する。いくつかの実施形態では、ウィジェットのデフォルト集合がユーザのために提供される。デフォルトパルスページの例は、ウィジェット、最新の新規ダイアリエントリ、最新のユーザアクティビティ、最新の服用された薬剤、および最新の物理的アクティビティを含むことができる。
ウィジェットは、例えば、機密データ、臨床医が入力したデータ対非臨床医が入力したデータ、および／または特定のユーザによって入力されたデータのフィルタリング等のデータフィルタリングオプションを有することができる。他の実施形態では他のフィルタリングオプションを使用することができる。
タイムラインの任意の数の閲覧者が、自身が見る許可を付与された基礎をなすデータに対してのみアクセスを有する。これは、ウィジェットを追加することができるが、ウィジェットのための基礎をなすデータは、特定のユーザにとって利用可能でない場合があることを意味する。
パルスページは、ユーザが自身のページに加えることができる様々な所定のウィジェットを有することができる。ユーザはページからウィジェットを除去することができる。いくつかの実施形態では、ウィジェットは、ドラッグアンドドロップ動作を介して、またはモバイルデバイス環境ではドラッグを介してソートすることができる。選択されたウィジェットおよびウィジェットの順序は、特定の所有者（患者）に対して保存することができる。
次に、いくつかの例示的なウィジェットが説明される。薬剤服用ウィジェットは、見出し（カスタムウィジェット見出し）、薬剤（薬剤を選択）、フォーカス（例えば、服用量、服用時刻）、およびタイムスパン（今日、直近７日間、直近３０日間、直近６ヶ月間）のためのオプションを含むことができる。物理的アクティビティウィジェットは、見出し（カスタムウィジェット見出し）、物理的アクティビティ（アクティビティを選択）、フォーカス（例えば、持続時間、アクティビティの時刻）、およびタイムスパン（今日、直近７日間、直近３０日間、直近６ヶ月間）のためのオプションを含むことができる。身体測定ウィジェットは、見出し（カスタムウィジェット見出し）、測定（測定を選択）、フォーカス（例えば、日ごとの平均）、およびタイムスパン（直近７日間、直近３０日間、直近６ヶ月間）のためのオプションを含むことができる。バイタルウィジェットは、見出し（カスタムウィジェット見出し）、バイタル（１つのバイタルを選択）、フォーカス（例えば、平均）、およびタイムスパン（今日、直近７日間、直近３０日間、直近６ヶ月間）のためのオプションを含むことができる。栄養ウィジェットは、見出し（カスタムウィジェット見出し）、フォーカス（例えば、総カロリー、総炭水化物、総コレステロール、総繊維、総糖類、総プロテイン、総脂肪、総飽和脂肪、総ナトリウム）、およびタイムスパン（今日、直近７日間、直近３０日間、直近６ヶ月間）のためのオプションを含むことができる。他のウィジェットは、最新のエントリ、睡眠、気分、痛み、およびアクセスを対応するオプションと共に含むことができる。
図５７は、運動タイプおよびビュー基準のためのドロップダウンメニューを有する２つの制御を有するリストビューを示す物理的アクティビティまたは運動履歴のための例示的なウィジェットのためのインターフェース画面を示す画面表示の一部分の例である。各ブロック部分は、運動を実行する持続時間を有し、色を用いて、例えば目標に基づくステータスを示すことができる。
図５８は、選択された運動タイプおよび消費カロリーによるビューを含む選択された制御に応答してグラフィカルデータビューを示す例示的なウィジェットのためのインターフェース画面を示す画面表示の一部分の例である。
図５９は、全ての運動タイプおよび平均時間によるビューを含む選択された制御に応答してグラフィカルデータビューを示す、例示的なウィジェットのためのインターフェース画面を示す画面表示の一部分の例である。
図６０は、選択された制御に応答してリストビューを示すいくつかの例示的なウィジェットのためのインターフェース画面を示す画面表示の例であり、ここで、各ウィジェットは異なる制御を有することができる。
図６１は、自身の健康状態フィードウィジェットのための例示的なウィジェット設定およびウィジェット表示と、物理的アクティビティウィジェットのための例示的なウィジェット設定および対応するウィジェット表示とのためのインターフェース画面を示す画面表示の例である。画面表示は、例えば、スマートフォン等のモバイルコンピューティングデバイス上で見ることができるもの等である。
表示画面６１１０は、ユーザがパルスページ上の「編集」ボタンをクリックし、新たなウィジェットを追加するために＋（プラス）ボタンをクリックしたときに現れる例示的なダイアログである。表示画面６１２０は、選択される新たなウィジェットをユーザがセットアップすることを可能にするために現れる例示的なダイアログ（この場合、健康情報データ−最新のデータ）である。表示画面６１３０は、パルスページウィジェット（通例、表示画面６１２０と同じ）のための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６１４０は、パルスページ上に現れるときの実際のウィジェットの例である。
表示画面６１５０〜６１８０は、物理的アクティビティのためのウィジェットを示す。表示画面６１５０は、ユーザが選択された新たなウィジェット（この場合、健康情報データ−物理的アクティビティ）を設定することを可能にするために現れる例示的なダイアログである。表示画面６１６０は、パルスページウィジェット（通例、表示画面６１５０と同じである）のための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６１７０は、１日の物理的アクティビティについてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６１８０は１週間の物理的アクティビティについてのものである。
図６２は、薬剤服用ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６２２０は、ユーザが選択された新たなウィジェット（この場合、健康情報データ−薬剤服用）を設定することを可能にするために現れる例示的なダイアログである。表示画面６２３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６２４０は、１日の薬剤服用についてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６２５０は１週間の薬剤服用についてのものである。
図６３は、睡眠ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６３２０は、ユーザが選択された新たなウィジェット（この場合、健康情報データ−睡眠）を設定することを可能にするために現れる例示的なダイアログである。表示画面６３３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６３４０は、１日の睡眠データについてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６３５０は１週間の睡眠データについてのものである。
図６４は、気分ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６４２０は、ユーザが選択された新たなウィジェット（この場合、気分）を設定することを可能にするために現れる例示的なダイアログである。表示画面６４３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行う可能にするダイアログの例である。表示画面６４４０は、１日の気分データについてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６４５０は１週間の気分データについてのものである。
図６５は、痛みウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６５２０は、ユーザが選択された新たなウィジェット（この場合、痛み）を設定することを可能にするために現れる例示的なダイアログである。表示画面６５３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６５４０は、１日の痛みデータについてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６５５０は１週間の痛みデータについてのものである。
図６６は、身体測定ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６６２０は、ユーザが選択された新たなウィジェット（この場合、健康情報データ−身体測定）を設定することを可能にするために現れる例示的なダイアログである。表示画面６６３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６６４０は、１日の身体測定データについてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６６５０は１週間の身体測定データについてのものである。
図６７は、バイタルウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６７２０は、ユーザが選択された新たなウィジェット（この場合、健康情報データ−バイタル）を設定することを可能にするために現れる例示的なダイアログである。表示画面６７３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６７４０は、１日のバイタルデータについてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６７５０は１週間のバイタルデータについてのものである。
図６８は、飲食物ウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６８２０は、ユーザが選択された新たなウィジェット（この場合、健康情報データ−飲食物）を設定することを可能にするために現れる例示的なダイアログである。表示画面６８３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６８４０は、１日の飲食物データについてパルスページ上に現れるときの実際のウィジェットの例であり、表示画面６８５０は１週間の飲食物データについてのものである。
図６９は、アクセスウィジェットのための例示的なウィジェット設定および対応するウィジェット表示のためのインターフェース画面を示す画面表示の例である。表示画面６９２０は、ユーザが選択された新たなウィジェット（この場合、アクセス）を設定することを可能にするために現れる例示的なダイアログである。表示画面６９３０は、パルスページウィジェットのための設定を変更するために現れ、ユーザがこれを行うことを可能にするダイアログの例である。表示画面６９４０は、所有者のデータへのアクセスのパルスページ列挙アイテム上に現れるときに実際のウィジェットの例である。
＜結論＞
システムおよび方法の全体効果は、例えば、プライバシーを守り、見落とし、漏れおよびミスを減らし、医療専門家がより総合的に、より短時間で診断することを可能にするために、データ所有者に関連付けられた様々な関係者に対するアクセスおよびアクセスタイプを制御することである。
本明細書において開示される実施態様に関連して説明される様々な例示的なロジック、論理ブロック、モジュール、回路およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または双方の組み合わせとして実施することができる。ハードウェアおよびソフトウェアの交換可能性は、概ね、機能の観点で説明されており、上述した様々な例証的なコンポーネント、ブロック、モジュール、回路およびステップにおいて示されている。そのような機能がハードウェアで実施されるかまたはソフトウェアで実施されるかは、特定の用途およびシステム全体に課される設計制約に依拠する。
１つ以上の態様において、説明される機能は、ハードウェア、デジタル電子回路部、コンピュータソフトウェア、ファームウェアにおいて実施することができ、本明細書に開示される構造、およびそれらの構造的等価物、またはそれらの任意の組み合わせを含む。本明細書に記載の主題の実施は、１つ以上のコンピュータプログラムとして、例えば、データ処理装置によって実行するかまたはデータ処理装置の動作を制御するためにコンピュータストレージ媒体上で符号化されるコンピュータプログラム命令の１つ以上のモジュールとして実施することもできる。
ソフトウェアにおいて実施される場合、機能は、コンピュータ可読媒体上の１つ以上の命令またはコードとして記憶または送信することができる。本明細書に開示される方法またはアルゴリズムのステップは、コンピュータ可読媒体上に常駐することができるプロセッサ実行可能なソフトウェアモジュールにおいて実施することができる。コンピュータ可読媒体は、コンピュータプログラムをある場所から別の場所に移すことが可能にされ得る任意の媒体を含むコンピュータストレージ媒体および通信媒体の双方を含む。ストレージ媒体は、コンピュータによってアクセス可能とすることができる任意の利用可能な媒体とすることができる。限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、命令もしくはデータ構造の形態で所望のプログラムコードを記憶するのに用いることができ、コンピュータによってアクセスすることができる任意の他の媒体を含むことができる。また、任意の接続を適宜、コンピュータ可読媒体と呼ぶことができる。本明細書において用いられるとき、ディスク（ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスク、およびブルーレイディスクを含み、ここで、ディスク（ｄｉｓｋ）は通例、データを磁気的に再生し、ディスク（ｄｉｓｃ）はデータをレーザで光学的に再生する。上記の組み合わせもコンピュータ可読媒体の範囲内に含まれるべきである。更に、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込むことができる、マシン可読媒体およびコンピュータ可読媒体上のコードおよび命令の１つまたは任意の組み合わせまたはこれらの組として存在することができる。
別個の実施態様の文脈において本明細書において説明されるいくつかの特徴は、単一の実施態様において組み合わせて実施することもできる。逆に、単一の実施態様との関連で記載されている様々な特徴を、複数の実施態様において別個に、または任意の適切な部分的組み合わせで実施することもできる。更に、特徴は、ある特定の組み合わせで動作するものとして上記で記載される場合があり、更にはそのように最初から特許請求される場合があるが、特許請求される組み合わせからの１つ以上の特徴は、いくつかの例では組み合わせから削除することができ、特許請求された組み合わせは、部分的組み合わせ、または部分的組み合わせの変形形態を対象とすることができる。
同様に、動作は図面において特定の順序で示されているが、これは、そのような動作が示される特定の順序でもしくは順次実行されること、または所望の結果を達成するために全ての示される動作が実行されることを必要とするものとして理解されるべきでない。ある特定の環境において、マルチタスクおよび並行処理が有利であり得る。更に、上記で説明した実施態様における様々なシステムコンポーネントの分離は、全ての実施態様におけるそのような分離を必要とするものとして理解されるべきでなく、説明されるプログラムコンポーネントおよびシステムを、単一のソフトウェア製品に合わせて一体化するか、または複数のソフトウェア製品にパッケージ化することができることが理解されるべきである。
上記の説明は、本発明のいくつかの実施形態を詳述する。一方、上述したものが本文においてどれだけ詳細に現れていようと、本発明は、多くの方法で実施することができることが理解されよう。同様に上述したように、本発明のいくつかの特徴および態様を説明するときに特定の用語の使用が、その用語が本明細書において、その用語が関連付けられた本発明の特徴または態様の何らかの特定の特性を含むように制約されることを暗に意味するように解釈されるべきでないことも留意されるべきである。したがって、本発明の範囲は、添付の特許請求の範囲およびその任意の等価物に従って解釈されるべきである。

Claims (71)

  1. 少なくとも複数のコンピューティングデバイス、サーバ、ネットワークおよびデータベースを含むシステム内のデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、
    該サーバにおいて、データベースの所有者の電子ダイアリ部分に記憶されたデータの所有者から電子認証を受信することと、
    該サーバにおいて、該所有者によって制御されるデータの特定のカテゴリにアクセスするように招待された１以上の所望の受信者の各々に対応する電子アドレスを受信することと、
    該招待が受け入れられた場合、該１以上の受信者が有することになる特定の許可を特定することであって、許可は１つ以上の特定のアクションを実行する能力を提供することと、
    コンピュータネットワークを介して、該１以上の所望の受信者に電子通信を送信することであって、各電子通信は、該通信に返答するのに用いるための一意のユニフォームリソースロケータを含むことと、
    コンピュータネットワークを介して、該１以上の受信者の各々から該招待の受入れまたは拒絶を含む電子メッセージを受信することと、
    該所有者のデータに対する、所有者により制御された電子アクセスを容易にするために、データ構造内に、該１以上の受信者の各々の識別子と、該招待の該受入れまたは拒絶のインジケータと、該招待が受け入れられた場合、該１以上の受信者の各々に付与される許可の対応する組み合わせとを記憶することと、
    を含む、方法。
  2. 前記受信者のうちの１つが組織である場合、前記所有者および１人以上のスタッフメンバのための１つ以上の特定のアクセスグループと、該１人以上のスタッフメンバのための１つ以上の役割と、前記特定の許可が付与されるデータの対応するカテゴリとを特定する１つ以上の電子メッセージを受信する、請求項１記載の方法。
  3. 特定のスタッフメンバは、前記所有者および該スタッフメンバが共通のアクセスグループを共有する場合にのみ、ダイアリにアクセスすることができる、請求項２記載の方法。
  4. 特定のスタッフメンバは、該スタッフメンバが属する全ての役割からの累積的許可に基づいてダイアリにアクセスする、請求項２記載の方法。
  5. 前記特定の許可は、前記所有者のアカウントから前記組織に与えられる許可に制約される、請求項２記載の方法。
  6. 役割は、組織が定義した許可の組み合わせである、請求項２記載の方法。
  7. アクセスグループは、スタッフおよび所有者をリンク付けするための組織が定義したグループである、請求項２記載の方法。
  8. 前記所有者から、特定の受信者の合意なしで許可を追加または削除するための電子要求を受信することを更に含む、請求項１記載の方法。
  9. 前記選択された受信者による前記付与された許可の使用を更に含み、これは、
    前記受信者のうちの特定の受信者から所有者データのグラフィカル表示のための要求を受信することと、
    前記特定の受信者のための累積的許可を決定することであって、該特定の受信者が組織の一部である場合、該決定することは、該特定の受信者が前記所有者と共有されるアクセスグループに関連付けられているか否かを判断することを更に含むことと、
    前記所有者の電子ダイアリにおける該累積的許可によって特定されるデータを取り出すことと、
    前記取り出されたデータのＨＴＭＬベースの画面表示を生成することと、
    を含む、請求項１記載の方法。
  10. 前記ＨＴＭＬベースの画面表示を操作するために前記特定の受信者からナビゲーション要求を受信することを更に含む、請求項９記載の方法。
  11. 前記ＨＴＭＬベースの画面表示を操作するために前記受信者のうちの特定の受信者からナビゲーション要求を受信することを更に含む、請求項９記載の方法。
  12. 前記画面表示は、前記受信者のうちの特定の受信者が許可を有する前記カテゴリのためのデータを含み、該画面表示は、該受信者のうちの該特定の受信者が許可を有していない前記カテゴリを示す、請求項９記載の方法。
  13. 前記ＨＴＭＬベースの画面表示を生成することは、前記累積的許可に対応する各カテゴリについて１つ以上の制御を適用することを含み、各許可されたカテゴリのための前記制御は、他の許可されたカテゴリのための前記制御と独立している、請求項１２記載の方法。
  14. 前記ＨＴＭＬベースの画面表示を生成することは、単一のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのタイムラインビューを適用することを含む、請求項９記載の方法。
  15. 前記ＨＴＭＬベースの画面表示を生成することは、複数のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのタイムラインビューを適用することを含む、請求項９記載の方法。
  16. 所定のテンプレートのタイムラインビューが、前記ユーザに許可されていないカテゴリからのデータに対するアクセスを必要とする場合、前記ビューは表示されず、ユーザが通知を受ける、請求項１５記載の方法。
  17. 日、週、月または年、および前記集約レベル選択に対応する開始日または終了日からの集約レベル選択を含むタイムライン表示の要求を受信することと、
    該受信した要求に従って２つの行部分を有するカレンダバーをレンダリングすることであって、最下行部分は、該集約レベル選択に対応する該開始日または該終了日に従って日付を有する一連のブロックを表示し、最上行部分は、該選択された集約レベルに一連のドットを表示し、ここで、明るいドットは、該選択された集約レベルにおける期間にわたる所有者データの欠如を表し、暗いドットは、該期間にわたる所有者データの存在を表すことと、
    を更に含む、請求項９記載の方法。
  18. 前記カレンダバーの前記最上行部分は、前記最下行部分における前記日付に対応する前記ドットにわたって強調されたブロックを更に表示し、カーソルが該最上行部分の別の部分上をホバリングするように動かされる場合、ホバリングカーソルの位置に対応して別の強調されたブロックが表示され、該ホバリングカーソルの該位置においてクリックイベントが受信される場合、前記タイムラインが、該クリックの日付に対応し、前記選択された集約レベルに従うデータを表示する、請求項１７記載の方法。
  19. 前記データのカテゴリは、薬剤、運動、睡眠、病気、および性の健康を含む、請求項２記載の方法。
  20. 前記データのカテゴリは、医療記録、症状および／またはバイタルサイン、薬剤および／または実験結果、感情、ライフイベント、遺伝子マーカおよびライフスタイルを含む、請求項２記載の方法。
  21. 前記受信者は、ビジタ、スタッフメンバおよび所有者／ビジタのうちの１つである、請求項１記載の方法。
  22. 前記ビジタは、読み出しおよび／または書き込み権限を有するゲスト、および／または完全な所有者権限を有する保護者のうちの一方である、請求項２１記載の方法。
  23. 前記スタッフメンバは組織に属するユーザである、請求項２記載の方法。
  24. 前記所有者／ビジタは、ダイアリを有する所有者であり、かつ別の所有者のダイアリに対するアクセスも付与されている、ユーザである、請求項１記載の方法。
  25. 許可ステータスは、取得、受信および受入れを含む、請求項１記載の方法。
  26. 許可の種類は、読み出し、書き込みおよびアクセスなしを含む、請求項１記載の方法。
  27. 前記招待の前記受信した受入れまたは拒絶の確認またはキャンセルを含む電子メッセージを受信することを更に含む、請求項１記載の方法。
  28. 少なくとも複数のコンピューティングデバイス、サーバおよびネットワークを含むシステム内のデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、
    該データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、該組織が有する許可を特定することであって、許可は、１つ以上の特定のアクションを実行する能力を提供することと、
    コンピュータネットワークを介して、少なくとも、該招待、該組織の該管理者に対する許可の組み合わせ、および該電子通信に返答する際に用いるための一意のユニフォームリソースロケータを含む電子通信を送信することと、
    組織が定義したアクセスグループへの該特定の所有者の割り当てを受信することと、
    該アクセスグループに対する、該特定の所有者および該組織の１人以上の選択されたスタッフメンバのマッピングを受信して、該特定の所有者および該選択されたスタッフメンバをリンク付けすることと、
    該組織の該スタッフメンバに対応する少なくとも１つの役割の識別情報を受信することと、
    該少なくとも１つの役割に対する、該組織の該１人以上の選択されたスタッフメンバの割り当てを受信することと、
    該特定の所有者および該選択されたスタッフメンバを有する該特定のアクセスグループに従って、かつ該選択されたスタッフを有する該少なくとも１つの役割に従って、該特定の所有者のための該選択されたスタッフメンバに特定の許可を付与することと、
    該所有者のデータに対する、所有者により制御される電子アクセスを容易にするために、データ構造内に、該招待の該受入れまたは拒絶のインジケータと、該選択されたスタッフメンバの各々の識別子と、該選択されたスタッフメンバの各々に付与された許可の対応する組み合わせとを記憶することと、
    を含む、方法。
  29. 特定のスタッフメンバは、前記所有者および前記スタッフメンバが共通アクセスグループを共有する場合にのみ所有者のダイアリにアクセスすることができる、請求項２８記載の方法。
  30. 特定のスタッフメンバは、前記スタッフメンバが属する全ての役割からの前記累積的許可に基づいて所有者のダイアリにアクセスする、請求項２８記載の方法。
  31. 前記特定の許可は、前記所有者のアカウントから前記組織に与えられる許可に制約される、請求項２８記載の方法。
  32. 役割は、組織が定義した許可の組み合わせである、請求項２８記載の方法。
  33. 前記選択されたスタッフメンバによる前記付与された許可の使用を更に含み、これは、
    該スタッフメンバのうちの特定のスタッフメンバから所有者データのグラフィカル表示のための要求を受信することと、
    該特定のスタッフメンバのための累積的許可を決定することであって、該特定のスタッフメンバが前記所有者と共有されるアクセスグループに関連付けられているか否かを判断することを更に含むことと、
    該所有者の電子ダイアリにおける該累積的許可によって特定されるデータを取り出すことと、
    該取り出されたデータのＨＴＭＬベースの画面表示を生成することと、
    を含む、請求項２８記載の方法。
  34. 前記特定のスタッフメンバから、前記ＨＴＭＬベースの画面表示を操作するためのナビゲーション要求を受信することを更に含む、請求項３３記載の方法。
  35. 前記スタッフメンバは、医師、看護師、技術者、薬剤師および管理者のうちの１つを含む、前記組織に属するユーザである、請求項２８記載の方法。
  36. 許可の種類は、読み出し、書き込みおよびアクセスなしを含む、請求項２８記載の方法。
  37. 前記役割は、対応するスタッフメンバがアクセスを有する選択されたデータのカテゴリを更に含み、該データのカテゴリは、医療記録、症状および／またはバイタルサイン、薬剤および／または実験結果、感情、ライフイベント、遺伝子マーカおよびライフスタイルを含む、請求項２８記載の方法。
  38. 少なくとも複数のコンピューティングデバイス、サーバおよびネットワークを含むシステム内の所有者ダイアリ内に配列されたデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、
    該データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、該組織が有する許可を特定することであって、許可は、１つ以上の特定のアクションを実行する能力を提供することと、
    コンピュータネットワークを介して、少なくとも、該所有者の各々からの招待、および該組織の該管理者に対する許可の対応する組み合わせを含む電子通信を送信することであって、各電子通信は、該電子通信に返答する際に用いるための一意のユニフォームリソースロケータを含むことと、
    １つ以上の組織が定義したアクセスグループへの該所有者の各々の割り当てを受信することと、
    １つ以上のアクセスグループに対する、特定の所有者および該組織の１人以上の選択されたスタッフメンバのマッピングを受信して、該特定の所有者および該選択されたスタッフメンバをリンク付けすることと、
    該組織の該スタッフメンバに対応する少なくとも１つの役割の識別情報を受信することと、
    該少なくとも１つの役割に対する、該組織の該１人以上の選択されたスタッフメンバの割り当てを受信することと、
    特定の所有者および該選択されたスタッフメンバを有する１つ以上のアクセスグループに従って、かつ該選択されたスタッフを有する該特定の所有者のための該少なくとも１つの役割に従って、該所有者の各々のための該選択されたスタッフメンバに特定の許可を付与することと、
    各所有者のデータに対する、所有者により制御される電子アクセスを容易にするために、データ構造内に、該所有者の各々のための該招待の該受入れまたは拒絶のインジケータと、該選択されたスタッフメンバの各々の識別子と、各所有者のための該選択されたスタッフメンバの各々に付与された許可の対応する組み合わせとを記憶することと、
    を含む、方法。
  39. 特定のスタッフメンバは、前記対応する特定の所有者および該スタッフメンバが共通アクセスグループを共有する場合にのみ特定のダイアリにアクセスすることができる、請求項３８記載の方法。
  40. 特定のスタッフメンバは、該スタッフメンバが属する全ての役割からの累積的許可に基づいて特定のダイアリにアクセスする、請求項３８記載の方法。
  41. 前記特定の許可は、対応する所有者のアカウントから前記組織に与えられる許可に制約される、請求項３８記載の方法。
  42. 役割は、組織が定義した許可の組み合わせである、請求項３８記載の方法。
  43. 前記選択されたスタッフメンバによる前記付与された許可の使用を更に含み、これは、
    前記スタッフメンバのうちの特定のスタッフメンバから特定の所有者のデータのグラフィカル表示のための要求を受信することであって、前記データは複数のカテゴリ間でグループ化されることと、
    該特定のスタッフメンバが該特定の所有者と共有されるアクセスグループに関連付けられているか否かを判断することと、
    該特定のスタッフメンバが該特定の所有者と共有されるアクセスグループに関連付けられている場合、該特定のスタッフメンバのための役割から前記累積的許可を決定することと、
    前記組織が前記所有者によって該累積的許可のうちのいずれを与えられたかを判断することと、
    該特定の所有者の電子ダイアリにおける該累積的許可によって特定されるデータを取り出すことと、
    該取り出されたデータのＨＴＭＬベースの画面表示を生成することと、
    を含む、請求項３８記載の方法。
  44. 前記特定のスタッフメンバから、前記ＨＴＭＬベースの画面表示を操作するためのナビゲーション要求を受信することを更に含む、請求項４３記載の方法。
  45. 前記画面表示は、前記特定のスタッフメンバが許可を有する前記カテゴリのためのデータを含み、該画面表示は、該特定のスタッフメンバが許可を有していない該カテゴリを示す、請求項４３記載の方法。
  46. 前記スタッフメンバは、医師、看護師、技術者、薬剤師および管理者のうちの１つを含む、前記組織に属するユーザである、請求項３８記載の方法。
  47. 許可の種類は、読み出し、書き込みおよびアクセスなしを含む、請求項３８記載の方法。
  48. 前記役割には、対応するスタッフメンバがアクセスを有するデータのカテゴリが関連付けられ、該データのカテゴリは、医療記録、症状および／またはバイタルサイン、薬剤および／または実験結果、感情、ライフイベント、遺伝子マーカおよびライフスタイルを含む、請求項３８記載の方法。
  49. 前記役割には、対応するスタッフメンバがアクセスを有するデータのカテゴリが関連付けられ、前記データのカテゴリは、身体測定値、臨床メモ、ダイアリメモ、飲酒、環境、気分、予防接種、実験結果、ライフイベント、薬剤、気分、栄養、痛み、患者ストレス、物理的アクティビティ、睡眠、喫煙、症状、治療およびバイタルサインを含む、請求項３８記載の方法。
  50. 前記ＨＴＭＬベースの画面表示を生成することは、前記付与された許可に対応する各カテゴリについて１つ以上の制御を適用することを含み、各許可されたカテゴリのための前記制御は、他の許可されたカテゴリのための前記制御と独立している、請求項４５記載の方法。
  51. 前記制御は、前記取り出されたデータのソート、閲覧、色分けおよびフィルタリングの選択を含む、請求項５０記載の方法。
  52. 前記制御は、前記取り出されたデータを表示するためのリストフォーマットおよびグラフィカルフォーマットを含む、請求項５０記載の方法。
  53. 前記ＨＴＭＬベースの画面表示を生成することは、単一のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのライムラインビューを適用することを含む、請求項４３記載の方法。
  54. 前記ＨＴＭＬベースの画面表示は、複数のカテゴリからのデータに基づいて、１つ以上の所定のテンプレートのタイムラインビューを適用することを含む、請求項４３記載の方法。
  55. 所定のテンプレートのタイムラインビューが、前記ユーザに許可されていないカテゴリからのデータに対するアクセスを必要とする場合、前記ビューは表示されず、ユーザが通知を受ける、請求項５４記載の方法。
  56. 前記所有者のデータにアクセスする人物、各人物によってとられるアクション、前記ダイアリに対する変更または追加が存在する場合、それらのタイムスタンプを付されたログを生成することを更に含む、請求項４３記載の方法。
  57. 特定の所有者に対応するソース文書をスキャンすることと、
    該スキャンされた文書から、該ソース文書への参照を含む医療データを抽出することと、
    該ソース文書を電子ストレージに記憶することと、
    該抽出された医療データおよび該ソース文書への該参照を、該抽出されたデータのカテゴリに基づいて特定のダイアリに記憶することであって、該記憶された参照は、ユーザが該抽出されたデータを閲覧して該ソース文書にナビゲートし、該ソース文書を閲覧することを可能にすることと、
    を更に含む、請求項３８記載の方法。
  58. 前記ソース文書は、特定のウェブページの解像度で記憶される、請求項５７記載の方法。
  59. 前記抽出されたデータは、タイムライン上で、または前記データの他の表示ページ上で閲覧される、請求項５７記載の方法。
  60. 特定のダイアリのための選択されたカテゴリにおけるデータアイテムの選択を受信することと、
    該選択されたカテゴリにおける制御を起動して、ソース文書リンクプロセスを開始することと、
    前記電子ストレージへのユーザインターフェースを表示することと、
    該データアイテムにリンクされるソース文書の該インターフェースの使用による選択を受信することと、
    該データアイテムのための該リンクを前記特定のダイアリに記録することと、
    を更に含む、請求項４５記載の方法。
  61. 前記データのカテゴリは、臨床データ、ライフスタイルデータ、心理社会的データ、環境データおよび遺伝データを含む、請求項２記載の方法。
  62. 少なくとも複数のコンピューティングデバイス、サーバおよびネットワークを含むシステム内のデータの所有者によって、選択された受信者に対する許可の付与を制御する方法であって、
    該データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、該組織が有する許可を特定することであって、許可は、１つ以上の特定のアクションを実行する能力を提供することと、
    コンピュータネットワークを介して、少なくとも、該招待、該組織の該管理者に対する許可の組み合わせ、および該電子通信に返答する際に用いるための一意のユニフォームリソースロケータを含む電子通信を送信することと、
    組織が定義したアクセスグループへの該特定の所有者の割り当てを受信することと、
    該アクセスグループに対する、該特定の所有者および該組織の１人以上の選択されたスタッフメンバのマッピングを受信して、該特定の所有者および該選択されたスタッフメンバをリンク付けすることと、
    該少なくとも１つの組織の役割に対する、該組織の該１人以上の選択されたスタッフメンバの割り当てを受信することと、
    該特定の所有者および該選択されたスタッフメンバを有する該特定のアクセスグループに従って、かつ該選択されたスタッフを有する該少なくとも１つの役割に従って、該特定の所有者のための該選択されたスタッフメンバに特定の許可を付与することと、
    データ構造内に、該招待の該受入れまたは拒絶のインジケータと、該選択されたスタッフメンバの各々の識別子と、該選択されたスタッフメンバの各々に付与された許可の対応する組み合わせとを記憶することと、
    対応する付与された書き込み許可を有する第１のユーザから該所有者のデータまたは新たなデータに対する編集を受信することと、
    該第１のユーザのアイデンティティ、該編集または新たなデータの時刻および日付、更新されたタイプまたはカテゴリ、およびデータベース内の該編集または新たなデータを追跡することと、
    該更新された所有者のデータのためのバージョン識別子を変更することと、
    を含む、方法。
  63. 前記所有者のデータが、前記第１のユーザによってフェッチされてから第２のユーザによって変更されたか否かを判断することと、
    前記更新が否認されたことを前記第１のユーザに通知することと、
    を更に含む、請求項６２記載の方法。
  64. 前記所有者のデータが、フェッチされてから変更されたか否かを判断することは、前記変更されたエントリが最新バージョンであるか否かを判断することを含む、請求項６３記載の方法。
  65. 前記所有者のデータは、医療データまたは健康関連データである、請求項６２記載の方法。
  66. 前記更新は、変更されたバージョン識別子を有する所有者のデータにアクセスするために対応する付与された許可を有する各後続のユーザに可視である、請求項６２記載の方法。
  67. 前記編集された所有者のデータの以前のバージョンのための変更履歴を、該編集されたデータに対応する前記データのカテゴリのための適切な読み出し許可を有するユーザに対し表示することを更に含む、請求項６２記載の方法。
  68. データの所有者によって、選択された受信者に対する許可の付与を制御するためのシステムであって、少なくとも複数のクライアントコンピューティングデバイス、サーバおよびデータベースを含み、
    サーバにおいて、データベースの所有者の電子ダイアリ部分に記憶されたデータの所有者に対応するクライアントコンピューティングデバイスから電子認証を受信する手段と、
    該サーバにおいて、該所有者によって制御されるデータの特定のカテゴリにアクセスするように招待された１以上の所望の受信者クライアントコンピューティングデバイスの各々に対応する電子アドレスを受信する手段と、
    該招待が受け入れられた場合、該１以上の受信者が有することになる特定の許可を特定する手段であって、許可は１つ以上の特定のアクションを実行する能力を提供する、手段と、
    該１以上の所望の受信者クライアントコンピューティングデバイスに電子通信を送信する手段であって、各電子通信は、該通信に返答するのに用いるための一意のユニフォームリソースロケータを含む、手段と、
    該１以上の受信者クライアントコンピューティングデバイスの各々から該招待の受入れまたは拒絶を含む電子メッセージを受信する手段と、
    該所有者のデータに対する、所有者により制御された電子アクセスを容易にするために、該１以上の受信者の各々の識別子と、該招待の該受入れまたは拒絶のインジケータと、該招待が受け入れられた場合、該１以上の受信者の各々に付与される許可の対応する組み合わせとを記憶する手段と、
    を備える、システム。
  69. データの特定の所有者は、該特定の所有者に対応する複数のクライアントコンピューティングデバイスを有する、請求項６８記載のシステム。
  70. 所有者ダイアリ内に配列されたデータの所有者によって、選択された受信者に対する許可の付与を制御するためのシステムであって、少なくとも複数のクライアントコンピューティングデバイスおよびサーバを含み、
    該データの特定の所有者からの招待が組織の管理者によって受け入れられる場合、該組織が有する許可を特定する手段であって、許可は、１つ以上の特定のアクションを実行する能力を提供する、手段と、
    少なくとも、該所有者の各々に対応するクライアントコンピューティングデバイスからの招待、および該組織の該管理者に対する許可の対応する組み合わせを含む電子通信を送信する手段であって、各電子通信は、該通信に返答する際に用いるための一意のユニフォームリソースロケータを含む、手段と、
    １つ以上の組織が定義したアクセスグループへの該所有者の各々の割り当てを受信する手段と、
    １つ以上のアクセスグループに対する、特定の所有者および該組織の１人以上の選択されたスタッフメンバのマッピングを受信して、該特定の所有者および該選択されたスタッフメンバをリンク付けする手段と、
    該組織の該スタッフメンバに対応する少なくとも１つの役割の識別情報を受信する手段と、
    該少なくとも１つの役割に対する、該組織の該１人以上の選択されたスタッフメンバの割り当てを受信する手段と、
    特定の所有者および該選択されたスタッフメンバを有する１つ以上のアクセスグループに従って、かつ該選択されたスタッフを有する該特定の所有者のための該少なくとも１つの役割に従って、該所有者の各々のための該選択されたスタッフメンバに特定の許可を付与する手段と、
    各所有者のデータに対する、所有者により制御される電子アクセスを容易にするために、該所有者の各々のための該招待の該受入れまたは拒絶のインジケータ、該選択されたスタッフメンバの各々の識別子、および各所有者のための該選択されたスタッフメンバの各々に付与された許可の対応する組み合わせを記憶する手段と、
    を備える、システム。
  71. データの特定の所有者は、該特定の所有者に対応する複数のクライアントコンピューティングデバイスを有する、請求項７０記載のシステム。
JP2017540641A 2015-01-30 2016-01-28 データの所有者によって、選択された受信者のための許可を制御するシステムおよび方法 Ceased JP2018512085A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562110315P 2015-01-30 2015-01-30
US62/110,315 2015-01-30
US201562128830P 2015-03-05 2015-03-05
US62/128,830 2015-03-05
PCT/US2016/015392 WO2016123359A1 (en) 2015-01-30 2016-01-28 System and method for controlling permissions for selected recipients by owners of data

Publications (2)

Publication Number Publication Date
JP2018512085A true JP2018512085A (ja) 2018-05-10
JP2018512085A5 JP2018512085A5 (ja) 2019-02-14

Family

ID=56544335

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017540641A Ceased JP2018512085A (ja) 2015-01-30 2016-01-28 データの所有者によって、選択された受信者のための許可を制御するシステムおよび方法

Country Status (9)

Country Link
US (1) US20180150650A1 (ja)
EP (1) EP3251079A4 (ja)
JP (1) JP2018512085A (ja)
CN (1) CN107533555A (ja)
AU (2) AU2016211464A1 (ja)
CA (1) CA2972918A1 (ja)
HK (1) HK1248855A1 (ja)
SG (2) SG10201802859XA (ja)
WO (1) WO2016123359A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020166095A1 (ja) * 2019-02-14 2020-08-20 エンブレース株式会社 医療・介護分野における多職種連携支援方法及びシステム

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170300628A1 (en) * 2016-04-15 2017-10-19 Under Armour, Inc. Health tracking system including subjective health perception tool
US20180173886A1 (en) * 2016-12-15 2018-06-21 Joseph E Dryer Collaborative Database to Promote Data Sharing, Synchronization, and Access Control
US11025635B2 (en) * 2017-01-30 2021-06-01 Ncr Corporation Secure remote support authorization
US11443098B1 (en) * 2017-02-08 2022-09-13 Amazon Technologies, Inc. Federated recursive user interface element rendering
DE102018001986A1 (de) * 2017-03-22 2018-09-27 Löwenstein Medical Technology S.A. Verfahren und Vorrichtung zur Übermittlung von Daten von Beatmungsgeräten
JP6813403B2 (ja) * 2017-03-25 2021-01-13 エンブレース株式会社 医療・介護情報管理方法、医療・介護情報管理システム及び医療・介護情報管理プログラム
US10885134B2 (en) * 2017-05-12 2021-01-05 International Business Machines Corporation Controlling access to protected information
US11050753B2 (en) * 2017-09-29 2021-06-29 Oracle International Corporation Data driven role permissions
JP7013807B2 (ja) * 2017-11-15 2022-02-01 富士通株式会社 情報処理装置、情報処理システムおよび情報処理プログラム
JP6674435B2 (ja) * 2017-12-05 2020-04-01 エンブレース株式会社 医療・介護支援システムにおけるサービス構築支援方法及びシステム
US10255415B1 (en) 2018-04-03 2019-04-09 Palantir Technologies Inc. Controlling access to computer resources
US11210418B2 (en) * 2018-07-26 2021-12-28 Health2047, Inc. Medical data access rights constraint enforcement and presentation system
US11323452B2 (en) * 2019-01-25 2022-05-03 International Business Machines Corporation Hiearchical access groups for controlling data access, especially patient data access
US10902146B2 (en) 2019-03-19 2021-01-26 Workiva Inc. Method and computing device for gating data between workspaces
KR20200120156A (ko) * 2019-04-11 2020-10-21 삼성전자주식회사 전자 장치 및 전자 장치에서 의료 정보 공유 방법
US11379600B2 (en) 2019-08-26 2022-07-05 Saudi Arabian Oil Company Management of actions and permissions to applications in an enterprise network
US11704441B2 (en) 2019-09-03 2023-07-18 Palantir Technologies Inc. Charter-based access controls for managing computer resources
GB2607824A (en) * 2020-02-12 2022-12-14 Rapiscan Systems Inc Systems and methods of generating improved graphical user interfaces for distributed rule and workflow management
US11627126B2 (en) 2020-08-20 2023-04-11 Bank Of America Corporation Expedited authorization and access management
US11874852B2 (en) * 2020-08-28 2024-01-16 Micron Technology, Inc. Instructive actions based on categorization of input data
JP2022107418A (ja) * 2021-01-08 2022-07-21 トヨタ自動車株式会社 サーバ装置、システム、情報処理装置、プログラム、及びシステムの動作方法
CN113111647B (zh) * 2021-04-06 2022-09-06 北京字跳网络技术有限公司 信息的处理方法、装置、终端和存储介质
TW202242634A (zh) * 2021-04-27 2022-11-01 新加坡商格步計程車控股私人有限公司 用於針對儲存在資料儲存器中之資料的存取進行控制之資料儲存系統及方法
CN114510729A (zh) * 2021-12-31 2022-05-17 西安即刻易用网络科技有限公司 一种企业级应用系统的组织安全转让方法
WO2023154525A1 (en) * 2022-02-14 2023-08-17 Align Technology, Inc. Clinical partner event relationship management
US11928161B2 (en) * 2022-03-04 2024-03-12 Humane, Inc. Structuring and presenting event data for use with wearable multimedia devices
US20240015158A1 (en) * 2022-07-07 2024-01-11 Capital One Services, Llc Systems and methods for granting account access to a guest contact
US11977728B1 (en) * 2022-12-22 2024-05-07 Lifetrack Medical Systems Private Ltd. Interface-integrated permissions configuration

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001209742A (ja) * 2000-01-25 2001-08-03 Fujitsu Ltd 医療情報処理システムおよび医療情報処理プログラム記憶媒体
US20050182661A1 (en) * 2004-02-17 2005-08-18 International Business Machines Corporation Method, system, and apparatus for patient controlled access of medical records
JP2009169913A (ja) * 2007-12-21 2009-07-30 Taito Corp サービス提供システム、サービス提供方法、及びコンピュータプログラム
US20100241595A1 (en) * 2000-07-06 2010-09-23 David Paul Felsher Information record infrastructure, system and method
US20120017266A1 (en) * 2010-07-01 2012-01-19 Experian Information Solutions, Inc. Systems and methods for permission arbitrated transaction services
US20140142984A1 (en) * 2012-11-21 2014-05-22 Datcard Systems, Inc. Cloud based viewing, transfer and storage of medical data
US20140180719A1 (en) * 2012-10-21 2014-06-26 Mymedlink, Llc Personal healthcare information management system and related methods
JP2014134934A (ja) * 2013-01-09 2014-07-24 Canon Inc 医療情報管理方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8281370B2 (en) * 2006-11-27 2012-10-02 Therap Services LLP Managing secure sharing of private information across security domains
US8484745B2 (en) * 2007-05-21 2013-07-09 International Business Machines Corporation Electronic calendar collaboration
US20090070146A1 (en) * 2007-09-10 2009-03-12 Sultan Haider Method for managing the release of data
US20100082371A1 (en) * 2008-10-01 2010-04-01 General Electric Company, A New York Corporation Patient Document Privacy And Disclosure Engine
NZ623737A (en) * 2010-09-28 2015-10-30 Lifetime Health Diary Ltd Systems and methods for medical data collection and display
US20150370462A1 (en) * 2014-06-20 2015-12-24 Microsoft Corporation Creating calendar event from timeline
US20170063551A1 (en) * 2014-07-25 2017-03-02 Snapfile Ltd. System and method for securely managing integrity-verifiable and authenticable information
US20160098522A1 (en) * 2014-10-07 2016-04-07 David Roey Weinstein Method and system for creating and managing permissions to send, receive and transmit patient created health data between patients and health care providers

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001209742A (ja) * 2000-01-25 2001-08-03 Fujitsu Ltd 医療情報処理システムおよび医療情報処理プログラム記憶媒体
US20100241595A1 (en) * 2000-07-06 2010-09-23 David Paul Felsher Information record infrastructure, system and method
US20050182661A1 (en) * 2004-02-17 2005-08-18 International Business Machines Corporation Method, system, and apparatus for patient controlled access of medical records
JP2009169913A (ja) * 2007-12-21 2009-07-30 Taito Corp サービス提供システム、サービス提供方法、及びコンピュータプログラム
US20120017266A1 (en) * 2010-07-01 2012-01-19 Experian Information Solutions, Inc. Systems and methods for permission arbitrated transaction services
US20140180719A1 (en) * 2012-10-21 2014-06-26 Mymedlink, Llc Personal healthcare information management system and related methods
US20140142984A1 (en) * 2012-11-21 2014-05-22 Datcard Systems, Inc. Cloud based viewing, transfer and storage of medical data
JP2014134934A (ja) * 2013-01-09 2014-07-24 Canon Inc 医療情報管理方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020166095A1 (ja) * 2019-02-14 2020-08-20 エンブレース株式会社 医療・介護分野における多職種連携支援方法及びシステム
JP2020135125A (ja) * 2019-02-14 2020-08-31 エンブレース株式会社 医療・介護分野における多職種連携支援方法及びシステム

Also Published As

Publication number Publication date
CA2972918A1 (en) 2016-08-04
EP3251079A1 (en) 2017-12-06
AU2019222854A1 (en) 2019-09-19
SG11201705605RA (en) 2017-08-30
CN107533555A (zh) 2018-01-02
WO2016123359A1 (en) 2016-08-04
US20180150650A1 (en) 2018-05-31
EP3251079A4 (en) 2018-08-29
SG10201802859XA (en) 2018-05-30
AU2016211464A1 (en) 2017-07-20
WO2016123359A8 (en) 2016-10-06
HK1248855A1 (zh) 2018-10-19

Similar Documents

Publication Publication Date Title
JP2018512085A (ja) データの所有者によって、選択された受信者のための許可を制御するシステムおよび方法
US11416901B2 (en) Dynamic forms
Pask et al. A framework for complexity in palliative care: a qualitative study with patients, family carers and professionals
US20220138689A1 (en) Generation and Data Management of a Medical Study Using Instruments in an Integrated Media and Medical System
US20190244684A1 (en) Generation and Data Management of a Medical Study Using Instruments in an Integrated Media and Medical System
US8788287B2 (en) Systems, apparatus, and methods for developing patient medical history using hierarchical relationships
US20180294048A1 (en) Patient-centric portal
US20110125527A1 (en) Systems, apparatus, and methods for identifying patient-to patient relationships
US20130066648A1 (en) Systems and methods for disease management algorithm integration
US20130054678A1 (en) Data collection form authoring system with remote client data collection and management system
US20030140043A1 (en) Clinical research data management system and method
US20140244306A1 (en) Generation and Data Management of a Medical Study Using Instruments in an Integrated Media and Medical System
WO2013070895A1 (en) Systems and methods for assembling electronic medical records
US20150234984A1 (en) Patient-Centric Portal
KR20040107894A (ko) 온라인 상에서의 의사용 의료정보 관리 방법
Bourgeois et al. Mychildren’s: integration of a personally controlled health record with a tethered patient portal for a pediatric and adolescent population
Heeney et al. Optimising ePrescribing in hospitals through the interoperability of systems and processes: a qualitative study in the UK, US, Norway and the Netherlands
Qaurooni et al. Visual Analytics for Data-Driven Understanding of the Substance Use Disorder Epidemic
CA2777554A1 (en) Generation and data management of a medical study using instruments in an integrated media and medical system
Gyebi A universal platform for electronic health records for low resource hospitals
Marref Supporting Integrated Care through Visualization of Shared Medical Documents and Communication
Kardaras et al. Case Studies in Customization of E-Health Services
Thiong'o Framework for the implementation of a patient electronic referral system: case study of Nairobi province.
Nduanya et al. AN ONLINE PATIENT DIAGNOSTIC LABORATORY APPOINTMENT BOOKING MANAGEMENT SYSTEM

Legal Events

Date Code Title Description
A529 Written submission of copy of amendment under article 34 pct

Free format text: JAPANESE INTERMEDIATE CODE: A529

Effective date: 20170927

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190107

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190107

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20191010

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191203

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200302

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200916

A045 Written measure of dismissal of application [lapsed due to lack of payment]

Free format text: JAPANESE INTERMEDIATE CODE: A045

Effective date: 20210119