患者ジャーニーデータテンプレート

athenahealth
患者ジャーニーデータテンプレート

患者ジャーニーデータテンプレート

このテンプレートは、患者ジャーニーを分析するために必要なデータを収集するための包括的なガイドを提供します。追跡すべき重要な属性とアクティビティ、そしてathenahealthからこの情報を抽出する方法に関する明確なガイダンスが示されています。このリソースを活用して、データが効果的なプロセスマイニングに対応できるように準備してください。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • athenahealthデータ抽出ガイド
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

患者ジャーニー属性

これらは、包括的な分析と患者ジャーニーの理解に不可欠な、イベントログに含めるべき推奨データフィールドです。
5 必須 10 推奨 5 任意
名前 説明
アクティビティ名
ActivityName
患者ジャーニーで実行されたイベントまたはタスクの名前。
説明

プロセス内で発生している具体的なステップを示します。例えば、「患者チェックイン済み」、「診断テストオーダー済み」、「投薬済み」などです。このテキスト文字列は、プロセスマップ内のノードを定義します。
プロセスの流れを視覚化し、操作の順序を特定するために使用されます。これらの名前の標準化は、クラスタ化されておらず、読みやすいプロセスマップにとって非常に重要です。

その重要性

プロセスマップのステップを定義し、あらゆるプロセスマイニングに必須です。

取得元

監査ログ、予約ステータス変更、または請求明細項目記述から派生します。

アポイントメント設定済み患者チェックイン済み診断テストオーダー患者退院済み
イベントのタイムスタンプ
EventTimestamp
活動が発生した具体的な日時です。
説明

アクティビティが実行された正確な瞬間を記録します。これにより、イベントを時系列で並べ、ステップ間の期間を計算します。
サイクルタイム、待機時間、スループット分析を含む時間ベースの分析に不可欠です。同日に発生するイベントの順序を解決するためには、高精度が望ましいです。

その重要性

イベントを順序付けし、すべての時間ベースのKPIを計算するために必要です。

取得元

athenahealthテーブルのステータス変更または作成日に関連付けられたタイムスタンプフィールド。

2023-10-12T08:30:00Z2023-10-12T09:15:22Z2023-10-15T14:20:00Z
ソースシステム
SourceSystem
`データ`の`発信元``システム`名です。
説明

この場合、「athenahealth」として、記録を生成したITシステムを特定します。これは、データが混在するマルチシステム環境で特に役立ちます。
アナリストがデータソースごとにビューをフィルタリングし、特定のシステムに固有のデータ品質の問題をトラブルシューティングすることを可能にします。

その重要性

マルチシステム環境のプロセスマイニング設定において、データリネージとコンテキストを提供します。

取得元

ハードコードされたリテラルまたはシステム構成ID。

athenahealthAthenaOneAthenaPractice
最終データ更新
LastDataUpdate
データが最後に抽出または更新されたタイムスタンプ。
説明

分析に使用されるデータの鮮度を示します。これにより、ユーザーはリアルタイムデータを見ているのか、それとも過去のスナップショットを見ているのかを理解できます。
データパイプラインを管理し、ダッシュボードがプロセスの最新の状態を反映していることを確認するために使用されます。

その重要性

データガバナンスとダッシュボードの最新性に対するユーザーの信頼にとって重要です。

取得元

ETL実行時のシステム時間。

2023-11-01T12:00:00Z2023-11-02T06:00:00Z
患者エピソード
PatientEpisodeId
特定の患者エピソードまたはジャーニーの一意の識別子。
説明

この属性は、患者の特定のケア期間または状態に関連するすべてのアクティビティをグループ化する中央のケース識別子として機能します。予約、診断オーダー、退院手続きなどの異なるイベントを、単一の一貫したジャーニーに結びつけます。
分析において、このIDはプロセスマイニングの主キーであり、エンドツーエンドのフローの再構築を可能にします。同じ患者による異なる状態に対する複数の受診が、別個のプロセスインスタンスとして扱われることを保証します。

その重要性

分析内の単一プロセスインスタンスのスコープを定義するために不可欠です。

取得元

athenahealthにおけるエンカウンターIDのグループ化、または特定のケアエピソードIDへのリンクから派生します。

EP-2023-88491EP-2023-99102ENC-55412-GRP
イベントの終了時刻
EventEndTime
特定のアクティビティが完了した時間。
説明

アクティビティの完了時刻を捕捉し、その前の待ち時間とは異なる、ステップ自体のアクティブな期間(処理時間)の計算を可能にします。

リソース効率を分析し、手動で実行するのに予想以上に時間がかかるタスクを特定するために使用されます。

その重要性

アクティブな処理時間とパッシブな待ち時間の計算を可能にします。

取得元

athenahealthにおけるチェックアウト時間、結果検証時間、または特定の完了タイムスタンプ。

2023-10-12T09:00:00Z2023-10-12T10:45:00Z
エンカウンタータイプ
EncounterType
受診の分類(例:外来受診、遠隔医療、緊急)。
説明

提供されるケアの様式または設定を定義します。これは汎用データモデルにおける「ケースタイプ」として機能します。

異なるエンカウンタータイプは、異なる予想されるフローと請求要件を持っています。この属性でフィルタリングすることは、サイクルタイム分析で異なる種類のものを比較することを避けるために不可欠です。

その重要性

遠隔医療と対面診療など、異なるプロセスバリアントを区別します。

取得元

athenahealthの「encountertype」フィールド。

外来受診遠隔医療緊急手術
主要診断コード
PrimaryDiagnosisCode
エピソードに関連する主要なICD-10コード。
説明

患者ジャーニーの臨床的理由を分類します。これは「年齢層と診断によるジャーニー比較」に必要なコンテキストを提供します。

異なる病状(例:肺炎と骨折)では予想される経路やサイクルタイムが大きく異なるため、アナリストはこれを使用して病状別にジャーニーをセグメント化します。

その重要性

「類似」ケースの比較を可能にします。診断によってサイクルタイムは大きく異なります。

取得元

エンカウンターまたは請求の診断フィールド(ICD-10)。

J18.9I10E11.9
再入院である
IsReadmission
このエピソードが予定外の再来院を表すかどうかを示すフラグ。
説明

前回の退院から一定期間内(例:30日以内)に患者が病院に再入院したかどうかを示すブール値インジケーターです。これは「予定外再入院の割合」KPIを直接サポートします。

この属性でフィルタリングすることで、アナリストは再入院の根本原因を深く掘り下げ、初期治療経路のパターンを特定することができます。

その重要性

再入院率KPIを直接サポートします。

取得元

ETL中に、入院日を前回の退院日と比較して計算されます。

truefalse
処理時間
ProcessingTime
アクティビティに積極的に費やされた時間。
説明

特定のタスクの開始から完了までの時間差(例:スキャン実行にかかる時間)を表します。これは汎用モデルの「ProcessingTime」に相当します。
リソース利用率を計算し、手動タスクと自動化されたタスクにおける効率のギャップを特定するために使用されます。

その重要性

総サイクルにおけるアクティブな作業と待ち時間を区別します。

取得元

計算式: EventEndTime - EventTimestamp。

15分1時間30分45秒
医療提供者名
ProviderName
アクティビティを実行する医療従事者の名前。
説明

イベントを担当した特定の医師、看護師、または技術者を特定します。この属性は、リソース利用率分析の中心です。
これにより、異なるスタッフメンバー間でのスループットやサイクルタイムなどのパフォーマンス指標を比較し、トレーニングの必要性やワークロードの不均衡を特定することができます。

その重要性

「リソース利用率」およびハンドオフ分析の鍵となります。

取得元

athenahealthの「providerid」がプロバイダーディレクトリ名に解決されたもの。

スミス医師看護師ジョーンズ技術者アダムス
患者ID
PatientId
患者の一意の識別子(匿名化/ハッシュ化)。
説明

ジャーニーを経験している顧客(患者)を一意に識別します。ケース識別子と似ていますが、一人の患者が時間とともに複数のエピソードを持つ可能性があります。
繰り返し受診をリンクし、再入院率を分析するために使用されます。「予定外再入院の割合」KPIにとって重要です。

その重要性

再入院と、エピソードを超えた患者履歴を追跡するために必要です。

取得元

athenahealthの「patientid」フィールド。

PAT-100234PAT-559201PAT-992210
患者年齢層
PatientAgeGroup
患者の年齢のカテゴリ別グループ分け(例:18-25歳、65歳以上)。
説明

患者をデモグラフィックコホートにセグメント化します。これは「年齢層および診断ジャーニー比較」ダッシュボードに直接必要です。
これにより、プロセスの非効率性やアウトカムが高齢者や小児患者など特定の年齢層に不釣り合いに影響を与えているかどうかを特定するのに役立ちます。

その重要性

医療プロセス分析のための標準的な人口統計学的セグメント。

取得元

患者の生年月日と開始時刻から派生。

18-29歳30-49歳65歳以上
退院``
DischargeDisposition
退院時の患者の行き先または状態。
説明

エピソード後に患者が「自宅」、「専門看護施設」、「ホスピス」など、どこへ行ったかを示します。これは「退院計画と再入院傾向」にとって不可欠です。
必要な退院計画の複雑さに関するコンテキストを提供し、ケア移行の有効性を評価するのに役立ちます。

その重要性

退院計画と再入院リスクに関する重要なコンテキスト。

取得元

athenahealthのエンカウンターフィールドまたは病院退院記録。

ホーム専門看護施設短期病院へ移送済み失効
部門名
DepartmentName
アクティビティが発生した病院または診療所の部門。
説明

プロセスデータを、救急、循環器科、放射線科などの機能単位でセグメント化します。これは「部門別スループットとハンドオフ」ダッシュボードにとって不可欠です。
この属性を用いた分析は、特定の領域におけるボトルネックを浮き彫りにし、部門間の患者フローを最適化するのに役立ちます。

その重要性

組織的なボトルネックや引き継ぎの非効率性を特定するために不可欠です。

取得元

athenahealthの「departmentid」が部門名に解決されたもの。

救急部門内科放射線科
手戻り
IsRework
このアクティビティが繰り返しであるかを示すフラグ。
説明

同じケース内でアクティビティが複数回発生した場合にtrueとなるブール値フラグです。「アクティビティ頻度と手戻りループ」ダッシュボードをサポートします。

手戻りを含むケースを即座に特定し、「手戻りアクティビティの頻度」KPIの計算を容易にします。

その重要性

プロセスの非効率性や冗長なステップを特定します。

取得元

CaseIdごとのアクティビティ発生に基づいてETL中に計算されます。

truefalse
注文タイプ
OrderType
オーダーの種類(例:検査、画像診断、処方)。
説明

エピソード中に発行された臨床オーダーを分類します。これは「診断テストのリードタイム」ダッシュボードにとって非常に重要です。

アナリストは、サービスレベル契約やボトルネックが異なることが多い検査と画像診断のリードタイムを具体的に測定できます。

その重要性

特定のリードタイム分析のために診断プロセスをセグメント化します。

取得元

athenahealthオーダーAPIの「ordertype」または「class」フィールド。

検査画像診断処方箋処置
総請求額
TotalChargeAmount
アクティビティまたはエピソードに請求された金額。
説明

アクティビティまたは総請求額に関連する財務的価値。これにより、コストベースのプロセスマイニングと財務影響分析が可能になります。
治療経路における高コストの変動を特定し、プロセス効率と財務的成果を関連付けるために使用されます。

その重要性

プロセス分析に財務的側面を追加します。

取得元

athenahealthの請求/課金テーブルにおける「amount」または「totalcharge」フィールド。

150.002500.5045.00
診断結果ステータス
DiagnosticResultStatus
診断オーダーのアウトカムステータス(例:陽性、正常)。
説明

検査の概要結果を捕捉します。これにより、「診断テストのリードタイム」とそれに続く治療決定のコンテキストが提供されます。

異常な結果が正常な結果と比較して、その後の迅速な行動につながるかどうかを分析するために使用されます。

その重要性

プロセスフローと臨床転帰を関連付けます。

取得元

athenahealthの検査結果観察フィールド。

通常異常クリティカル
請求ステータス
ClaimStatus
ケアに関連する財務請求のステータス。
説明

請求が「提出済み」、「拒否済み」、「支払い済み」など、どの段階にあるかを示します。「請求提出済み」アクティビティと財務スループットに関連します。
臨床文書の問題がバックエンドの財務遅延につながっているかどうかを特定するのに役立ちます。

その重要性

臨床効率を収益サイクルパフォーマンスに連携させます。

取得元

athenahealthの「claimstatus」フィールド。

請求済み保留ドロップ
必須 推奨 任意

患者ジャーニー活動

これらは、患者体験の正確な発見と最適化のために、イベントログで捕捉すべき重要なプロセスステップとマイルストーンです。
7 推奨 8 任意
アクティビティ 説明
テスト結果受領
診断テストの結果が確定され、患者のカルテで利用可能になります。これは通常、検査システムまたは画像診断システムが結果をathenahealthに送信し、タイムスタンプ付きのエントリを作成する際に捕捉されます。
その重要性

結果の受領は、診断や治療計画などのその後の臨床的決定の重要な引き金となります。このイベントは、診断のターンアラウンドタイムを測定するための終点です。

取得元

元のオーダーにリンクされた結果または診断テーブルにあります。このイベントは、結果が患者のカルテに記録または受信されたときのタイムスタンプによってマークされます。

取得

新しい結果レコードがタイムスタンプと共に作成されます。多くの場合、LISまたはRISからのインターフェースを介します。

イベントタイプ explicit
処置実施済み
手術や専門的な治療など、臨床処置が患者に対して行われます。これは、診療記録に明示的に記録されるイベントであり、しばしば処置記録に特定の開始時刻と終了時刻が記載されます。
その重要性

処置は、患者の治療における重要な節目です。処置前後の活動を分析することで、術前および術後のワークフローを最適化するのに役立ちます。

取得元

athenaClinicalsの処置記録または特定の臨床フローシート内にあります。イベントのタイムスタンプは、処置の記録された開始時刻または終了時刻から導出されます。

取得

処置が行われた日時を示すタイムスタンプを含む処置記録またはログが作成されます。

イベントタイプ explicit
初期評価完了
バイタルサインと主訴が記録された、トリアージや看護アセスメントなどの最初の臨床評価の完了を示します。このイベントは、多くの場合、診察の最初の署名済み臨床ノートまたは完了した評価フォームのタイムスタンプから推測されます。
その重要性

このマイルストーンは臨床ケアの開始を示します。チェックインからこのアクティビティまでの期間は、初期の患者待ち時間とリソース応答性を測定する主要な指標です。

取得元

athenaClinicals内の特定の臨床文書またはフロースシートの作成または署名タイムスタンプから推測されます。トリアージまたは受付に関連する文書タイプを特定する必要があります。

取得

診察記録、バイタルサイン記録、または特定の受付フォーム上の最初のタイムスタンプを特定します。

イベントタイプ inferred
患者チェックイン済み
このアクティビティは、患者の到着と、予定された予約または受診のための正式なチェックインを示します。これは通常、athenaClinicalsまたはathenaCommunicator内の予約記録の明示的なステータス変更として捕捉されます。
その重要性

これは患者の施設内ジャーニーの決定的な開始点です。待ち時間と臨床診察の全体的なサイクルタイムを測定するための重要な開始点として機能します。

取得元

予約または診察テーブルのステータス更新として記録されます。「チェックイン済み」ステータスとそれに対応するタイムスタンプを探してください。

取得

予約またはエンカウンターオブジェクトのステータス変更がタイムスタンプとともに記録されます。

イベントタイプ explicit
患者退院済み
患者は正式に退院し、施設内でのジャーニーが完了しました。これは入院患者の診察における最終ADTイベントであり、正確なタイムスタンプと共に捕捉されます。
その重要性

このイベントは、患者の主要なジャーニーの終わりを示します。これは、全体的な「患者ジャーニーサイクルタイム」を測定するための終点であり、再入院分析に不可欠です。

取得元

これはADTシステムまたは患者診察テーブル内の明示的なイベントであり、診察の最終ステータスを「退院済み」としてタイムスタンプと共にマークします。

取得

患者の診察ステータスは「退院済み」に更新され、ADTイベントが記録されます。

イベントタイプ explicit
診断確定済み
臨床医が現在の診療における患者の状態について、公式に診断を下すか確認します。これは、患者の診療に関連付けられた主要な診断コード(例:ICD-10)の作成タイムスタンプまたは「最終更新」タイムスタンプから推測できます。
その重要性

これは、その後の治療経路を決定する極めて重要なマイルストーンです。この時点以降のアクティビティの変動を分析することは、ケアプロトコルを理解し標準化するのに役立ちます。

取得元

患者の問題リストまたは診察の診断データから推測されます。診断コードの変更または確定とそれに関連するタイムスタンプがこのイベントを示します。

取得

エンカウンターの主要診断が追加または更新されたタイムスタンプを検出します。

イベントタイプ inferred
退院オーダー記載済み
医師または認定された医療提供者が、患者をケアから退院させるための公式な指示書を作成します。これは、EHRのCPOEモジュール内で作成される、明示的なタイムスタンプ付きのイベントです。
その重要性

このアクティビティは退院プロセスを開始します。このオーダーと実際の退院までの時間は、「退院計画リードタイム」の主要なパフォーマンス指標です。

取得元

オーダーテーブルにあります。このイベントは、特定の「退院」オーダータイプとその作成タイムスタンプによって識別されます。

取得

オーダータイプが「退院」の新しいレコードがオーダーテーブルに作成されます。

イベントタイプ explicit
アポイントメント設定済み
患者の予約を表します。このイベントは、ユーザーがathenahealthのスケジューリングモジュールであるathenaCommunicatorで新しい予約エントリを作成および確認する際に明示的に捕捉されます。
その重要性

このアクティビティは、多くの患者ジャーニーにおける初期の接点を示します。予約からチェックインまでの時間を分析することで、患者アクセスと受診前効率の理解に役立ちます。

取得元

これは予約またはスケジューリングテーブルに記録される明示的なイベントです。通常、作成タイムスタンプと患者IDに関連付けられています。

取得

スケジューリングモジュールで予約記録が作成された時点でイベントが記録されます。

イベントタイプ explicit
フォローアップ予約済み
主要な治療または退院後、患者のフォローアップ予約がスケジュールされます。このイベントは、athenaCommunicatorスケジューリングモジュールで新しい予約が作成されたときに明示的に捕捉されます。
その重要性

このアクティビティは、退院後のケア調整とその再入院率などのアウトカムへの影響を理解する上で重要です。ケアの継続性を示します。

取得元

予約テーブルに記録されます。このイベントは、退院日以降に発生する予約の作成タイムスタンプによって識別されます。

取得

スケジューリングシステムに新しい予約記録が作成されます。

イベントタイプ explicit
患者移送済み
患者が、例えば救急部門から入院病棟へなど、あるケアユニットまたは部門から別の部門へ移動します。これはEHR内の入院・退院・転院(ADT)イベントを通じて明示的に記録されます。
その重要性

このアクティビティは、施設内の部門間のハンドオフと患者フローを分析するために不可欠です。「患者ハンドオフ時間」とリソース配分におけるボトルネックを特定するのに役立ちます。

取得元

ADTイベントログまたは患者追跡テーブルに記録されます。各移送イベントには、患者、元/先の場所、およびタイムスタンプが含まれます。

取得

患者の転送時にADTメッセージまたはイベントログエントリがタイムスタンプと共に生成されます。

イベントタイプ explicit
投薬実施済み
薬剤は臨床スタッフによって患者に物理的に投与されます。これはathenaClinicalsの薬剤投与記録(MAR)モジュールに明示的に記録され、各投与量には正確なタイムスタンプが付与されます。
その重要性

このアクティビティは直接的な治療介入を表します。そのタイミングを分析することで、「初回治療までの時間」を測定し、投薬スケジュールへの遵守を保証するのに役立ちます。

取得元

MARデータテーブルにあります。各投与イベントには、患者ID、薬剤ID、投与量、および投与のタイムスタンプが含まれています。

取得

薬剤が投与されたと文書化されるたびに、MARにタイムスタンプ付きの記録が作成されます。

イベントタイプ explicit
検体採取済み
血液や尿などの生体検体が検査のために患者から採取されるイベントを表します。これは通常、検査モジュールに明示的に記録されるイベント、またはオーダーの状態更新として記録されます。
その重要性

これは診断テストプロセスにおける重要なマイルストーンです。オーダー、採取、および結果の間の時間は、検査ワークフローにおける重大なボトルネックを明らかにすることができます。

取得元

このイベントは、検査オーダーのステータス変更として、またはathenahealthと連携した検査情報システム内の個別のイベントとして見つけることができます。「採取済み」ステータスとタイムスタンプを探してください。

取得

検査オーダーのステータス更新として、または専用の検体追跡モジュールに記録されます。

イベントタイプ explicit
治療計画策定済み
臨床医による患者の治療計画の正式な作成と文書化を表します。これは、特定の「ケアプラン」文書の作成または署名、または関連する治療オーダーのセットとして捕捉できます。
その重要性

このアクティビティは、意図された臨床経路を正式化します。標準プロトコルへの適合性を測定し、ケアの変動を分析するための重要なポイントです。

取得元

臨床文書またはオーダーテーブルに見られる可能性が高いです。このイベントは、署名されたケアプランノートのタイムスタンプ、または調整された一連の治療オーダーの提出に対応します。

取得

イベントとは、特定の治療計画書またはオーダーセットの作成または最終確定のタイムスタンプです。

イベントタイプ explicit
診断テストオーダー
医師が臨床検査、画像診断スキャン、その他の処置のような診断テストのオーダーを出します。これは、athenaClinicalsのCPOE(Computerized Provider Order Entry)機能を通じて作成される、明示的なタイムスタンプ付きイベントです。
その重要性

これは、診断サブプロセスを開始する重要な決定ポイントです。このアクティビティを追跡することは、オーダーから結果までの「診断テストリードタイム」KPIを分析するために不可欠です。

取得元

オーダーテーブルにあります。各オーダーには、患者識別子、オーダー名、オーダー状況、および作成タイムスタンプが含まれます。

取得

システムのオーダーテーブルに新しいレコードがタイムスタンプと共に作成されます。

イベントタイプ explicit
請求の提出
患者の診療中に提供されたサービスに対する請求が生成され、支払い者に提出されます。これはathenaCollectorの収益サイクル管理モジュール内の明示的なイベントです。
その重要性

管理上のステップではありますが、このアクティビティは臨床ジャーニーと並行して実行される収益サイクルプロセスを分析するために不可欠です。臨床ケアと請求の間の遅延を特定するのに役立ちます。

取得元

請求または課金テーブルにあります。イベントは請求の作成または提出タイムスタンプによってマークされます。

取得

請求レコードが作成され、そのステータスがタイムスタンプとともに「提出済み」に更新されます。

イベントタイプ explicit
推奨 任意

抽出ガイド

athenahealthからデータを取得する方法