世帯データモデルを確認する

学習の目的

この単元を完了すると、次のことができるようになります。

• Health Cloud のコンテキスト内におけるデータモデルの利用目的について説明する。
• 患者のヘルスケアジャーニーにHealth Cloud データモデルを対応付ける。
• Health Cloud で患者レコードとメンバーレコードに個人取引先を使用する理由を説明する。
• Health Cloud の世帯データモデルのリレーションについて説明する。

Health Cloud のデータモデル

Health Cloud のデータモデルは、特定のヘルスケアビジネスプロセスをサポートするオブジェクトと項目を表します。このデータモデルは Health Cloud の機能の基盤となっています。また、このデータモデルにより、Health Cloud に保存可能なデータの種類を詳細に把握できます。Health Cloud の実装と導入を成功させるためには、データモデルを理解する必要があります。 

「データモデル」モジュールを完了された方は、データモデルがデータベーステーブルの構造をわかりやすく示すための方法であることをご存知だと思います。Salesforce では、データベーステーブルはオブジェクト、列は項目、行はレコードとみなされます。 

Salesforce での「データモデル」は、オブジェクトのコレクションであり、オブジェクトの相互のつながり (関連性) と考えてください。  

データモデルを理解すれば、新しい機能を実装するときに、Health Cloud ですでにどのような作業が可能になっているのかがわかります。そのため、既存の機能と重複するカスタムオブジェクトや項目を作成しないようにしたり、将来リリースされる新機能や拡張機能を利用したりすることができます。 

患者のヘルスケアジャーニー

このモジュールでは、Charles Green という患者のヘルスケアジャーニーに関連する Health Cloud データモデルを紹介します。

Charles は腰に痛みがあるため病院を訪れます。医師は検査を行って病状を診断し、痛みを抑えるために Pain-Away という薬剤を処方します。また、医師は、この薬剤を処方されている患者を対象としたケアプログラムに Charles を登録します。Charles がケアプログラムに登録されると、チームが Charles の健康状態を管理するためのケアプランを作成します。Charles はケアプログラムのアンケートで、「車を持っておらず、決められた日時に処方薬を取りに行けない」と回答します。 

Charles が加入している医療保険プランでは、リハビリテーションサービスも給付の対象になっています。そこで、Charles は症状の改善をサポートしてくれる理学療法士を見つけ、理学療法士との予定をスケジュールします。理学療法士は、Charles の医療保険会社である Bloomington Health Plans に理学療法セッションの事前承認要請を送信します。その後、理学療法士は、請求を申請する前に Charles の給付を確認します。

このシナリオを関連する Health Cloud のデータモデルに対応付けてみましょう。

このモジュールでは、上記に挙げたデータモデルの大部分を詳しく見ていきながら、シナリオを拡張します。また、各データモデルの利用目的を紹介し、シナリオに関連する主要なオブジェクトを説明します。各データモデルでは Health Cloud の特定の観点が示され、一部のオブジェクトは複数の図に表示されます。たとえば、各データモデルには患者を表す取引先オブジェクト (個人レコードタイプ) が含まれています。まず、このオブジェクトから見ていきましょう。 

患者とメンバーの個人レコード

Salesforce で作業したことがあれば、従来の取引先 - 取引先責任者モデルをよくご存知でしょう。このモデルでは、取引先は組織を表し、取引先責任者は人を表します。取引先責任者が存在するのは、取引先との関係においてのみです。 

従来の取引先 - 取引先責任者モデルは、人や組織をモデル化するのに適しています。ただし、大半のヘルスケア組織は患者やメンバーを組織の一部と考えていません。そのため、Health Cloud では、ヘルスケアの患者やメンバーを表すために個人取引先を使用します。

Health Cloud では、患者やメンバーを常に個人取引先としてモデル化します。患者やメンバーを個人取引先としてモデル化しないと、Health Cloud の機能を十分に使用することはできません。同じ個人取引先レコードで、Charles は患者およびメンバーとして表されます。個人取引先には、姓や名、役職、住所、生年月日など、組織ではなく人間に適用される情報が保存されます。 

データベースでは、個人取引先はレコードタイプが個人である取引先です。個人取引先レコードでは、人を表すために取引先と取引先責任者が組み合わされているため、その人物を組織と関連付ける必要はありません。

この例では、ユーザービュー (1) に Charles Green という人物のレコードが 1 件表示されています。このレコードには、取引先レコードと取引先責任者レコードの情報が統合されています。ただし、バックグラウンドのデータベースビュー (2) を見ると、このレコードは実際には 1 対 1 で双方向にリンクされた取引先と取引先責任者であり、1 人の人物を表していることがわかります。 

組織や他の人のレコードが、Charles の個人取引先レコードとどのように関連しているかを見てみましょう。

世帯データモデル

Health Cloud のコンテキストにおける世帯データモデルでは、患者やメンバーとそのケアに関わる人々や組織間のリレーションが対応付けられます。この対応付けにより、ケア担当者は患者に関わり、適切なケアを提供する際に、より効率的に作業できるようになります。 

取引先オブジェクトと取引先責任者オブジェクトは、こういったケア担当者や組織を表します。法人取引先レコードは組織を表します。個人取引先レコードまたは取引先責任者レコードは人を表します。リレーション種別は、組織と人、2 つの組織、または 2 人の人物の間のリレーションであるかどうかを決定します。  

取引先と取引先責任者のリレーション、取引先間リレーション、取引先責任者間リレーションの各連結オブジェクトは、リレーション種別を表します。連結オブジェクトは、2 つの親 - 子リレーションがあるオブジェクトであり、オブジェクト間に多対多のリレーションを作成するための要となります。つまり、1 つの親レコードは多数の子レコードと関連し、その各子レコードは多数の親レコードと関連する可能性があるということです。たとえば、1 つの取引先レコードは多数の取引先責任者レコードと関連し、同様に 1 つの取引先責任者レコードは多数の取引先と関連する可能性があります。

各リレーション種別の意味を次に示します。

いくつかの例を挙げて、実際に見てみましょう。

例 1

Charles は Shawna Green と婚姻関係にあります。 

Charles の個人取引先レコード (1) には、Shawna の個人取引先レコード (3) との取引先責任者間リレーション (2) があります。[ロール] 項目には、各リレーションの性質に関するさらに詳しい情報が追加されています。この例では [配偶者] です。

例 2

Charles と Shawna が Green 世帯を構成しています。 

Charles の個人取引先レコード (1) には、Green 世帯取引先レコード (3) との取引先と取引先責任者のリレーション (2) があります。Charles は患者であるため、世帯の主取引先責任者になります。また、Shawna の個人取引先レコード (4) にも、Green 世帯取引先レコードとの取引先と取引先責任者のリレーション (5) があります。Shawna は世帯の副取引先責任者になります。

例 3

Charles は、通院予定のために車を必要としています。Charles は Bloomington Health Plans の医療保険プランに加入しており、保険給付の対象として患者の送迎が含まれています。Patient Shuttle Transportation は、このサービスの承認済みのサービス提供者です。Anna Jones は Patient Shuttle Transportation の従業員です。交通手段コーディネーターとして、Charles の医療予定の送迎サービスを手配します。 

この例には、3 つのリレーション種別がすべて含まれています。

Charles の例では、先に世帯マップから説明しました。次の単元では、Charles がヘルスケアジャーニーの最初の一歩を踏み出したときに戻って説明します。

リソース

• Salesforce ヘルプ: Salesforce Health Cloud 開発者ガイド
• Salesforce ヘルプ: 多対多オブジェクトリレーションの作成