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

Oracle Health (Cerner)
患者ジャーニーデータテンプレート

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

この包括的なテンプレートは、患者ジャーニーを効果的に分析および最適化するために必要な重要なデータを概説しています。収集すべき重要な属性、追跡すべき主要な活動、およびデータ抽出に関する実践的なガイダンスの構造化された概要を提供します。このリソースを使用して、シームレスなプロセスマイニング体験のためにイベントログを準備してください。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • 抽出の手引き
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

患者ジャーニー属性

これらは、システム内の患者ジャーニーを包括的に分析するために、イベントログに含めることを推奨されるデータフィールドです。
5 必須 9 推奨 6 任意
名前 説明
アクティビティ
ClinicalEventTag
実施された臨床的または管理的なイベントの名前または説明。
説明

この属性は、「薬剤投与済み」、「バイタルサイン測定済み」、「患者退院済み」など、患者ケア中に取られた具体的な行動を捉えます。これはプロセスステップの人間が読めるラベルを提供します。

Cernerでは、これはしばしば CLINICAL_EVENT テーブルから派生し、特に EVENT_CD (イベントコード) をその表示値にマッピングするか、EVENT_TAG を使用します。ここでは、読みやすいプロセスマップのために一貫した命名規則が重要です。

その重要性

プロセスマップのステップを定義し、ワークフローの可視化を可能にします。

取得元

テーブル: CLINICAL_EVENT, カラム: EVENT_TAG または EVENT_CD のリンクされたCODE_VALUE

トリアージアセスメント白血球5分類退院指示患者転送
イベントのタイムスタンプ
EventEndDateTime
活動が発生または完了した具体的な日時。
説明

この属性は、イベントが発生した正確な瞬間を記録します。活動を順序付け、プロセスステップ間のサイクルタイムを計算するために使用されます。

CLINICAL_EVENT テーブルでは、これは通常 EVENT_END_DT_TM に対応します。ここでの正確さは、「患者登録済み」から「トリアージアセスメント」までの期間など、待ち時間を計算するために不可欠です。

その重要性

イベントの順序を決定し、リードタイムのようなパフォーマンス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 に対応します。これは、患者のデモグラフィック、オーダー、および臨床イベントをリンクするために使用される主キーです。

その重要性

これは、入院から退院までのエンドツーエンドの患者ジャーニーを再構築するために不可欠な基本キーです。

取得元

テーブル: 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に見られます。これはプロセスを流れる「製品」として機能します。

その重要性

診断および治療パスのきめ細かな分析に必要です。

取得元

テーブル: ORDERS, カラム: ORDER_MNEMONIC

胸部X線基礎代謝パネルアセトアミノフェン脳MRI
ケース種別
EncounterType
患者の受診の分類(例:入院、外来、緊急)。
説明

患者エピソードの性質を分類します。これはデータをスライスするための主要なディメンションであり、「緊急」受診のプロセスフローは「選択入院」受診とは大きく異なるためです。

これは、ENCOUNTERテーブルのENCNTR_TYPE_CDから派生し、コードセット値(例:「入院」、「緊急」)を参照します。

その重要性

異なるケア設定間での経路とスループットの比較分析を可能にします。

取得元

テーブル: ENCOUNTER, カラム: ENCNTR_TYPE_CD (CODE_VALUE経由で解決)

入院患者緊急外来患者日帰り手術
ユーザー
PerformingPrsnlId
その活動を実行した臨床医の識別子または名前。
説明

薬剤を投与する看護師や退院に署名する医師など、プロセスステップを実行した人物を記録します。これにより、リソース利用分析が可能になります。

Cernerでは、テーブル(オーダーと臨床イベント)に応じて、これはしばしばPERFORMED_PRSNL_IDまたはUPDT_IDです。これを汎用的な「ユーザー」属性にマッピングすることで、職務分掌分析が容易になります。

その重要性

リソース分析をサポートし、潜在的なトレーニングニーズや作業負荷の不均衡を特定します。

取得元

テーブル: CLINICAL_EVENT, カラム: PERFORMED_PRSNL_ID

スミス医師RNジョーンズSysAdmin
主な診断
DiagnosisCode
ケアの主な理由を表すICD-10またはSNOMEDコード。
説明

エピソードに割り当てられた標準化された臨床コード(例:肺炎の「J18.9」)。これにより、特定の疾患における「治療プロトコル逸脱」を分析するために、病状別に患者をグループ化できます。

DIAGNOSIS テーブルにあり、エンカウンターにリンクされています。

その重要性

特定の病状における患者経路の公平な比較を可能にします。

取得元

テーブル: DIAGNOSIS, カラム: DIAGNOSIS_CODE (命名法経由)

I10E11.9J18.9
再入院か
IsReadmission
このエピソードが以前の退院から30日以内に発生したかどうかを示すフラグ。
説明

再入院を示すケースを識別するために使用されるブール型のフラグです。これは、現在のエピソードの入院日と、同じPersonIdの以前のエピソードの退院日を比較して計算されます。

「患者再入院トレンド」ダッシュボードに不可欠です。

その重要性

主要なケア品質指標である「患者再入院率」KPIを直接サポートします。

取得元

ENCOUNTERレコードを比較するSQLロジックを介して派生

truefalse
在院日数
LengthOfStay
患者エピソードの総期間(日数または時間)。
説明

これは、入院タイムスタンプと退院タイムスタンプの間の時間差を表す計算された属性です。「全体的な患者在院日数分析」ダッシュボードの主要な効率性指標です。

プロセスマイニングツール内で計算することも可能ですが、ケースレベルで事前に計算された静的属性としてインポートする方が、パフォーマンス上効率的であることがよくあります。

その重要性

病院経営にとって最も重要な効率性KPIです。

取得元

ENCOUNTER.REG_DT_TMおよびDISCH_DT_TMから派生

4.5日2 hours12日間
患者ID
PersonId
複数のエンカウンターにおける患者の一意の識別子。
説明

ケースIDとは異なり、患者ID(または人物ID)は、患者のすべての病院受診を通じて一定です。この属性は、再入院率の分析や患者の長期的な履歴を理解するために重要です。

Cernerでは、これはPERSONテーブルのPERSON_IDです。複数のENCNTR_IDレコードをリンクします。

その重要性

個別のエピソードを同じ個人にリンクすることで、「患者再入院率」KPIを可能にします。

取得元

テーブル: PERSON, カラム: PERSON_ID

P10001P55992P99221
退院ステータス
DischargeDisposition
退院時の患者の行き先またはステータス。
説明

エピソード終了後、患者がどこへ行ったか(例:「自宅へ帰宅」、「専門看護施設」、「死亡」など)を示します。これは「退院計画」分析や成功しなかった結果の特定に不可欠です。

ENCOUNTER テーブルの DISCH_DISPOSITION_CD に見られます。

その重要性

主要な成果指標であり、患者ジャーニーの「最終状態」を定義します。

取得元

テーブル: ENCOUNTER, カラム: DISCH_DISPOSITION_CD (CODE_VALUE経由で解決)

自宅へ退院リハビリテーションへ転送医師の助言に反して退院失効
部署
NurseUnit
イベントが発生した特定の病棟、ユニット、または部門。
説明

イベント発生時に患者を担当する物理的な場所または組織単位(例:「ICU」、「一般外科」、「救急部門」)を特定します。

これにより、ユニット間の移動を追跡することで、「病棟間転送効率」ダッシュボードに役立ちます。Cernerでは、これはしばしばエンカウンターまたは追跡テーブルのLOC_NURSE_UNIT_CDです。

その重要性

特定の部門におけるボトルネック分析と、患者フローの地理的可視化に不可欠です。

取得元

テーブル: ENCOUNTER または CLINICAL_EVENT, カラム: LOC_NURSE_UNIT_CD

救急部門心臓病棟ICU放射線科
トリアージ優先度
TriageAcuity
トリアージアセスメント中に割り当てられた緊急度レベル。
説明

患者の状態の重症度を示す数値またはカテゴリ値(例:1-緊急から5-非緊急)。これは、優先度の高い患者は待ち時間が短いべきであるため、待ち時間を分析するための重要なセグメンテーション属性です。

通常、トリアージイベント中の臨床フォームまたは特定の観察コードで取得されます。

その重要性

臨床的な緊急度に応じてプロセスが患者を正しく優先しているかを検証するために不可欠です。

取得元

Oracle Health (Cerner)のドキュメントを参照する

12345
入院経路
AdmissionSource
患者入院の起点。
説明

「医師からの紹介」、「救急室」、「他の病院からの転送」など、患者がどのように病院システムに入ったかを示します。

これにより、病院プロセスの「玄関口」を分析できます。これはENCOUNTERテーブルのADMIT_SRC_CDにマッピングされます。

その重要性

エントリポイントに基づいて「初期評価待ち時間」を文脈化します。

取得元

テーブル: ENCOUNTER, カラム: ADMIT_SRC_CD

救急室医師紹介病院からの転送
支払者タイプ
FinancialClass
患者の主な保険適用または財務分類。
説明

患者を支払い元(例:メディケア、民間保険、自己負担)に基づいて分類します。この属性は、保険タイプによってプロセスフローや入院期間が異なるかどうかを分析するために使用されます。

ENCOUNTERテーブルのFINANCIAL_CLASS_CDから派生します。

その重要性

支払いタイプに基づくケア提供または管理処理における不均衡を特定するのに役立ちます。

取得元

テーブル: ENCOUNTER, カラム: FINANCIAL_CLASS_CD (CODE_VALUE経由で解決)

メディケアブルークロス自費メディケイド
注文番号
OrderId
特定のオーダー(検査、薬剤、診察)の一意の識別子。
説明

オーダーのシステム生成ID。これはケースIDではありませんが、重要なセカンダリキーです。「診断オーダー発行」イベントを「診断結果検証済み」イベントにリンクします。

これがなければ、患者が複数の同時オーダーを持っている場合、特定のテストの正確なターンアラウンドタイムを計算することは困難です。

その重要性

ペアになったアクティビティ(オーダー -> 結果)を正確にリンクするために不可欠です。

取得元

テーブル: ORDERS, カラム: ORDER_ID

88291028829103
結果ステータス
ResultStatus
診断結果のステータス(例:認証済み(検証済み)、修正済み、暫定)。
説明

診断テスト結果のライフサイクル段階を示します。これは「診断結果提供時間」分析で、結果が臨床意思決定のために公式に利用可能になる時期を判断するために使用されます。

通常、特定のステータスコードを持つCLINICAL_EVENTで見られます。

その重要性

暫定結果と最終結果を区別し、下流のアクティビティがいつ開始できるかに影響を与えます。

取得元

テーブル: CLINICAL_EVENT, カラム: RESULT_STATUS_CD

認証(確認済み)エラー発生変更済み
薬剤ステータス
MedAdminStatus
薬剤オーダーのステータス(例:投与済み、拒否済み、未投与)。
説明

薬剤投与タスクの結果を示します。「薬剤投与コンプライアンス」ダッシュボードでは、実際に投与された薬剤と、予定されていたが服用されなかったまたは拒否された薬剤を区別することが重要です。

CLINICAL_EVENTまたは特定の薬剤投与記録(MAR)テーブルで見られる可能性が高いです。

その重要性

治療プロトコルにおけるコンプライアンスギャップを特定します。

取得元

Oracle Health (Cerner)のドキュメントを参照する

投与済み拒否済み保留中
必須 推奨 任意

患者ジャーニー活動

正確なプロセス発見とボトルネック特定のため、イベントログに記録すべき主要ステップとマイルストーンは次のとおりです。
8 推奨 6 任意
アクティビティ 説明
トリアージアセスメント完了
救急または入院のコンテキストにおける初期看護アセスメントまたはトリアージフォームの完了を表します。これは通常、システム内に文書化された特定のフォームまたは臨床イベントです。
その重要性

「初期評価待ち時間」KPIの計算と、入り口でのボトルネック特定に不可欠です。

取得元

トリアージまたは初期評価フォームに関連付けられたイベントコードでフィルタリングされたCLINICAL_EVENTテーブル。

取得

臨床文書/フォームが署名/確認された際に記録される

イベントタイプ explicit
患者登録済み
患者が来院し、システムに登録された際に患者エピソードの開始を示します。Cerner Millenniumでは、エンカウンターレコードが作成された際、または登録のタイムスタンプが設定された際に記録されます。
その重要性

入院期間(LOS)計算と初期待ち時間分析の開始時間を確立します。

取得元

ENCOUNTERテーブル、特にREG_DT_TM(登録日時)カラム。

取得

トランザクションが新しいENCOUNTER行を作成した際に記録される

イベントタイプ explicit
患者退院済み
患者の滞在を終了する最終的な管理イベント。このタイムスタンプは、総在院日数を計算するために使用されます。
その重要性

プロセスの主要な終了イベント。LOS(在院日数)と再入院の計算に不可欠です。

取得元

ENCOUNTERテーブル、特にDISCH_DT_TM(退院日時)。

取得

エンカウンターのステータスが「DISCHARGED」に変更された際に記録される

イベントタイプ explicit
診断オーダー発行
臨床医が検査または画像診断のオーダーを入力した際に発生します。このタイムスタンプが診断のターンアラウンドタイム計算を開始します。
その重要性

「診断結果提供時間」KPIの開始点。オーダーと実行における遅延を特定するのに役立ちます。

取得元

ORDERSテーブル、カタログタイプがLaboratoryまたはRadiologyの場合にORIG_ORDER_DT_TMを使用。

取得

オーダーのステータスが「ORDERED」に設定された際に記録される

イベントタイプ explicit
診断結果検証
検査または画像診断の結果が確定し、臨床医に利用可能になった瞬間。これにより、診断のターンアラウンドタイム期間が終了します。
その重要性

「診断結果提供時間」サイクルを完了し、その後の治療決定をトリガーします。

取得元

CLINICAL_EVENTテーブル(検査用)またはORDERSのステータスがCOMPLETEDに変更。

取得

結果ステータスが「AUTH(認証済み)」に変更された際に記録される

イベントタイプ explicit
診断記録
患者のエンカウンター記録に正式な診断が追加された際に発生します。これは検査結果とは異なり、臨床医による病状の確認を表します。
その重要性

「診断確定」のマイルストーンおよび確定診断までの時間分析に不可欠です。

取得元

ENCOUNTER_IDにリンクされたDIAGNOSIS_DT_TMを使用するDIAGNOSISテーブル。

取得

PowerChartで診断が追加/更新された際に記録される

イベントタイプ explicit
退院指示署名済み
医師が患者を退院させるオーダーを発行するイベント。これにより、退院計画のカウントが開始されます。
その重要性

「退院計画サイクルタイム」の開始点。これと実際の退院との間にギャップがある場合、運用上の遅延を示します。

取得元

ORDERSテーブル、カタログタイプがDischargeを示す場合。

取得

退院オーダーのステータスが「ORDERED」になった際に記録される

イベントタイプ explicit
部門転送発生
患者が物理的にある場所(例:ER)から別の場所(例:ICU)へ移動したことを示します。これはロケーション履歴で追跡されます。
その重要性

「病棟間転送効率」分析を可能にし、病院内の患者の流れを視覚化するのに役立ちます。

取得元

ENCNTR_LOC_HIST(エンカウンター位置履歴)テーブル。LOC_NURSE_UNIT_CDの変更を捕捉します。

取得

ステータスフィールドを前後で比較

イベントタイプ inferred
ケアプラン有効化
CernerにおけるPowerPlanまたはケアパスウェイの開始を表します。これは、標準化された治療プロトコルが選択されたことを示します。
その重要性

実際のケアと計画された経路を比較する「治療プロトコル逸脱分析」に不可欠です。

取得元

ACT_PW_CAT (アクション経路カタログ) または DCP_FORMS_REF。経路とエンカウンターをリンクします。

取得

PowerPlanが開始された際に記録される

イベントタイプ explicit
コンサルテーション完了
専門医の診察が完了したことを示します。通常、署名されたコンサルテーションノートまたは文書によって証明されます。
その重要性

専門家の意見がいつ受け取られたかを特定し、これは複雑なケア経路におけるボトルネックとなる可能性があります。

取得元

コンサルテーションとして分類されたドキュメントタイプでフィルタリングされたCLINICAL_EVENTテーブル。

取得

コンサルトノートが署名された際に記録される

イベントタイプ explicit
フォローアップ予約済み
同一のエピソードまたはケアプランに紐付けられた患者の将来の予約が記録された際に発生します。
その重要性

「フォローアップ予約の適時性」ダッシュボードをサポートします。ケアの継続性の効率性を測定します。

取得元

SCH_APPT (スケジュール予約) テーブル、PERSON_IDにリンクされています。

取得

スケジュールモジュールで予約が作成された際に記録される

イベントタイプ explicit
処置スケジュール済み
外科的症例または主要な処置が特定の時間に予約されていることを示します。これにより、リソース配分と処置前の待ち時間を理解するのに役立ちます。
その重要性

手術室や処置室の利用におけるスケジューリング効率と潜在的なボトルネックを強調します。

取得元

SURGICAL_CASEテーブルまたはエンカウンターにリンクされたSCH_APPTテーブル。

取得

スケジュールトランザクションがコミットされた際に記録される

イベントタイプ explicit
処置実施済み
手術または主要な処置が実際にいつ行われたかを示すタイムスタンプ。これは多くの場合、周術期文書に記録されます。
その重要性

臨床パスとリソース利用率分析における重要なマイルストーンです。

取得元

SURGICAL_CASEテーブル(症例開始/終了時間)またはベッドサイド処置のCLINICAL_EVENT。

取得

SurgiNetまたは処置文書を介して記録される

イベントタイプ explicit
薬剤投与済み
薬剤投与記録 (MAR) に記載された、患者への実際の薬剤投与を記録します。
その重要性

薬剤が時間通りに投与されたかを確認することで、「薬剤投与コンプライアンス」ダッシュボードをサポートします。

取得元

薬剤投与イベント(タスクステータス = 完了)でフィルタリングされたCLINICAL_EVENTテーブル。

取得

バーコードスキャンまたは手動MAR入力時に記録される

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

抽出ガイド

Oracle Health (Cerner)からデータを取得する方法