Skip to main content

利用管理データモデルを理解する

学習の目的 

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

  • Health Cloud の利用管理データモデルの利用目的を説明する。
  • ケア要請のオブジェクトを説明する。
  • ヘルスケアのその他の Health Cloud データモデルを挙げる。

利用管理データモデル

利用管理 (UM) とは、事前承認などの管理されたケアの手法を使用することです。これにより、根拠に基づく基準やガイドラインを用いて、給付を行う前に給付の妥当性を評価することで、支払者はヘルスケア給付の費用を管理できるようになります。UM を使用すると、患者は確実に適切なケアを適切なタイミング、期間、設定で受けられます。

Health Cloud の利用管理では、OmniStudio コンポーネントを組み合わせることで、承認要請の送信とレビューを管理するユーザーに対して、ガイド付きのユーザーインタラクションを提供します。OmniScript は、承認要請の作成と送信、管理者、看護師、メディカルディレクターによる承認要請のレビュー、要請元の提供者とのピアツーピアレビューを行うために利用できます。 

ビジネスルールエンジンコンポーネントでは、承認プロセスの合理化、複雑なルックアップの簡略化、承認要請ワークフローにおけるビジネス上の意思決定の自動化が行われます。

UM データモデルは、外部システムとの相互運用性と統合のために FHIR R4 に適合しています。UM には、外部の電子カルテ (EHR) システムや支払者システムでの要請処理が中断しないように、MuleSoft 上にリリースされた API と統合アプリケーションが含まれています。この API は、FHIR Da Vinci Health Record Exchange (HRex) の実装ガイドに従っています。

利用管理データモデルには、事前承認要請や処方または医療サービス要請などのケア要請を評価するためのオブジェクトが用意されています。この単元では、例として事前承認要請を使用します。

Charles Green が理学療法士の Sara Johnson を初めて訪ねたとき、Sara は腰痛を治療するために 10 回の理学療法セッションが必要だと判断しました。 

Sara はセッションの事前承認要請を Charles の医療保険プランの提供者である Bloomington Health Plans に送信します。また、Bloomington Health Plans が要請 (ケース) を評価するために必要な詳細を入力します。 

Charles に 10 回の理学療法セッションを推奨する Sara。

Melinda Smith は Bloomington Health Plans の利用管理看護師です。Melinda は要請を評価し、医療必要度ガイドラインに基づき、要請を承認すべきであると判断します。その後、承認を確認してもらうため、Barbara Brown 医師 (メディカルディレクター) に事前承認要請を照会します。Brown 医師は要請を評価し、Charles の病歴に基づいて要請を承認します。 

このシナリオを利用管理データモデルのオブジェクトに対応付けてみましょう。 

ケア要請

Sara は、Bloomington Health Plans に Charles の理学療法セッションの事前承認要請を送信します。ケア要請、ケア要請延長、ケースのエンティティでは、承認要請の詳細が取得されます。 

ケア要請オブジェクトと関連オブジェクト。

オブジェクトとレコードの概要を次に示します。 

シナリオの詳細 オブジェクトとレコードの詳細

Sara Johnson は事前承認を要請する医師です。

個人レコードタイプの取引先オブジェクト (1) は、要請医師とサービス提供医師を表します。要請医師とサービス提供医師は別の人であってもかまいませんが、この例では Sara がすべて行います。

Sara Johnson が事前承認要求を送信します。

ケア要請 (2) はケア関連要請の一般的な詳細を表します。ケア要請には、薬品とサービスの事前承認、入院通知、入院時の病院滞在審査が含まれます。1 つの要請に複数の診断とサービスとを含めることができます。 

Sara の事前承認要請によりケースレコードが生成されます。

ケース (3) は事前承認のケースレコードを表します。このオブジェクトでは、マイルストーンやエンタイトルメントに基づく SLA 追跡およびワークフロー管理のためのオムニチャネルルーティングを設定できます。

Sara の事前承認要請には、メンバーの医療保険に関連する追加の詳細が含まれています。

ケア要請延長 (4) は、メンバーの医療保険の加入者情報など、ケア要請の追加詳細を表します。

Charles はケアが必要なメンバーです。 

個人レコードタイプの取引先オブジェクト (5) は Charles Green をメンバーとして表します。

Charles は Bloomington Health Plans の PPO メンバープランに加入しており、このプランにはリハビリテーションサービスの給付が含まれています。

メンバープラン (6) はメンバープランを表します。このオブジェクトは、Charles のメンバープランに関連する給付の詳細を保存する給付保障、給付保障項目、給付保障項目制限の各オブジェクトに関連しています。 

Sara の要請には、要請の詳細に 10 回の理学療法セッションが含まれています。

ケア要請品目 (7) はケアサービス要請の詳細を表します。 

Sara は Charles の健康状態の診断として腰痛を示します。

ケア診断 (8) は、コード種別、名前、説明などの診断の詳細を表します。 

Melinda Smith と Barbara Brown 医師がケア要請を審査します。

ケア要請確認者 (9) は、名前、確認者種別、審査の最後でのケア要請の状況、確認者のメモ、審査の日付などのケア要請確認者の詳細を表します。 

この単元で紹介したオブジェクトの詳細、および利用者管理データモデルの全体像については、『Salesforce Health Cloud 開発者ガイド』を参照してください。

これで、Charles のヘルスケアジャーニーを最後まで一緒に確認し、Health Cloud で使用可能な複数のヘルスケアデータモデルの利用目的を理解できました。上出来です。ただし、まだ学ぶべきことがあります。 

その他のヘルスケアデータモデル

Health Cloud には、『Salesforce Health Cloud 開発者ガイド』で学習できるヘルスケアデータモデルが他にもあります。 

Salesforce の新規リリースのたびに、データモデルの機能強化や更新に十分な注意を払うことをお勧めします。機能強化や更新は、Health Cloud が新しい業界標準に合わせたり、Health Cloud に新機能や拡張機能が追加されたりする場合に発生します。 

このモジュールで取り上げなかったデータモデルの概要を次に示します。

データモデル 説明

給付確認

提供されるサービスや商品の給付保障を決定する際にヘルスケア組織をサポートします。

統合ケア管理

患者やメンバーのケアプランに関連する臨床データを保存するためのオブジェクトを提供します。このデータモデルは USCDI と FHIR R4 に従っており、システムの相互運用性の確保に役立ちます。

インテリジェントな予定管理

さまざまな電子カルテプラットフォーム上で動作する複数のスケジュールソースシステムを操作するのに役立つオブジェクトを提供します。

インテリジェントなドキュメントの自動化

ドキュメントの受領から処理まで、ドキュメント管理プロセスを簡略化し、データの手動入力の手間を省き、患者やメンバーのすべてのフォームを 1 か所で管理するためのオブジェクトを提供します。

リモート監視と機器の登録

スマートウォッチや心臓モニターなど、患者やプログラムメンバーに支給された機器から収集したデータを管理するためのオブジェクトを提供します。

統合健康スコアリング

Score (スコア) データモデルでは、総合健康スコアリングのスコアリストと統合健康スコアリングのスコアの詳細のコンポーネントに使用される情報が保存および処理されます。

Actions (アクション) データモデルでは、総合健康スコアリングの動的アクションコンポーネントでユーザーがアクションを実行するために、コンテキストに応じたプロンプトの表示がサポートされています。

リソース 

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む