患者ジャーニーデータテンプレート
患者ジャーニーデータテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
患者ジャーニー属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ClinicalEventTag
|
実施された臨床的または管理的なイベントの名前または説明。 | ||
|
説明
この属性は、「薬剤投与済み」、「バイタルサイン測定済み」、「患者退院済み」など、患者ケア中に取られた具体的な行動を捉えます。これはプロセスステップの人間が読めるラベルを提供します。 Cernerでは、これはしばしば
その重要性
プロセスマップのステップを定義し、ワークフローの可視化を可能にします。
取得元
テーブル: CLINICAL_EVENT, カラム: EVENT_TAG または EVENT_CD のリンクされたCODE_VALUE
例
トリアージアセスメント白血球5分類退院指示患者転送
|
|||
|
イベントのタイムスタンプ
EventEndDateTime
|
活動が発生または完了した具体的な日時。 | ||
|
説明
この属性は、イベントが発生した正確な瞬間を記録します。活動を順序付け、プロセスステップ間のサイクルタイムを計算するために使用されます。
その重要性
イベントの順序を決定し、リードタイムのようなパフォーマンスKPIを計算するために不可欠です。
取得元
テーブル: CLINICAL_EVENT, カラム: EVENT_END_DT_TM
例
2023-10-15T08:30:00Z2023-10-15T09:15:45Z2023-10-16T14:20:00Z
|
|||
|
患者エピソード
EncounterId
|
特定の患者受診またはケアのエピソードの一意の識別子。 | ||
|
説明
この属性は、患者ジャーニーの中心的なケース識別子として機能します。これは、単一のケア期間(例:入院または緊急受診)内で発生するすべての臨床イベント、オーダー、および管理アクションをグループ化します。プロセスマイニングでは、このIDは、ばらばらの活動を統一されたプロセスビューに相関させるために不可欠です。 技術的には、これはCerner Millenniumデータベース内の
その重要性
これは、入院から退院までのエンドツーエンドの患者ジャーニーを再構築するために不可欠な基本キーです。
取得元
テーブル: ENCOUNTER, カラム: ENCNTR_ID
例
123456789876543211223344
|
|||
|
ソースシステム
SourceSystem
|
`データ`の`発信元``システム`名です。 | ||
|
説明
データレコードのソースアプリケーションを識別します。この文脈では、主に「Oracle Health」または「Cerner Millennium」となります。これは、他のEMRや部門システムとデータが混在するマルチシステム環境で役立ちます。 複数のソースが取り込まれている場合、アナリストはデータ元の出所に基づいてプロセス分析をフィルタリングまたはセグメント化できます。
その重要性
特に複数システムでのプロセスマイニング設定において、データリネージとトレーサビリティを保証します。
取得元
ハードコードされた文字列またはシステムメタデータ
例
Oracle HealthCerner Millennium
|
|||
|
最終データ更新
LastDataUpdate
|
レコードがウェアハウスから抽出された、または最後に変更された際のタイムスタンプ。 | ||
|
説明
分析で使用されるデータの鮮度を示します。このタイムスタンプは、ユーザーがリアルタイムデータを見ているのか、以前のロードからのスナップショットを見ているのかを理解するのに役立ちます。 これは通常、臨床属性ではなく、ETL(抽出、変換、ロード)プロセス中に生成されます。
その重要性
データガバナンスと、最新情報に基づいて分析が実行されることを保証するために不可欠です。
取得元
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
例
スミス医師RNジョーンズSysAdmin
|
|||
|
主な診断
DiagnosisCode
|
ケアの主な理由を表すICD-10またはSNOMEDコード。 | ||
|
説明
エピソードに割り当てられた標準化された臨床コード(例:肺炎の「J18.9」)。これにより、特定の疾患における「治療プロトコル逸脱」を分析するために、病状別に患者をグループ化できます。
その重要性
特定の病状における患者経路の公平な比較を可能にします。
取得元
テーブル: DIAGNOSIS, カラム: DIAGNOSIS_CODE (命名法経由)
例
I10E11.9J18.9
|
|||
|
再入院か
IsReadmission
|
このエピソードが以前の退院から30日以内に発生したかどうかを示すフラグ。 | ||
|
説明
再入院を示すケースを識別するために使用されるブール型のフラグです。これは、現在のエピソードの入院日と、同じ 「患者再入院トレンド」ダッシュボードに不可欠です。
その重要性
主要なケア品質指標である「患者再入院率」KPIを直接サポートします。
取得元
ENCOUNTERレコードを比較するSQLロジックを介して派生
例
truefalse
|
|||
|
在院日数
LengthOfStay
|
患者エピソードの総期間(日数または時間)。 | ||
|
説明
これは、入院タイムスタンプと退院タイムスタンプの間の時間差を表す計算された属性です。「全体的な患者在院日数分析」ダッシュボードの主要な効率性指標です。 プロセスマイニングツール内で計算することも可能ですが、ケースレベルで事前に計算された静的属性としてインポートする方が、パフォーマンス上効率的であることがよくあります。
その重要性
病院経営にとって最も重要な効率性KPIです。
取得元
ENCOUNTER.REG_DT_TMおよびDISCH_DT_TMから派生
例
4.5日2 hours12日間
|
|||
|
患者ID
PersonId
|
複数のエンカウンターにおける患者の一意の識別子。 | ||
|
説明
ケースIDとは異なり、患者ID(または人物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放射線科
|
|||
|
トリアージ優先度
TriageAcuity
|
トリアージアセスメント中に割り当てられた緊急度レベル。 | ||
|
説明
患者の状態の重症度を示す数値またはカテゴリ値(例:1-緊急から5-非緊急)。これは、優先度の高い患者は待ち時間が短いべきであるため、待ち時間を分析するための重要なセグメンテーション属性です。 通常、トリアージイベント中の臨床フォームまたは特定の観察コードで取得されます。
その重要性
臨床的な緊急度に応じてプロセスが患者を正しく優先しているかを検証するために不可欠です。
取得元
Oracle Health (Cerner)のドキュメントを参照する
例
12345
|
|||
|
入院経路
AdmissionSource
|
患者入院の起点。 | ||
|
説明
「医師からの紹介」、「救急室」、「他の病院からの転送」など、患者がどのように病院システムに入ったかを示します。 これにより、病院プロセスの「玄関口」を分析できます。これは
その重要性
エントリポイントに基づいて「初期評価待ち時間」を文脈化します。
取得元
テーブル: ENCOUNTER, カラム: ADMIT_SRC_CD
例
救急室医師紹介病院からの転送
|
|||
|
支払者タイプ
FinancialClass
|
患者の主な保険適用または財務分類。 | ||
|
説明
患者を支払い元(例:メディケア、民間保険、自己負担)に基づいて分類します。この属性は、保険タイプによってプロセスフローや入院期間が異なるかどうかを分析するために使用されます。
その重要性
支払いタイプに基づくケア提供または管理処理における不均衡を特定するのに役立ちます。
取得元
テーブル: ENCOUNTER, カラム: FINANCIAL_CLASS_CD (CODE_VALUE経由で解決)
例
メディケアブルークロス自費メディケイド
|
|||
|
注文番号
OrderId
|
特定のオーダー(検査、薬剤、診察)の一意の識別子。 | ||
|
説明
オーダーのシステム生成ID。これはケースIDではありませんが、重要なセカンダリキーです。「診断オーダー発行」イベントを「診断結果検証済み」イベントにリンクします。 これがなければ、患者が複数の同時オーダーを持っている場合、特定のテストの正確なターンアラウンドタイムを計算することは困難です。
その重要性
ペアになったアクティビティ(オーダー -> 結果)を正確にリンクするために不可欠です。
取得元
テーブル: ORDERS, カラム: ORDER_ID
例
88291028829103
|
|||
|
結果ステータス
ResultStatus
|
診断結果のステータス(例:認証済み(検証済み)、修正済み、暫定)。 | ||
|
説明
診断テスト結果のライフサイクル段階を示します。これは「診断結果提供時間」分析で、結果が臨床意思決定のために公式に利用可能になる時期を判断するために使用されます。 通常、特定のステータスコードを持つ
その重要性
暫定結果と最終結果を区別し、下流のアクティビティがいつ開始できるかに影響を与えます。
取得元
テーブル: CLINICAL_EVENT, カラム: RESULT_STATUS_CD
例
認証(確認済み)エラー発生変更済み
|
|||
|
薬剤ステータス
MedAdminStatus
|
薬剤オーダーのステータス(例:投与済み、拒否済み、未投与)。 | ||
|
説明
薬剤投与タスクの結果を示します。「薬剤投与コンプライアンス」ダッシュボードでは、実際に投与された薬剤と、予定されていたが服用されなかったまたは拒否された薬剤を区別することが重要です。
その重要性
治療プロトコルにおけるコンプライアンスギャップを特定します。
取得元
Oracle Health (Cerner)のドキュメントを参照する
例
投与済み拒否済み保留中
|
|||
患者ジャーニー活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
トリアージアセスメント完了
|
救急または入院のコンテキストにおける初期看護アセスメントまたはトリアージフォームの完了を表します。これは通常、システム内に文書化された特定のフォームまたは臨床イベントです。 | ||
|
その重要性
「初期評価待ち時間」KPIの計算と、入り口でのボトルネック特定に不可欠です。
取得元
トリアージまたは初期評価フォームに関連付けられたイベントコードでフィルタリングされた
取得
臨床文書/フォームが署名/確認された際に記録される
イベントタイプ
explicit
|
|||
|
患者登録済み
|
患者が来院し、システムに登録された際に患者エピソードの開始を示します。Cerner Millenniumでは、エンカウンターレコードが作成された際、または登録のタイムスタンプが設定された際に記録されます。 | ||
|
その重要性
入院期間(LOS)計算と初期待ち時間分析の開始時間を確立します。
取得元
取得
トランザクションが新しいENCOUNTER行を作成した際に記録される
イベントタイプ
explicit
|
|||
|
患者退院済み
|
患者の滞在を終了する最終的な管理イベント。このタイムスタンプは、総在院日数を計算するために使用されます。 | ||
|
その重要性
プロセスの主要な終了イベント。LOS(在院日数)と再入院の計算に不可欠です。
取得元
取得
エンカウンターのステータスが「DISCHARGED」に変更された際に記録される
イベントタイプ
explicit
|
|||
|
診断オーダー発行
|
臨床医が検査または画像診断のオーダーを入力した際に発生します。このタイムスタンプが診断のターンアラウンドタイム計算を開始します。 | ||
|
その重要性
「診断結果提供時間」KPIの開始点。オーダーと実行における遅延を特定するのに役立ちます。
取得元
ORDERSテーブル、カタログタイプがLaboratoryまたはRadiologyの場合にORIG_ORDER_DT_TMを使用。
取得
オーダーのステータスが「ORDERED」に設定された際に記録される
イベントタイプ
explicit
|
|||
|
診断結果検証
|
検査または画像診断の結果が確定し、臨床医に利用可能になった瞬間。これにより、診断のターンアラウンドタイム期間が終了します。 | ||
|
その重要性
「診断結果提供時間」サイクルを完了し、その後の治療決定をトリガーします。
取得元
取得
結果ステータスが「AUTH(認証済み)」に変更された際に記録される
イベントタイプ
explicit
|
|||
|
診断記録
|
患者のエンカウンター記録に正式な診断が追加された際に発生します。これは検査結果とは異なり、臨床医による病状の確認を表します。 | ||
|
その重要性
「診断確定」のマイルストーンおよび確定診断までの時間分析に不可欠です。
取得元
取得
PowerChartで診断が追加/更新された際に記録される
イベントタイプ
explicit
|
|||
|
退院指示署名済み
|
医師が患者を退院させるオーダーを発行するイベント。これにより、退院計画のカウントが開始されます。 | ||
|
その重要性
「退院計画サイクルタイム」の開始点。これと実際の退院との間にギャップがある場合、運用上の遅延を示します。
取得元
ORDERSテーブル、カタログタイプがDischargeを示す場合。
取得
退院オーダーのステータスが「ORDERED」になった際に記録される
イベントタイプ
explicit
|
|||
|
部門転送発生
|
患者が物理的にある場所(例:ER)から別の場所(例:ICU)へ移動したことを示します。これはロケーション履歴で追跡されます。 | ||
|
その重要性
「病棟間転送効率」分析を可能にし、病院内の患者の流れを視覚化するのに役立ちます。
取得元
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
ケアプラン有効化
|
CernerにおけるPowerPlanまたはケアパスウェイの開始を表します。これは、標準化された治療プロトコルが選択されたことを示します。 | ||
|
その重要性
実際のケアと計画された経路を比較する「治療プロトコル逸脱分析」に不可欠です。
取得元
ACT_PW_CAT (アクション経路カタログ) または DCP_FORMS_REF。経路とエンカウンターをリンクします。
取得
PowerPlanが開始された際に記録される
イベントタイプ
explicit
|
|||
|
コンサルテーション完了
|
専門医の診察が完了したことを示します。通常、署名されたコンサルテーションノートまたは文書によって証明されます。 | ||
|
その重要性
専門家の意見がいつ受け取られたかを特定し、これは複雑なケア経路におけるボトルネックとなる可能性があります。
取得元
コンサルテーションとして分類されたドキュメントタイプでフィルタリングされた
取得
コンサルトノートが署名された際に記録される
イベントタイプ
explicit
|
|||
|
フォローアップ予約済み
|
同一のエピソードまたはケアプランに紐付けられた患者の将来の予約が記録された際に発生します。 | ||
|
その重要性
「フォローアップ予約の適時性」ダッシュボードをサポートします。ケアの継続性の効率性を測定します。
取得元
SCH_APPT (スケジュール予約) テーブル、PERSON_IDにリンクされています。
取得
スケジュールモジュールで予約が作成された際に記録される
イベントタイプ
explicit
|
|||
|
処置スケジュール済み
|
外科的症例または主要な処置が特定の時間に予約されていることを示します。これにより、リソース配分と処置前の待ち時間を理解するのに役立ちます。 | ||
|
その重要性
手術室や処置室の利用におけるスケジューリング効率と潜在的なボトルネックを強調します。
取得元
SURGICAL_CASEテーブルまたはエンカウンターにリンクされたSCH_APPTテーブル。
取得
スケジュールトランザクションがコミットされた際に記録される
イベントタイプ
explicit
|
|||
|
処置実施済み
|
手術または主要な処置が実際にいつ行われたかを示すタイムスタンプ。これは多くの場合、周術期文書に記録されます。 | ||
|
その重要性
臨床パスとリソース利用率分析における重要なマイルストーンです。
取得元
SURGICAL_CASEテーブル(症例開始/終了時間)またはベッドサイド処置のCLINICAL_EVENT。
取得
SurgiNetまたは処置文書を介して記録される
イベントタイプ
explicit
|
|||
|
薬剤投与済み
|
薬剤投与記録 (MAR) に記載された、患者への実際の薬剤投与を記録します。 | ||
|
その重要性
薬剤が時間通りに投与されたかを確認することで、「薬剤投与コンプライアンス」ダッシュボードをサポートします。
取得元
薬剤投与イベント(タスクステータス = 完了)でフィルタリングされた
取得
バーコードスキャンまたは手動MAR入力時に記録される
イベントタイプ
explicit
|
|||