患者の受診プロセス向けデータテンプレート
患者の受診プロセス向けデータテンプレート
- 収集を推奨する属性
- 追跡すべき主なアクティビティ
- athenahealthからのデータ抽出ガイド
患者の受診プロセスの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
患者の診療経過で発生したイベントまたは実施したタスクの名前です。 | ||
|
説明
「患者の受付完了」「診断検査オーダー登録」「薬剤投与」など、プロセス内で発生した具体的なステップを示します。この文字列がプロセスマップのノード名になります。 プロセスの流れを可視化し、処理の順序を特定するために使います。プロセスマップを読みやすくし、不要な分類を避けるには、名称の標準化が欠かせません。
重要な理由
プロセスマップのステップを定義する項目であり、プロセスマイニングに必須です。
入手先
監査ログ、予約ステータスの変更、請求明細の説明から取得します。
例
予約を登録患者が受付を完了診断検査を依頼患者が退院
|
|||
|
イベント発生時刻
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です。 | ||
|
説明
この属性は中心となるケース識別子として機能し、患者の特定の診療期間や疾患に関連するすべてのアクティビティをまとめます。予約、診断オーダー、退院手続きなど、個別に記録されたイベントを一連の診療経過として結び付けます。 分析では、この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コードです。 | ||
|
説明
患者の診療経過の臨床的な理由を分類します。「年齢層・診断別の診療経過比較」に必要なコンテキストを提供します。 肺炎と骨折など、疾患ごとに診療経過を分けて分析できます。疾患によって想定される診療経路やサイクルタイムは大きく異なるためです。
重要な理由
診断によってサイクルタイムが大きく異なるため、条件の近いケースを比較するのに役立ちます。
入手先
EncounterまたはClaimの診断フィールド(ICD-10)です。
例
J18.9I10E11.9
|
|||
|
再入院の有無
IsReadmission
|
この診療エピソードが予定外の再受診に該当するかを示すフラグです。 | ||
|
説明
前回の退院から一定期間(例:30日)以内に患者が再入院したかを示す真偽値です。「予定外再入院率」のKPIに直接役立ちます。 この属性で絞り込むと、再入院の根本原因を詳しく調べ、初回の診療経路に見られる傾向を特定できます。
重要な理由
再入院率のKPIに直接役立ちます。
入手先
ETL処理時に、入院日と前回の退院日を比較して算出します。
例
truefalse
|
|||
|
医療従事者名
ProviderName
|
アクティビティを実施した医療従事者の名前です。 | ||
|
説明
イベントを担当した医師、看護師、技師を特定します。この属性はリソース利用状況の分析に欠かせません。 スタッフ間の処理量やサイクルタイムなどの指標を比較し、研修の必要性や業務負荷の偏りを把握できます。
重要な理由
リソース利用率の把握と、引き継ぎの分析に役立ちます。
入手先
athenahealthの「providerid」を医療従事者ディレクトリの名前に対応付けます。
例
Smith医師Jones看護師Adams技師
|
|||
|
受診種別
EncounterType
|
受診の分類です(例:外来、遠隔診療、救急)。 | ||
|
説明
提供された診療の形態や場所を示します。汎用データモデルでは「ケースタイプ」に相当します。 受診種別によって想定される流れや請求要件は異なります。サイクルタイムを分析する際に、この属性で絞り込むことで、条件の異なるケースを比較せずに済みます。
重要な理由
遠隔診療と対面診療など、異なるプロセスバリアントを区別します。
入手先
athenahealthの「encountertype」フィールドです。
例
外来遠隔診療救急手術
|
|||
|
患者ID
PatientId
|
患者を識別する一意のID(匿名化またはハッシュ化済み)です。 | ||
|
説明
診療経過の対象となる患者を一意に識別します。ケース識別子と似ていますが、同じ患者が時間をおいて複数の診療エピソードを持つ場合があります。 再診を関連付け、再入院率を分析するために使います。「予定外再入院率」のKPIを算出するうえで欠かせません。
重要な理由
診療エピソードをまたいで再入院や患者の履歴を追跡するために必要です。
入手先
athenahealthの「patientid」フィールドです。
例
PAT-100234PAT-559201PAT-992210
|
|||
|
患者の年齢層
PatientAgeGroup
|
患者の年齢を区分したグループです(例:18~25歳、65歳以上)。 | ||
|
説明
患者を年齢層ごとのグループに分けます。「年齢層・診断別の診療経過比較」ダッシュボードに必要です。 プロセスの非効率や治療結果が、高齢者や小児など特定の年齢層に偏って影響していないかを把握できます。
重要な理由
医療プロセス分析で標準的に使われる人口統計上の区分です。
入手先
患者の生年月日と開始時刻から算出します。
例
18-2930-4965+
|
|||
|
診療科名
DepartmentName
|
アクティビティが発生した病院または診療所の診療科です。 | ||
|
説明
救急科、循環器科、放射線科などの機能単位ごとにプロセスデータを分けます。「診療科別の処理量と引き継ぎ」ダッシュボードに必要です。 この属性を使った分析により、特定の診療科のボトルネックを明らかにし、診療科をまたぐ患者の流れを改善できます。
重要な理由
組織内のボトルネックや、引き継ぎの非効率な点を特定するうえで重要です。
入手先
athenahealthの「departmentid」を診療科名に対応付けます。
例
救急科内科放射線科
|
|||
|
退院先
DischargeDisposition
|
退院時の患者の行き先または状態です。 | ||
|
説明
退院後の行き先を示します。例として、自宅、介護施設、ホスピスがあります。「退院計画と再入院の傾向」を分析するうえで重要です。 退院計画の複雑さを把握し、診療移行が適切に行われているかを評価できます。
重要な理由
退院計画と再入院リスクを把握するための重要なコンテキストです。
入手先
athenahealthの受診フィールド、または病院の退院記録です。
例
自宅介護施設短期入院病院へ転院死亡
|
|||
|
オーダー種別
OrderType
|
オーダーの分類です(例:検査、画像診断、処方)。 | ||
|
説明
診療エピソード中に登録された臨床オーダーを分類します。「診断検査のリードタイム」ダッシュボードに欠かせません。 検査と画像診断それぞれのリードタイムを測定できます。両者ではサービスレベルの合意内容やボトルネックが異なることが多いためです。
重要な理由
診断プロセスを分け、リードタイムを個別に分析できます。
入手先
athenahealthの「ordertype」、またはorders APIの「class」です。
例
検査画像診断処方処置
|
|||
|
手戻りの有無
IsRework
|
このアクティビティが繰り返されたかを示すフラグです。 | ||
|
説明
同じケース内でアクティビティが複数回発生した場合に真となるフラグです。「アクティビティの発生頻度と手戻りループ」ダッシュボードに役立ちます。 手戻りが発生したケースをすぐに抽出でき、「手戻りアクティビティの発生頻度」KPIを算出できます。
重要な理由
プロセスの非効率な点や重複するステップを特定します。
入手先
ETL処理時に、CaseIdごとのアクティビティ発生回数に基づいて算出します。
例
truefalse
|
|||
|
診断結果のステータス
DiagnosticResultStatus
|
診断オーダーの結果ステータスです(例:陽性、正常)。 | ||
|
説明
検査の概要結果を記録します。「診断検査のリードタイム」や、その後の治療方針を分析する際のコンテキストになります。 異常結果の場合、正常結果の場合と比べて、その後の対応が早く行われるかを分析できます。
重要な理由
プロセスの流れと臨床結果を関連付けます。
入手先
athenahealthの検査結果観察フィールドです。
例
正常異常重大
|
|||
|
請求ステータス
ClaimStatus
|
診療に関連する保険請求のステータスです。 | ||
|
説明
「送信済み」「否認」「支払済み」など、請求の進捗状況を示します。「請求送信」アクティビティや財務面の処理量を分析する際に関係します。 診療記録の問題が、後続の請求処理の遅れにつながっていないかを特定できます。
重要な理由
診療の効率と収益サイクルの実績を関連付けます。
入手先
athenahealthの「claimstatus」フィールドです。
例
請求済み保留送信
|
|||
|
請求総額
TotalChargeAmount
|
アクティビティまたは診療エピソードに対して請求された金額です。 | ||
|
説明
アクティビティに関連する金額、または請求総額です。コストに基づくプロセスマイニングや財務影響の分析に利用できます。 治療経路の中でコストが高いバリアントを特定し、プロセスの効率と財務上の結果との関係を分析できます。
重要な理由
プロセス分析に財務面の情報を加えます。
入手先
athenahealthの請求・料金テーブルにある「amount」または「totalcharge」です。
例
150.002500.5045.00
|
|||
患者の受診プロセスのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
処置を実施
|
手術や専門的な治療などの臨床処置が患者に実施されます。臨床文書に明示的なイベントとして記録され、多くの場合、処置記録に開始時刻と終了時刻が記載されます。 | ||
|
重要な理由
処置は患者の治療における重要な節目です。処置の前後のアクティビティを分析すると、術前・術後のワークフローの最適化に役立ちます。
入手先
athenaClinicalsの処置記録または特定の臨床フローシートで確認できます。イベントのタイムスタンプは、記録された処置の開始時刻または終了時刻から取得します。
記録
処置が行われた時刻を含む処置記録またはログが作成されます。
イベントタイプ
explicit
|
|||
|
初回評価を完了
|
トリアージや看護師による評価など、バイタルサインと主な訴えを記録する初回の臨床評価が完了したことを示します。このイベントは、受診に関する最初の臨床記録への署名時刻や、評価フォームの完了時刻から推定されることがよくあります。 | ||
|
重要な理由
この節目は臨床ケアの開始を示します。受付からこのアクティビティまでの時間は、患者の初期待ち時間とリソース対応の速さを測る重要な指標です。
入手先
athenaClinicals内の特定の臨床文書やフローシートの作成時刻または署名時刻から推定します。トリアージや初診時の情報収集に該当する文書の種類を特定する必要があります。
記録
受診に関する臨床記録、バイタルサインのフローシート、または特定の初診時問診フォームの最初のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
患者が受付を完了
|
患者が到着し、予約または受診の受付を正式に済ませたことを示します。通常、athenaClinicalsまたはathenaCommunicatorの予約記録における明示的なステータス変更として記録されます。 | ||
|
重要な理由
患者が施設内で受診するプロセスの明確な開始点です。待ち時間や診療のサイクルタイム全体を測定する際の重要な起点となります。
入手先
予約または受診のテーブルにステータス更新として記録されます。「受付済み」ステータスと対応するタイムスタンプを確認してください。
記録
予約または受診のオブジェクトに対するステータス変更が、タイムスタンプとともに記録されます。
イベントタイプ
explicit
|
|||
|
患者が退院
|
患者の退院が正式に完了し、施設内での受診プロセスが終了したことを示します。入院受診における最後のADTイベントで、正確なタイムスタンプが記録されます。 | ||
|
重要な理由
患者の主な受診プロセスの終了を示します。患者の受診プロセス全体のサイクルタイムを測定する終点であり、再入院の分析にも欠かせません。
入手先
ADTシステムまたは患者の受診テーブルに明示的なイベントとして記録されます。受診の最終ステータスが「退院」となったことをタイムスタンプとともに示します。
記録
患者の受診ステータスが「退院」に更新され、ADTイベントが記録されます。
イベントタイプ
explicit
|
|||
|
検査結果を受領
|
診断検査の結果が確定し、患者のカルテで確認できるようになったことを示します。通常、検査システムまたは画像診断システムからathenahealthに結果が送信され、タイムスタンプ付きの記録が作成されます。 | ||
|
重要な理由
結果の受領は、診断や治療計画など、その後の臨床判断につながる重要なきっかけです。このイベントは、診断にかかる所要時間を測定する際の終点となります。
入手先
元のオーダーに関連付けられた結果または診断のテーブルに記録されます。結果が患者のカルテに登録または受信された時刻が、イベントのタイムスタンプとなります。
記録
多くの場合、LISまたはRISとの連携を通じて、タイムスタンプ付きの新しい結果レコードが作成されます。
イベントタイプ
explicit
|
|||
|
診断を確定
|
医療従事者が、現在の受診における患者の状態について診断を正式に割り当てる、または確定します。患者の受診に関連付けられた主要な診断コード(ICD-10など)の作成時刻や最終更新時刻から推定できます。 | ||
|
重要な理由
その後の治療経路を決める重要な節目です。この時点以降のアクティビティのばらつきを分析すると、ケア手順の理解と標準化に役立ちます。
入手先
患者の問題リストまたは受診時の診断データから推定します。診断コードの変更または確定と、そのタイムスタンプがイベントを示します。
記録
受診における主要な診断が追加または更新された時刻を特定します。
イベントタイプ
inferred
|
|||
|
退院指示を作成
|
医師または権限を持つ医療従事者が、患者の退院を正式に指示します。EHRのCPOEモジュールで作成される、タイムスタンプ付きの明示的なイベントです。 | ||
|
重要な理由
このアクティビティをきっかけに退院プロセスが始まります。指示から実際の退院までの時間は、「退院計画のリードタイム」を測る重要業績評価指標です。
入手先
オーダーテーブルで確認できます。特定の「退院」オーダー種別とその作成時刻からイベントを特定します。
記録
オーダーテーブルに、オーダー種別が「退院」の新しいレコードが作成されます。
イベントタイプ
explicit
|
|||
|
フォローアップの予約を登録
|
主な治療または退院の後に、患者のフォローアップ予約が登録されます。athenaCommunicatorの予約管理モジュールで新しい予約を作成すると、このイベントが明示的に記録されます。 | ||
|
重要な理由
このアクティビティは、退院後のケア連携と再入院率などの治療成果への影響を把握するうえで重要です。ケアが継続していることを示します。
入手先
予約テーブルに記録されます。退院日より後に行われる予約の作成時刻からイベントを特定します。
記録
予約管理システムに新しい予約レコードが作成されます。
イベントタイプ
explicit
|
|||
|
予約を登録
|
患者の予約が登録されたことを示します。athenahealthの予約管理モジュールathenaCommunicatorで、新しい予約を作成して確定すると、このイベントが明示的に記録されます。 | ||
|
重要な理由
このアクティビティは、多くの患者の受診プロセスの開始点です。予約から受付までの時間を分析すると、患者の受診しやすさや来院前の業務効率を把握できます。
入手先
予約またはスケジュール管理のテーブルに明示的なイベントとして記録されます。通常、作成日時と患者IDが関連付けられています。
記録
スケジュール管理モジュールで予約記録が作成された時点でイベントが記録されます。
イベントタイプ
explicit
|
|||
|
患者を移送
|
患者が、救急部門から入院病棟へ移る場合のように、ある診療単位または部門から別の場所へ移動します。EHRの入院・退院・転棟(ADT)イベントとして明示的に記録されます。 | ||
|
重要な理由
このアクティビティは、施設内の部門間の引き継ぎや患者の流れを分析するうえで重要です。「患者の引き継ぎ時間」におけるボトルネックやリソース配分の問題を特定できます。
入手先
ADTイベントログまたは患者追跡テーブルに記録されます。各移送イベントには、患者、移送元と移送先、タイムスタンプが含まれます。
記録
患者の移送時に、タイムスタンプ付きのADTメッセージまたはイベントログの記録が作成されます。
イベントタイプ
explicit
|
|||
|
検体を採取
|
検査のために、患者から血液や尿などの生体検体を採取したことを示します。通常、検査モジュールに明示的なイベントとして記録されるか、オーダーステータスの更新として記録されます。 | ||
|
重要な理由
診断検査プロセスにおける重要な節目です。依頼、採取、結果の各時点の間隔を確認すると、検査ワークフローの大きなボトルネックが分かることがあります。
入手先
検査オーダーのステータス変更、またはathenahealthと連携した検査情報システムの独立したイベントとして確認できます。「採取済み」ステータスとタイムスタンプを確認してください。
記録
検査オーダーのステータス更新、または専用の検体追跡モジュールに記録されます。
イベントタイプ
explicit
|
|||
|
治療計画を作成
|
医療従事者が患者の治療計画を正式に作成し、文書化したことを示します。特定の「ケア計画」文書の作成または署名、あるいは関連する一連の治療オーダーとして記録できます。 | ||
|
重要な理由
このアクティビティによって、予定している臨床経路が正式に定まります。標準的な手順への適合性を測定し、ケアのばらつきを分析する重要な時点です。
入手先
臨床文書またはオーダーのテーブルで確認できる可能性があります。署名済みのケア計画記録のタイムスタンプ、または連携した一連の治療オーダーの送信時刻が該当します。
記録
特定の治療計画文書またはオーダーセットの作成時刻、あるいは確定時刻がイベントとなります。
イベントタイプ
explicit
|
|||
|
薬剤を投与
|
医療スタッフが患者に薬剤を実際に投与します。athenaClinicalsの投薬記録(MAR)モジュールに明示的に記録され、投与ごとに正確なタイムスタンプが付与されます。 | ||
|
重要な理由
このアクティビティは、治療が実際に行われたことを示します。投与時刻を分析すると、「初回治療までの時間」を測定し、投薬スケジュールの遵守状況を確認できます。
入手先
MARのデータテーブルで確認できます。各投与イベントには、患者ID、薬剤ID、投与量、投与時刻が含まれます。
記録
薬剤を投与したことが記録されるたびに、MARにタイムスタンプ付きのレコードが作成されます。
イベントタイプ
explicit
|
|||
|
診断検査を依頼
|
医療従事者が、検査、画像診断、その他の処置などの診断検査を依頼します。athenaClinicalsのCPOE(医師による電子オーダー入力)機能で作成される、タイムスタンプ付きの明示的なイベントです。 | ||
|
重要な理由
診断のサブプロセスを開始する重要な判断点です。このアクティビティを追跡することは、依頼から結果までの「診断検査のリードタイム」という重要業績評価指標(KPI)の分析に欠かせません。
入手先
オーダーテーブルで確認できます。各オーダーには、患者識別子、オーダー名、オーダーステータス、作成時刻が含まれます。
記録
システムのオーダーテーブルに、タイムスタンプ付きの新しいレコードが作成されます。
イベントタイプ
explicit
|
|||
|
請求を提出
|
患者の受診中に提供したサービスの請求を作成し、支払者に提出します。athenahealthの収益サイクル管理モジュールathenaCollector内で発生する明示的なイベントです。 | ||
|
重要な理由
管理上の手順ではありますが、このアクティビティは、診療の流れと並行して進む収益サイクルの分析に欠かせません。診療から請求までの遅れを特定するのに役立ちます。
入手先
請求または請求処理のテーブルに記録されます。請求の作成または送信時刻がイベントの目印になります。
記録
請求レコードが作成され、時刻とともにステータスが「送信済み」に更新されます。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできていますか?
患者ケアの最適化に向けて、取り組みを始めましょう。このテンプレートは、価値あるインサイトを見つけ、医療の成果を高めるための第一歩です。
患者の受診プロセスを今すぐ最適化し、ボトルネックを解消
athenahealthの非効率な箇所を特定し、患者の受診プロセスのサイクルタイムを30%短縮します。
クレジットカードは不要です。今日から最適化に取り組めます。