患者ジャーニーのデータテンプレート
患者ジャーニーのデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- 抽出手順
患者ジャーニーの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ClinicalEventTag
|
実行された臨床イベントまたは管理イベントの名称または説明です。 | ||
|
説明
この属性は、患者様のケア中に実行された具体的なアクションを記録します。たとえば、「投薬実施」、「バイタルサイン測定」、「患者様の退院」などです。プロセスの各ステップを人が読める名称で示します。 Cernerでは、CLINICAL_EVENTテーブルの
重要な理由
プロセスマップ上のステップを定義し、ワークフローを可視化できるようにします。
入手先
テーブル:CLINICAL_EVENT、列:EVENT_TAGまたはEVENT_CDに紐づくCODE_VALUE
例
トリアージ評価白血球分画付き全血球計算退院指示患者転送
|
|||
|
イベントのタイムスタンプ
EventEndDateTime
|
アクティビティが発生または完了した具体的な日時です。 | ||
|
説明
この属性には、イベントが発生した正確な時刻を記録します。アクティビティを時系列に並べ、プロセスの各ステップ間のサイクルタイムを計算するために使用します。
重要な理由
イベントの順序を特定し、リードタイムなどのパフォーマンスKPIを計算するために必要です。
入手先
テーブル:CLINICAL_EVENT、列:EVENT_END_DT_TM
例
2023-10-15T08:30:00Z2023-10-15T09:15:45Z2023-10-16T14:20:00Z
|
|||
|
患者様のエピソード
EncounterId
|
特定の患者様の受診またはケアのエピソードを一意に識別するIDです。 | ||
|
説明
この属性は、患者様の受療経路における中心的なケース識別子です。入院や救急受診など、1つのケア期間内に発生するすべての臨床イベント、オーダー、管理上の処理をまとめます。プロセスマイニングでは、分断されたアクティビティを1つのプロセスビューに関連付けるために、このIDが欠かせません。 技術的には、Cerner MillenniumデータベースのENCOUNTERテーブルにある
重要な理由
入院から退院までの患者様の受療経路をエンドツーエンドで再構成するために必要な基本キーです。
入手先
テーブル:ENCOUNTER、列:ENCNTR_ID
例
123456789876543211223344
|
|||
|
ソースシステム
SourceSystem
|
データの取得元となったシステムの名称です。 | ||
|
説明
データレコードの元となるアプリケーションを特定します。この場合、主に 複数のソースからデータを取り込む場合、データの出所に基づいてプロセス分析をフィルタリングまたは分類できます。
重要な理由
特に複数のシステムを対象とするプロセスマイニング環境で、データの系譜と追跡可能性を確保します。
入手先
ハードコードされた文字列またはシステムメタデータ
例
Oracle HealthCerner Millennium
|
|||
|
最終データ更新日時
LastDataUpdate
|
レコードがデータウェアハウスに抽出された時刻、または最後に変更された時刻です。 | ||
|
説明
分析に使用するデータの鮮度を示します。このタイムスタンプにより、リアルタイムデータを見ているのか、以前のロード時点のスナップショットを見ているのかを確認できます。 通常は臨床属性ではなく、ETL(Extract、Transform、Load)プロセス中に生成されます。
重要な理由
データガバナンスと、最新の情報に基づく分析を確保するために重要です。
入手先
ETLシステムのタイムスタンプ
例
2023-11-01T00:00:00Z2023-11-02T12:00:00Z
|
|||
|
オーダー項目
OrderMnemonic
|
発行された具体的なオーダーの名称です。検査や薬剤などが該当します。 | ||
|
説明
オーダーイベントの内容を示します(例:「全血球計算」「アスピリン81mg」)。「診断オーダー発行」や「薬剤投与」のアクティビティに必要な文脈を提供します。 通常は
重要な理由
診断および治療経路を詳細に分析するために必要です。
入手先
テーブル:ORDERS、列:ORDER_MNEMONIC
例
胸部X線基礎代謝パネルアセトアミノフェン脳MRI
|
|||
|
ケース種別
EncounterType
|
入院、外来、救急など、患者の受診種別です。 | ||
|
説明
患者エピソードの性質を分類します。データを切り分ける主要な軸であり、「救急」受診と「予定入院」ではプロセスフローが大きく異なります。
重要な理由
異なる医療提供環境における経路と処理量を比較分析できます。
入手先
テーブル:ENCOUNTER、列:ENCNTR_TYPE_CD(CODE_VALUEで解決)
例
入院患者救急外来患者日帰り手術
|
|||
|
ユーザー
PerformingPrsnlId
|
アクティビティを実施した医療従事者の識別子または氏名です。 | ||
|
説明
薬剤を投与した看護師や退院処理に署名した医師など、プロセスの各ステップを実行した担当者を記録します。これにより、リソースの利用状況を分析できます。 Cernerでは、テーブルに応じて
重要な理由
リソース分析に役立ち、トレーニングの必要性や業務負荷の偏りを特定できます。
入手先
テーブル:CLINICAL_EVENT、列:PERFORMED_PRSNL_ID
例
Smith医師Jones看護師システム管理者
|
|||
|
主傷病名
DiagnosisCode
|
治療を受ける主な理由を示すICD-10またはSNOMEDコードです。 | ||
|
説明
エピソードに割り当てられた標準化された臨床コードです(例:肺炎を示す「J18.9」)。疾患ごとに患者をグループ化し、特定の疾患に対する「治療プロトコル逸脱」を分析できます。 受診記録に紐づく
重要な理由
特定の疾患について、患者経路を同じ条件で比較できます。
入手先
テーブル:DIAGNOSIS、列:DIAGNOSIS_CODE(命名体系経由)
例
I10E11.9J18.9
|
|||
|
再入院かどうか
IsReadmission
|
前回の退院から30日以内に発生したエピソードかどうかを示すフラグです。 | ||
|
説明
再入院に該当するケースを特定するためのブール型フラグです。同じ 「患者再入院傾向」ダッシュボードに欠かせません。
重要な理由
医療の質を示す主要指標である「患者再入院率」KPIを直接支援します。
入手先
ENCOUNTERレコードを比較するSQLロジックから算出
例
truefalse
|
|||
|
患者ID
PersonId
|
複数の受診記録にまたがって患者を一意に識別するIDです。 | ||
|
説明
Case IDとは異なり、Patient ID(またはPerson ID)は、患者が病院を受診したすべての記録で変わりません。この属性は、再入院率の分析や患者の長期的な履歴の把握に欠かせません。 Cernerでは、
重要な理由
別々のエピソードを同じ個人に関連付け、「患者再入院率」KPIを算出できます。
入手先
テーブル:PERSON、列:PERSON_ID
例
P10001P55992P99221
|
|||
|
退院時の状態
DischargeDisposition
|
退院時の患者の行き先または状態です。 | ||
|
説明
エピソード終了後の患者の行き先を示します(例:「自宅」「熟練看護施設」「死亡」)。「退院計画」分析や望ましくない結果の特定に欠かせません。
重要な理由
主要な結果指標であり、患者の経過における「終了状態」を定義します。
入手先
テーブル:ENCOUNTER、列:DISCH_DISPOSITION_CD(CODE_VALUEで解決)
例
自宅へ退院リハビリテーション施設へ転院医師の指示に反して退院死亡
|
|||
|
部門
NurseUnit
|
イベントが発生した具体的な病棟、ユニット、または部門です。 | ||
|
説明
イベント発生時に患者を担当していた物理的な場所または組織単位を特定します(例:「ICU」「一般外科」「救急部」)。 ユニット間の移動を追跡し、「病棟間移送効率」ダッシュボードで役立ちます。Cernerでは、受診テーブルまたは追跡テーブルの
重要な理由
特定の部門におけるボトルネックの分析や、患者フローの分布の可視化に必要です。
入手先
テーブル:ENCOUNTERまたはCLINICAL_EVENT、列:LOC_NURSE_UNIT_CD
例
救急部循環器病棟ICU放射線科
|
|||
|
オーダー番号
OrderId
|
特定のオーダー(検査、薬剤、コンサルテーション)を一意に識別するIDです。 | ||
|
説明
オーダーに対してシステムが生成するIDです。Case IDではありませんが、重要な副次キーです。「診断オーダー発行」イベントと「診断結果検証済み」イベントを関連付けます。 このIDがない場合、患者に複数のオーダーが同時に存在すると、特定の検査の正確なターンアラウンドタイムを計算することが難しくなります。
重要な理由
対応するアクティビティ(Order → Result)を正確に関連付けるために必要です。
入手先
テーブル:ORDERS、列:ORDER_ID
例
88291028829103
|
|||
|
トリアージ優先度
TriageAcuity
|
トリアージ評価時に割り当てられた緊急度です。 | ||
|
説明
患者の状態の重症度を示す数値またはカテゴリ値です(例:1「即時対応」から5「緊急性なし」)。待ち時間を分析する際の重要な分類属性であり、優先度の高い患者ほど待ち時間が短いことが期待されます。 通常は、トリアージイベント中に臨床フォームまたは特定の観察コードとして記録されます。
重要な理由
臨床上の緊急度に応じて、プロセスが患者を適切に優先しているかを検証するために重要です。
入手先
Oracle Health(Cerner)のドキュメントを参照してください
例
12345
|
|||
|
入院経路
AdmissionSource
|
患者が入院に至った経路です。 | ||
|
説明
患者がどのように病院システムへ入ったかを示します。医師からの紹介、救急外来、他院からの転院などが該当します。 病院プロセスの「入口」を分析する際に役立ちます。
重要な理由
入口に応じて「初回評価待ち時間」を分析する際の背景情報を提供します。
入手先
テーブル:ENCOUNTER、列:ADMIT_SRC_CD
例
救急外来医師からの紹介病院からの転院
|
|||
|
支払者種別
FinancialClass
|
患者の主な保険適用または財務上の分類です。 | ||
|
説明
支払元に基づいて患者を分類します(例:「メディケア」「民間保険」「自己負担」)。保険種別によってプロセスフローや在院日数が異なるかを分析するために使用します。
重要な理由
支払者種別に基づく医療提供や事務処理の格差を特定するのに役立ちます。
入手先
テーブル:ENCOUNTER、列:FINANCIAL_CLASS_CD(CODE_VALUEで解決)
例
メディケアBlue Cross自己負担Medicaid
|
|||
|
結果の状態
ResultStatus
|
診断結果の状態です(例:「承認(検証済み)」「修正済み」「暫定」)。 | ||
|
説明
診断検査結果のライフサイクル上の段階を示します。「診断結果提供時間」分析で、臨床上の意思決定に正式に利用可能になった時点を特定するために使用します。 通常は、特定のステータスコードとともに
重要な理由
暫定結果と最終結果を区別します。これにより、後続のアクティビティを開始できる時点が変わります。
入手先
テーブル:CLINICAL_EVENT、列:RESULT_STATUS_CD
例
承認(確認済み)エラー変更済み
|
|||
|
薬剤の状態
MedAdminStatus
|
薬剤オーダーの状態です(例:「投与済み」「拒否」「未投与」)。 | ||
|
説明
薬剤投与タスクの結果を示します。「薬剤投与コンプライアンス」ダッシュボードでは、実際に投与された薬剤と、予定されていたものの未投与または拒否された薬剤を区別することが重要です。 通常は
重要な理由
治療プロトコルにおけるコンプライアンス上の不足を特定します。
入手先
Oracle Health(Cerner)のドキュメントを参照してください
例
投与済み拒否保留
|
|||
患者ジャーニーのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
トリアージ評価完了
|
救急または入院の場面で、初回の看護評価またはトリアージフォームの記入が完了したことを示します。通常、システム内に記録された特定のフォームまたは臨床イベントが該当します。 | ||
|
重要な理由
「初回評価待ち時間」KPIの計算と、受付時点のボトルネック特定に欠かせません。
入手先
CLINICAL_EVENTテーブル。トリアージまたは初回評価フォームに関連するイベントコードで絞り込みます。
取得
臨床文書またはフォームに署名・確認が行われた時点で記録
イベントタイプ
explicit
|
|||
|
患者様の登録完了
|
患者様が到着し、システムに登録された時点で、患者様のエピソードが始まったことを示します。Cerner Millenniumでは、受診記録が作成された時点、または登録タイムスタンプが設定された時点で記録されます。 | ||
|
重要な理由
在院日数(LOS)の計算と初期待ち時間の分析における開始時刻を設定します。
入手先
ENCOUNTERテーブルのREG_DT_TM(登録日時)列です。
取得
トランザクションによって新しいENCOUNTER行が作成された時点で記録
イベントタイプ
explicit
|
|||
|
患者様の退院
|
患者様の入院を終了する最後の管理イベントです。このタイムスタンプを使って在院日数全体を計算します。 | ||
|
重要な理由
プロセスの主要な終了イベントです。在院日数と再入院の計算に欠かせません。
入手先
ENCOUNTERテーブルのDISCH_DT_TM(退院日時)列です。
取得
受診記録のステータスがDISCHARGEDに変更された時点で記録
イベントタイプ
explicit
|
|||
|
診断オーダー入力
|
臨床医が検査または画像診断のオーダーを入力した時点で発生します。このタイムスタンプが診断の所要時間の計算を開始します。 | ||
|
重要な理由
「診断結果提供時間」KPIの開始点です。オーダーから実施までの遅延を特定するのに役立ちます。
入手先
ORDERSテーブル。カタログ種別がLaboratoryまたはRadiologyである場合のORIG_ORDER_DT_TMを使用します。
取得
オーダーのステータスがORDEREDに設定された時点で記録
イベントタイプ
explicit
|
|||
|
診断の記録
|
患者様の受診記録に正式な診断が追加された時点で発生します。検査結果とは異なり、臨床医が疾患や状態を確認したことを示します。 | ||
|
重要な理由
「診断確定」マイルストーンと、確定診断までの時間の分析に欠かせません。
入手先
DIAGNOSISテーブル。ENCOUNTER_IDにリンクされたDIAGNOSIS_DT_TMを使用します。
取得
PowerChartで診断が追加または更新された時点で記録
イベントタイプ
explicit
|
|||
|
診断結果の確認完了
|
検査または画像診断の結果が確定し、臨床医が利用できるようになった時点です。診断の所要時間の計測区間が終了します。 | ||
|
重要な理由
「診断結果提供時間」のサイクルを完了し、その後の治療判断を開始します。
入手先
CLINICAL_EVENTテーブル(検査の場合)またはORDERSのステータスがCOMPLETEDに変更された時点です。
取得
結果のステータスがAUTH(Authenticated)に変更された時点で記録
イベントタイプ
explicit
|
|||
|
退院オーダー署名
|
医師が患者様の退院オーダーを入力したイベントです。退院計画の計測を開始します。 | ||
|
重要な理由
「退院計画サイクル時間」の開始点です。この時点から実際の退院までに差がある場合、業務上の遅延を示します。
入手先
ORDERSテーブル。カタログ種別がDischargeであるレコードを使用します。
取得
退院オーダーのステータスがORDEREDになった時点で記録
イベントタイプ
explicit
|
|||
|
部門間の移送発生
|
患者様がある場所(例:ER)から別の場所(例:ICU)へ実際に移動したことを示します。ロケーション履歴を通じて追跡されます。 | ||
|
重要な理由
「病棟間移送効率」の分析を可能にし、病院内の患者様の流れを可視化するのに役立ちます。
入手先
ENCNTR_LOC_HIST(受診記録ロケーション履歴)テーブル。LOC_NURSE_UNIT_CDの変更を記録します。
取得
前後のステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
ケアプランの有効化
|
CernerでPowerPlanまたは医療経路が開始されたことを示します。標準化された治療プロトコルが選択されたことを意味します。 | ||
|
重要な理由
実際の医療と計画された経路を比較する「治療プロトコル逸脱分析」に欠かせません。
入手先
ACT_PW_CAT(Action Pathway Catalog)またはDCP_FORMS_REF。経路を受診記録にリンクします。
取得
PowerPlanが開始された時点で記録
イベントタイプ
explicit
|
|||
|
コンサルテーション完了
|
専門医によるコンサルテーションが完了したことを示します。通常、署名済みのコンサルテーション記録または文書で確認できます。 | ||
|
重要な理由
専門医の意見を受け取った時点を特定します。複雑な医療経路では、ここがボトルネックになる場合があります。
入手先
CLINICAL_EVENTテーブル。コンサルテーションに分類された文書種別で絞り込みます。
取得
コンサルテーション記録に署名された時点で記録
イベントタイプ
explicit
|
|||
|
フォローアップ予約の設定
|
同じエピソードまたはケアプランに関連付けられた将来の予約が、患者様に対して設定された時点で発生します。 | ||
|
重要な理由
「フォローアップ予約の適時性」ダッシュボードを支援します。ケアの継続性に関する業務効率を測定します。
入手先
SCH_APPT(予約スケジュール)テーブル。PERSON_IDにリンクします。
取得
予約スケジュールモジュールで予約が作成された時点で記録
イベントタイプ
explicit
|
|||
|
処置の予約完了
|
手術または主要な処置が特定の時間に予約されたことを示します。リソース配分や処置前の待ち時間を把握するのに役立ちます。 | ||
|
重要な理由
手術室や処置室の利用における予約効率と潜在的なボトルネックを明らかにします。
入手先
受診記録にリンクされたSURGICAL_CASEテーブルまたはSCH_APPTテーブルです。
取得
予約トランザクションが確定した時点で記録
イベントタイプ
explicit
|
|||
|
処置の実施
|
手術または主要な処置が実際に行われた時点を示すタイムスタンプです。通常、周術期の文書に記録されます。 | ||
|
重要な理由
臨床経路とリソース利用の分析における重要なマイルストーンです。
入手先
SURGICAL_CASEテーブル(Case Start/Stop時刻)またはベッドサイド処置のCLINICAL_EVENTです。
取得
SurgiNetまたは処置文書を通じて記録
イベントタイプ
explicit
|
|||
|
投薬実施
|
Medication Administration Record(MAR)に記録された、患者様への実際の投薬を記録します。 | ||
|
重要な理由
投薬が予定どおり実施されたかを確認し、「投薬実施コンプライアンス」ダッシュボードを支援します。
入手先
CLINICAL_EVENTテーブル。投薬実施イベント(Task Status = Complete)で絞り込みます。
取得
バーコードのスキャンまたはMARへの手入力時に記録
イベントタイプ
explicit
|
|||
抽出ガイド
準備はできましたか?
このテンプレートを使ってデータを準備し、患者ジャーニーのプロセスに潜む価値ある情報を見つけ出してください。患者の成果を最適化する取り組みは、ここから始まります。
患者ジャーニーを今すぐ最適化し、成果を早期に改善
ボトルネックを迅速に特定し、患者ジャーニーのサイクルタイムを30%短縮します。
クレジットカードは不要です。数分で始められます。