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

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

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

このテンプレートでは、患者ジャーニーを分析するために必要なデータを収集する方法を詳しく説明します。追跡すべき重要な属性とアクティビティに加え、athenahealthから情報を抽出する方法も明確に示しています。プロセスマイニングに適したデータを準備するためにご利用ください。
  • 収集を推奨する属性
  • 追跡すべき主要なアクティビティ
  • athenahealthからの抽出ガイド
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

患者ジャーニーの属性

患者ジャーニーを詳しく分析し、理解するために不可欠な、イベントログに含める推奨データ項目です。
5 必須 9 推奨 5 任意
名前 説明
アクティビティ名
ActivityName
患者のプロセスで実行されたイベントまたはタスクの名前です。
説明

「Patient Checked In」「Diagnostic Test Ordered」「Medication Administered」など、プロセス内で発生した具体的なステップを示します。この文字列によって、プロセスマップ上のノードが定義されます。

プロセスフローの可視化と処理順序の特定に使用します。整理され、読みやすいプロセスマップにするには、これらの名称を標準化することが欠かせません。

重要な理由

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

入手先

監査ログ、予約ステータスの変更、または請求明細の説明から取得します。

予約確定患者のチェックイン完了診断検査の依頼患者の退院
イベントタイムスタンプ
EventTimestamp
アクティビティが発生した具体的な日時です。
説明

アクティビティが実行された正確な時点を記録します。イベントを時系列に並べ、ステップ間の所要時間を計算するために使用します。

サイクルタイム、待ち時間、スループット分析など、時間に基づく分析に欠かせません。同じ日に発生したイベントの順序を判別できるよう、高い精度が望まれます。

重要な理由

イベントの順序付けと、時間に基づくすべてのKPIの計算に必要です。

入手先

athenahealthのテーブルにある、ステータス変更または作成日に関連付けられたタイムスタンプ項目です。

2023-10-12T08:30:00Z2023-10-12T09:15:22Z2023-10-15T14:20:00Z
ソースシステム
SourceSystem
データの取得元となったシステムの名前です。
説明

レコードを生成したITシステムを特定します。この場合は「athenahealth」です。データを複数のシステムから統合する環境で特に役立ちます。

データソースで表示を絞り込み、特定のシステムに起因するデータ品質の問題を調査できます。

重要な理由

複数システムを対象とするプロセスマイニング環境で、データの系譜と背景情報を提供します。

入手先

ハードコードされたリテラル、またはシステム設定のIDです。

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

分析に使用するデータの鮮度を示します。リアルタイムデータを見ているのか、過去のスナップショットを見ているのかを把握できます。

データパイプラインの管理や、ダッシュボードにプロセスの最新状態を反映するために使用します。

重要な理由

データガバナンスと、ダッシュボードの最新性に対する利用者の信頼を支える重要な項目です。

入手先

ETL実行時点のシステム時刻です。

2023-11-01T12:00:00Z2023-11-02T06:00:00Z
患者エピソード
PatientEpisodeId
特定の患者エピソードまたはプロセスを一意に識別するIDです。
説明

この属性は中心的なケース識別子として機能し、患者の特定のケア期間または状態に関連するすべてのアクティビティをまとめます。予約、診断依頼、退院処理などの個別のイベントを、1つの一貫したプロセスとして結び付けます。

分析では、このIDがプロセスマイニングにおける主キーとなり、エンドツーエンドのフローを再構築できます。同じ患者が異なる状態で複数回受診した場合も、それぞれを別個のプロセスインスタンスとして扱えます。

重要な理由

分析対象となる単一のプロセスインスタンスの範囲を定義するために必要です。

入手先

Encounter IDをグループ化するか、athenahealthの特定のEpisode of Care IDに関連付けて生成します。

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

アクティビティの完了時刻を記録し、ステップ自体の実作業時間と、その前の待ち時間を分けて計算できます。

リソース効率の分析や、手作業での実行に想定以上の時間がかかるタスクの特定に使用します。

重要な理由

実作業時間と待ち時間を分けて計算できます。

入手先

チェックアウト時刻、結果確認時刻、またはathenahealthに記録された特定の完了時刻です。

2023-10-12T09:00:00Z2023-10-12T10:45:00Z
主診断コード
PrimaryDiagnosisCode
エピソードに関連付けられた主診断のICD-10コードです。
説明

患者のプロセスにおける臨床上の理由を分類します。「年齢層別・診断別の患者プロセス比較」に必要な背景情報を提供します。

状態によって想定される経路やサイクルタイムが大きく異なるため、分析担当者はこの項目を使って、肺炎や骨折など状態別にプロセスを分けて分析します。

重要な理由

同種のケースを比較できます。診断によってサイクルタイムは大きく異なります。

入手先

受診または請求の診断項目(ICD-10)です。

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

前回の退院から一定期間(例:30日)以内に患者が病院へ戻ったかどうかを示すブール型の属性です。これは「予定外の再入院率」KPIを直接支援します。

この属性で絞り込むことで、分析担当者は再入院の根本原因を詳しく調べ、初回の治療経路に見られるパターンを特定できます。

重要な理由

再入院率KPIを直接支援します。

入手先

入院日と直前の退院日を比較し、ETL処理中に算出します。

truefalse
医療提供者名
ProviderName
アクティビティを実施した医療従事者の名前です。
説明

イベントを担当した医師、看護師、技師などを特定します。リソース利用分析の中心となる属性です。

スタッフごとのスループットやサイクルタイムなどのパフォーマンス指標を比較し、研修の必要性や業務負荷の偏りを特定できます。

重要な理由

「リソース利用率」の算出と引き継ぎ分析に必要です。

入手先

athenahealthの「providerid」を医療提供者ディレクトリの名前に変換した値です。

Smith医師Jones看護師Adams技師
受診タイプ
EncounterType
受診の分類です(例:外来受診、遠隔医療、救急)。
説明

提供されたケアの形態または環境を定義します。汎用データモデルでは「ケースタイプ」に相当します。

受診タイプによって想定されるフローや請求要件が異なります。サイクルタイム分析で比較対象を適切にそろえるには、この属性による絞り込みが欠かせません。

重要な理由

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

入手先

athenahealthの「encountertype」項目です。

外来診療遠隔医療救急手術
患者ID
PatientId
患者を一意に識別するIDです(匿名化またはハッシュ化済み)。
説明

プロセスをたどる患者を一意に識別します。ケース識別子と似ていますが、1人の患者が時間をおいて複数のエピソードを持つ場合があります。

再受診を関連付け、再入院率を分析するために使用します。「予定外再入院率」KPIに欠かせません。

重要な理由

エピソードをまたいだ再入院と患者履歴の追跡に必要です。

入手先

athenahealthの「patientid」項目です。

PAT-100234PAT-559201PAT-992210
患者の年齢層
PatientAgeGroup
患者の年齢をカテゴリに分けた項目です(例:18~25歳、65歳以上)。
説明

患者を人口統計上のコホートに分けます。「年齢層別・診断別の患者プロセス比較」ダッシュボードに直接必要です。

高齢患者や小児患者など、特定の年齢層にプロセスの非効率や成果への影響が偏っていないかを特定できます。

重要な理由

医療プロセス分析で標準的に使用する人口統計上の区分です。

入手先

患者の生年月日とStartTimeから生成します。

18-2930-4965+
退院先
DischargeDisposition
退院時の患者の行き先または状態です。
説明

エピソード後に患者が向かった先を示します。たとえば「自宅」「熟練看護施設」「ホスピス」などです。「退院計画と再入院の傾向」を分析するうえで重要です。

退院計画の複雑さを把握し、ケア移行の有効性を評価するための背景情報を提供します。

重要な理由

退院計画と再入院リスクを理解するために欠かせない情報です。

入手先

athenahealthの受診フィールドまたは退院記録。

自宅熟練看護施設短期入院病院へ転院死亡
部門名
DepartmentName
アクティビティが発生した病院またはクリニックの部門です。
説明

救急、循環器、放射線などの機能単位でプロセスデータを分けます。「部門別スループットと引き継ぎ」ダッシュボードに欠かせません。

この属性を使った分析により、特定領域のボトルネックを明らかにし、部門間の患者フローを改善できます。

重要な理由

組織のボトルネックと、引き継ぎにおける非効率を特定するために欠かせません。

入手先

athenahealthの「departmentid」を部門名に変換した値です。

救急部内科放射線科
やり直しかどうか
IsRework
このアクティビティが繰り返されているかどうかを示すフラグ。
説明

同じケース内でアクティビティが複数回発生した場合にtrueとなるブール型のフラグです。これは「アクティビティ頻度とやり直しループ」ダッシュボードを支援します。

やり直しを含むケースをすぐに抽出できるため、「やり直しアクティビティの頻度」KPIの算出に役立ちます。

重要な理由

プロセスの非効率や重複した手順を特定します。

入手先

CaseIdごとのアクティビティ発生回数に基づき、ETL処理中に算出します。

truefalse
依頼タイプ
OrderType
依頼のカテゴリです(例:検査、画像診断、処方)。
説明

エピソード中に登録された臨床依頼を分類します。「診断検査リードタイム」ダッシュボードに欠かせません。

検査と画像診断ではサービスレベル合意やボトルネックが異なることが多いため、それぞれのリードタイムを測定できます。

重要な理由

診断プロセスを分け、リードタイムを個別に分析できます。

入手先

athenahealthの「ordertype」、またはOrders APIの「class」です。

検査室画像検査処方処置
診断結果ステータス
DiagnosticResultStatus
診断オーダーの結果ステータス(例:陽性、正常)。
説明

検査の概要結果を記録します。これにより、「診断検査のリードタイム」や、その後の治療判断を把握できます。

異常結果の場合に、正常結果と比べて後続アクションが早く行われるかを分析するために使用します。

重要な理由

プロセスフローと臨床結果を結び付けます。

入手先

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

正常異常緊急
請求ステータス
ClaimStatus
診療に関連する財務請求のステータス。
説明

請求が「提出済み」「否認」「支払い済み」のどの状態にあるかを示します。「請求提出」アクティビティや財務スループットに関係します。

臨床文書の問題が、請求処理の遅延につながっているかを特定するのに役立ちます。

重要な理由

臨床業務の効率と収益サイクルのパフォーマンスを結び付けます。

入手先

athenahealthの「claimstatus」フィールド。

請求済み保留ドロップ
請求総額
TotalChargeAmount
アクティビティまたはエピソードに対して請求された金額。
説明

アクティビティに関連する金額、または請求総額です。これにより、コストに基づくプロセスマイニングと財務影響の分析が可能になります。

治療経路における高コストのばらつきを特定し、プロセス効率と財務結果の関係を分析するために使用します。

重要な理由

プロセス分析に財務面の視点を加えます。

入手先

請求・料金テーブルにあるathenahealthの「amount」または「totalcharge」。

150.002500.5045.00
必須 推奨 任意

患者ジャーニーのアクティビティ

患者体験を正確にディスカバリーし、最適化するため、イベントログに記録すべき重要なプロセス手順と節目です。
7 推奨 8 任意
アクティビティ 説明
処置の実施
手術や専門的な治療などの臨床処置を患者に実施します。通常は、処置記録に開始時刻と終了時刻を含む明示的なイベントとして記録されます。
重要な理由

処置は患者の治療における重要なマイルストーンです。処置の前後に行われるアクティビティを分析することで、術前・術後のワークフローを最適化できます。

入手先

athenaClinicalsの処置記録または特定の臨床フローシートで確認できます。イベントのタイムスタンプは、処置の記録上の開始時刻または終了時刻から取得します。

取得

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

イベントタイプ explicit
初回評価の完了
トリアージや看護評価など、バイタルサインと主訴を記録する最初の臨床評価が完了したことを示します。多くの場合、受診に関する最初の臨床記録への署名日時、または完了した評価フォームのタイムスタンプから推定します。
重要な理由

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

入手先

athenaClinicals内の特定の臨床文書またはフローシートの作成日時や署名日時から推定します。トリアージまたは受付に該当する文書タイプを特定する必要があります。

取得

受診に関する臨床記録、バイタルサインのフローシート、または特定の受付フォームに記録された最初のタイムスタンプを特定します。

イベントタイプ inferred
患者のチェックイン完了
予約した診察または受診のために患者が到着し、正式にチェックインしたことを示します。通常は、athenaClinicalsまたはathenaCommunicator内の予約レコードに対する明示的なステータス変更として記録されます。
重要な理由

患者が施設内でたどるプロセスの正式な開始点です。待ち時間や診療の全体的なサイクルタイムを測定するうえで重要な起点になります。

入手先

予約または受診テーブルのステータス更新として記録されます。「Checked-In」ステータスと対応するタイムスタンプを確認してください。

取得

予約または受診オブジェクトのステータス変更が、タイムスタンプ付きで記録されます。

イベントタイプ explicit
患者の退院
患者が正式に退院し、施設内でのプロセスが完了したことを示します。入院受診における最後のADTイベントであり、正確なタイムスタンプとともに記録されます。
重要な理由

患者の主要なプロセスの終了を示します。全体の「患者プロセスサイクルタイム」を測定する終点であり、再入院分析にも欠かせません。

入手先

ADTシステムまたは患者受診テーブルに明示的なイベントとして記録され、受診の最終ステータスが「Discharged」になったことをタイムスタンプとともに示します。

取得

患者受診のステータスが「Discharged」に更新され、ADTイベントが記録されます。

イベントタイプ explicit
検査結果の受領
診断検査の結果が確定し、患者のカルテで確認できる状態になったことを示します。通常は、検査システムまたは画像診断システムからathenahealthに結果が送信され、タイムスタンプ付きの記録が作成された時点で取得されます。
重要な理由

結果の受領は、診断や治療計画など、その後の臨床判断につながる重要なトリガーです。このイベントは、診断のターンアラウンドタイムを測定する終点になります。

入手先

元の依頼に関連付けられた結果または診断テーブルにあります。結果が患者のカルテに登録または受信された時点のタイムスタンプでイベントを特定します。

取得

通常はLISまたはRISからの連携によって、新しい結果レコードがタイムスタンプ付きで作成されます。

イベントタイプ explicit
診断の確定
担当医療者が、今回の受診における患者の状態について診断を正式に付与または確定します。患者の受診に関連付けられた主診断コード(ICD-10など)の作成日時または「最終更新日時」から推定できます。
重要な理由

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

入手先

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

取得

受診における主診断が追加または更新された時点のタイムスタンプを検出します。

イベントタイプ inferred
退院指示の作成
医師または権限を持つ医療提供者が、患者を医療機関でのケアから退院させる正式な指示を作成します。EHRのCPOEモジュール内で作成される、明示的なタイムスタンプ付きイベントです。
重要な理由

このアクティビティによって退院プロセスが開始されます。この指示から実際の退院までの時間は、「退院計画リードタイム」の重要なパフォーマンス指標です。

入手先

依頼テーブルにあります。特定の「Discharge」依頼タイプと、その作成日時によってイベントを特定します。

取得

依頼タイプが「Discharge」の新しいレコードが、依頼テーブルに作成されます。

イベントタイプ explicit
フォローアップ予約の確定
主な治療または退院後に、患者のフォローアップ予約を設定します。athenaCommunicatorの予約管理モジュールで新しい予約が作成された時点で、明示的なイベントとして記録されます。
重要な理由

退院後のケア連携と、再入院率などの成果への影響を把握するうえで重要なアクティビティです。ケアの継続性を示します。

入手先

予約テーブルに記録されます。退院日より後に行われる予約の作成日時によってイベントを特定します。

取得

予約管理システムに新しい予約レコードが作成されます。

イベントタイプ explicit
予約確定
患者の予約を登録することを示します。athenahealthの予約管理モジュールであるathenaCommunicatorで、ユーザーが新しい予約を作成して確定した時点で、このイベントが明示的に記録されます。
重要な理由

このアクティビティは、多くの患者プロセスにおける最初の接点を示します。予約からチェックインまでの時間を分析することで、患者の受診しやすさと受診前の業務効率を把握できます。

入手先

予約またはスケジュールのテーブルに明示的なイベントとして記録されます。通常は、作成日時と患者IDが関連付けられています。

取得

予約管理モジュールで予約レコードが作成された時点で記録されます。

イベントタイプ explicit
患者の搬送
患者を、あるケアユニットまたは部門から別の場所へ移動します。たとえば、救急部門から入院病棟への移動などです。EHRのAdmission、Discharge、Transfer(ADT)イベントとして明示的に記録されます。
重要な理由

施設内の部門間の引き継ぎと患者フローを分析するうえで重要なアクティビティです。「患者引き継ぎ時間」におけるボトルネックと、リソース配分の問題を特定できます。

入手先

ADTイベントログまたは患者追跡テーブルに記録されます。各搬送イベントには、患者、搬送元と搬送先、タイムスタンプが含まれます。

取得

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

イベントタイプ explicit
検体採取
検査のために、血液や尿などの生体検体を患者から採取するイベントを示します。通常は、検査モジュールに明示的なイベントとして記録されるか、依頼ステータスの更新として記録されます。
重要な理由

診断検査プロセスにおける重要なマイルストーンです。依頼、採取、結果取得の間隔を確認することで、検査業務の重大なボトルネックを把握できます。

入手先

検査依頼のステータス変更、またはathenahealthと連携する検査情報システム内の個別イベントとして確認できます。「Collected」ステータスとタイムスタンプを確認してください。

取得

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

イベントタイプ explicit
治療計画の策定
医療者が患者の治療計画を正式に作成し、記録することを示します。特定の「ケア計画」文書の作成または署名、あるいは関連する一連の治療依頼として取得できます。
重要な理由

このアクティビティによって、予定されている臨床経路が正式に定められます。標準プロトコルへの適合度を測定し、ケアのばらつきを分析する重要な時点です。

入手先

臨床文書または依頼テーブルで確認できる可能性があります。署名済みのケア計画記録、または連携された一連の治療依頼が送信された時点のタイムスタンプに対応します。

取得

特定の治療計画文書または依頼セットが作成または確定された時点のタイムスタンプです。

イベントタイプ explicit
薬剤の投与
医療スタッフが患者に薬剤を実際に投与します。athenaClinicalsのMedication Administration Record(MAR)モジュールに、投与ごとの正確なタイムスタンプとともに明示的に記録されます。
重要な理由

このアクティビティは、直接的な治療介入を示します。実施時刻を分析することで、「初回治療までの時間」を測定し、投薬スケジュールの遵守状況を確認できます。

入手先

MARデータテーブルで確認できます。各投与イベントには、患者ID、薬剤ID、用量、投与時刻のタイムスタンプが記録されます。

取得

薬剤を投与したことが記録されるたびに、MARにタイムスタンプ付きのレコードが作成されます。

イベントタイプ explicit
診断検査の依頼
医療提供者が、検査、画像診断、その他の処置などの診断検査を依頼します。athenaClinicalsのCPOE(Computerized Provider Order Entry)機能で作成される、明示的なタイムスタンプ付きイベントです。
重要な理由

診断サブプロセスを開始する重要な判断点です。このアクティビティを追跡することで、依頼から結果取得までの「診断検査リードタイム」KPIを分析できます。

入手先

依頼テーブルで確認できます。各依頼には、患者識別子、依頼名、依頼ステータス、作成日時が記録されます。

取得

システムの依頼テーブルに新しいレコードがタイムスタンプ付きで作成されます。

イベントタイプ explicit
請求の提出
患者の受診中に提供したサービスの請求を作成し、支払者に提出します。athenaCollectorの収益サイクル管理モジュール内で明示的なイベントとして記録されます。
重要な理由

管理上の手順ではありますが、臨床プロセスと並行して進む収益サイクルを分析するうえで重要なアクティビティです。臨床ケアから請求までの遅延を特定できます。

入手先

請求または請求処理テーブルで確認できます。請求の作成日時または提出日時のタイムスタンプでイベントを特定します。

取得

請求レコードが作成され、ステータスがタイムスタンプ付きで「Submitted」に更新されます。

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

抽出ガイド

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

始める準備はできていますか?

患者ケアの最適化に向けた取り組みを始めましょう。このテンプレートは、価値ある情報を見つけ出し、医療成果を改善するための第一歩です。

患者ジャーニーを今すぐ最適化し、ボトルネックを解消

athenahealthの非効率な箇所を特定し、患者ジャーニーのサイクルタイムを30%短縮します。

無料トライアルを開始

クレジットカードは不要です。今日から最適化を始められます。