Your Patient Journey Data Template
Your Patient Journey Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance
Patient Journey Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity
ClinicalEventTag
|
The name or description of the clinical or administrative event performed. | ||
|
Description
This attribute captures the specific action taken during the patient's care, such as 'Medication Administered', 'Vital Signs Taken', or 'Patient Discharged'. It provides the human-readable label for the process step. In Cerner, this is often derived from the
Why it matters
Defines the steps in the process map, enabling the visualization of the workflow.
Where to get
Table: CLINICAL_EVENT, Column: EVENT_TAG or linked CODE_VALUE for EVENT_CD
Examples
Triage AssessmentCBC with DifferentialDischarge OrderTransfer Patient
|
|||
|
Event Timestamp
EventEndDateTime
|
The specific date and time when the activity occurred or was completed. | ||
|
Description
This attribute records the precise moment an event took place. It is used to order activities sequentially and calculate cycle times between process steps. In the
Why it matters
Essential for determining the sequence of events and calculating performance KPIs like lead times.
Where to get
Table: CLINICAL_EVENT, Column: EVENT_END_DT_TM
Examples
2023-10-15T08:30:00Z2023-10-15T09:15:45Z2023-10-16T14:20:00Z
|
|||
|
Patient Episode
EncounterId
|
Unique identifier for the specific patient visit or episode of care. | ||
|
Description
This attribute serves as the central case identifier for the patient journey. It groups all clinical events, orders, and administrative actions occurring within a single period of care (e.g., an inpatient stay or an emergency visit). In process mining, this ID is essential for correlating disjointed activities into a unified process view. Technically, this corresponds to the
Why it matters
It is the fundamental key required to reconstruct the end-to-end patient journey from admission to discharge.
Where to get
Table: ENCOUNTER, Column: ENCNTR_ID
Examples
123456789876543211223344
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp when the record was extracted or last modified in the warehouse. | ||
|
Description
Indicates the freshness of the data used in the analysis. This timestamp helps users understand if they are looking at real-time data or a snapshot from a previous load. It is typically generated during the ETL (Extract, Transform, Load) process rather than being a clinical attribute.
Why it matters
Critical for data governance and ensuring analysis is performed on up-to-date information.
Where to get
ETL System Timestamp
Examples
2023-11-01T00:00:00Z2023-11-02T12:00:00Z
|
|||
|
Source System
SourceSystem
|
The name of the system where the data originated. | ||
|
Description
Identifies the source application for the data record. In this context, it will predominantly be 'Oracle Health' or 'Cerner Millennium'. This is useful in multi-system environments where data might be blended with other EMRs or departmental systems. It allows analysts to filter or segment the process analysis based on data provenance if multiple sources are ingested.
Why it matters
Ensures data lineage and traceability, especially in multi-system process mining setups.
Where to get
Hardcoded string or System Metadata
Examples
Oracle HealthCerner Millennium
|
|||
|
Case Type
EncounterType
|
Categorization of the patient visit, such as Inpatient, Outpatient, or Emergency. | ||
|
Description
Classifies the nature of the patient episode. This is a primary dimension for slicing the data, as the process flow for an 'Emergency' visit differs significantly from an 'Elective Inpatient' visit. This is derived from
Why it matters
Allows for comparative analysis of pathways and throughput across different care settings.
Where to get
Table: ENCOUNTER, Column: ENCNTR_TYPE_CD (resolve via CODE_VALUE)
Examples
InpatientEmergencyOutpatientDay Surgery
|
|||
|
Department
NurseUnit
|
The specific ward, unit, or department where the event occurred. | ||
|
Description
Identifies the physical location or organizational unit responsible for the patient at the time of the event (e.g., 'ICU', 'General Surgery', 'Emergency Dept'). This helps in the 'Inter-Ward Transfer Efficiency' dashboard by tracking movement between units. In Cerner, this is often
Why it matters
Essential for analyzing bottlenecks in specific departments and visualizing patient flow geography.
Where to get
Table: ENCOUNTER or CLINICAL_EVENT, Column: LOC_NURSE_UNIT_CD
Examples
Emergency DeptCardiology WardICURadiology
|
|||
|
Discharge Status
DischargeDisposition
|
The destination or status of the patient upon discharge. | ||
|
Description
Indicates where the patient went after the episode ended (e.g., 'Home', 'Skilled Nursing Facility', 'Expired'). This is critical for the 'Discharge Planning' analysis and identifying unsuccessful outcomes. Found in the
Why it matters
Key outcome metric; defines the 'end state' of the patient journey.
Where to get
Table: ENCOUNTER, Column: DISCH_DISPOSITION_CD (resolve via CODE_VALUE)
Examples
Discharged to HomeTransferred to RehabLeft Against Medical AdviceExpired
|
|||
|
Is Readmission
IsReadmission
|
Flag indicating if this episode occurred within 30 days of a previous discharge. | ||
|
Description
A boolean flag used to identify cases that represent a readmission. This is calculated by comparing the admission date of the current episode with the discharge date of the previous episode for the same Essential for the 'Patient Readmission Trends' dashboard.
Why it matters
Directly supports the 'Patient Readmission Rate' KPI, a key quality of care metric.
Where to get
Derived via SQL Logic comparing ENCOUNTER records
Examples
truefalse
|
|||
|
Length of Stay
LengthOfStay
|
Total duration of the patient episode in days or hours. | ||
|
Description
This is a calculated attribute representing the time difference between the admission timestamp and the discharge timestamp. It is the primary efficiency metric for the 'Overall Patient Length of Stay Analysis' dashboard. While this can be calculated within the process mining tool, importing it as a pre-calculated static attribute on the case level is often performance-efficient.
Why it matters
The single most important efficiency KPI for hospital management.
Where to get
Derived from ENCOUNTER.REG_DT_TM and DISCH_DT_TM
Examples
4.5 days2 hours12 days
|
|||
|
Order Item
OrderMnemonic
|
The name of the specific order placed, such as a lab test or medication. | ||
|
Description
Describes the content of an order event (e.g., 'Complete Blood Count', 'Aspirin 81mg'). This attribute provides necessary context for 'Diagnostic Order Placed' and 'Medication Administered' activities. It is typically found in the
Why it matters
Necessary for granular analysis of diagnostic and treatment pathways.
Where to get
Table: ORDERS, Column: ORDER_MNEMONIC
Examples
Chest X-RayBasic Metabolic PanelAcetaminophenMRI Brain
|
|||
|
Patient ID
PersonId
|
Unique identifier for the patient across multiple encounters. | ||
|
Description
Distinct from the Case ID, the Patient ID (or Person ID) remains constant for a patient across all their visits to the hospital. This attribute is crucial for analyzing readmission rates and understanding the patient's long-term history. In Cerner, this is the
Why it matters
Enables the 'Patient Readmission Rate' KPI by linking separate episodes to the same individual.
Where to get
Table: PERSON, Column: PERSON_ID
Examples
P10001P55992P99221
|
|||
|
Primary Diagnosis
DiagnosisCode
|
The ICD-10 or SNOMED code representing the primary reason for care. | ||
|
Description
The standardized clinical code (e.g., 'J18.9' for Pneumonia) assigned to the episode. This allows for grouping patients by condition to analyze 'Treatment Protocol Deviation' for specific diseases. Found in the
Why it matters
Enables apples-to-apples comparison of patient pathways for specific conditions.
Where to get
Table: DIAGNOSIS, Column: DIAGNOSIS_CODE (via nomenclature)
Examples
I10E11.9J18.9
|
|||
|
User
PerformingPrsnlId
|
The identifier or name of the clinician who performed the activity. | ||
|
Description
Captures who executed the process step, such as the nurse administering medication or the doctor signing the discharge. This allows for resource utilization analysis. In Cerner, this is often
Why it matters
Supports resource analysis and identifies potential training needs or workload imbalances.
Where to get
Table: CLINICAL_EVENT, Column: PERFORMED_PRSNL_ID
Examples
Dr. SmithRN JonesSysAdmin
|
|||
|
Admission Channel
AdmissionSource
|
The origin of the patient admission. | ||
|
Description
Describes how the patient entered the hospital system, such as 'Physician Referral', 'Emergency Room', or 'Transfer from other Hospital'. This helps analyze the 'front door' of the hospital process. It maps to the
Why it matters
Contextualizes the 'Initial Assessment Wait Time' based on entry point.
Where to get
Table: ENCOUNTER, Column: ADMIT_SRC_CD
Examples
Emergency RoomPhysician ReferralTransfer from Hospital
|
|||
|
Medication Status
MedAdminStatus
|
Status of the medication order (e.g., Given, Refused, Not Given). | ||
|
Description
Indicates the outcome of a medication administration task. For the 'Medication Admin Compliance' dashboard, it is vital to distinguish between medications actually administered versus those scheduled but missed or refused. Likely found in the
Why it matters
Identifies compliance gaps in treatment protocols.
Where to get
Consult Oracle Health (Cerner) documentation
Examples
AdministeredRefusedHeld
|
|||
|
Order Number
OrderId
|
Unique identifier for a specific order (Lab, Med, Consult). | ||
|
Description
The system-generated ID for an order. While not the Case ID, this is a crucial secondary key. It links the 'Diagnostic Order Placed' event to the 'Diagnostic Result Verified' event. Without this, it is difficult to calculate the exact turnaround time for specific tests if a patient has multiple concurrent orders.
Why it matters
Essential for linking paired activities (Order -> Result) accurately.
Where to get
Table: ORDERS, Column: ORDER_ID
Examples
88291028829103
|
|||
|
Payer Type
FinancialClass
|
The primary insurance coverage or financial classification of the patient. | ||
|
Description
Categorizes the patient based on their payer source (e.g., Medicare, Private Insurance, Self-Pay). This attribute is used to analyze if process flows or lengths of stay vary based on insurance type. Derived from
Why it matters
Helps identify disparities in care delivery or administrative processing based on payer type.
Where to get
Table: ENCOUNTER, Column: FINANCIAL_CLASS_CD (resolve via CODE_VALUE)
Examples
MedicareBlue CrossSelf-PayMedicaid
|
|||
|
Result Status
ResultStatus
|
The status of a diagnostic result (e.g., Auth (Verified), Corrected, Preliminary). | ||
|
Description
Indicates the lifecycle stage of a diagnostic test result. This is used in the 'Diagnostic Result Delivery Time' analysis to determine when a result is officially available for clinical decision-making. Typically found in
Why it matters
Differentiates between preliminary and final results, which impacts when downstream activities can start.
Where to get
Table: CLINICAL_EVENT, Column: RESULT_STATUS_CD
Examples
Auth (Verified)In ErrorModified
|
|||
|
Triage Priority
TriageAcuity
|
The urgency level assigned during triage assessment. | ||
|
Description
A numeric or categorical value indicating the severity of the patient's condition (e.g., 1-Immediate to 5-Non-urgent). This is a vital segmentation attribute for analyzing wait times, as higher priority patients should have shorter waits. Usually captured in clinical forms or specific observation codes during the Triage event.
Why it matters
Critical for validating if the process prioritizes patients correctly according to clinical urgency.
Where to get
Consult Oracle Health (Cerner) documentation
Examples
12345
|
|||
Patient Journey Activities
| Activity | Description | ||
|---|---|---|---|
|
Department Transfer Occurred
|
Indicates the patient physically moved from one location (e.g., ER) to another (e.g., ICU). This is tracked via location history. | ||
|
Why it matters
Enables 'Inter-Ward Transfer Efficiency' analysis and helps visualize patient flow through the hospital.
Where to get
ENCNTR_LOC_HIST (Encounter Location History) table, capturing changes in LOC_NURSE_UNIT_CD.
Capture
Compare status field before/after
Event type
inferred
|
|||
|
Diagnosis Documented
|
Occurs when a formal diagnosis is added to the patient's encounter record. This is distinct from a test result and represents the clinician's confirmation of the condition. | ||
|
Why it matters
Essential for the 'Diagnosis Confirmed' milestone and analyzing the time to definitive diagnosis.
Where to get
DIAGNOSIS table, using the DIAGNOSIS_DT_TM linked to the ENCOUNTER_ID.
Capture
Logged when diagnosis is added/updated in PowerChart
Event type
explicit
|
|||
|
Diagnostic Order Placed
|
Occurs when a clinician enters an order for a lab test or imaging study. This timestamp initiates the diagnostic turnaround time calculation. | ||
|
Why it matters
The starting point for the 'Diagnostic Result Delivery Time' KPI; helps identify delays in ordering versus execution.
Where to get
ORDERS table, using ORIG_ORDER_DT_TM where the catalog type is Laboratory or Radiology.
Capture
Logged when order status is set to ORDERED
Event type
explicit
|
|||
|
Diagnostic Result Verified
|
The moment a lab or imaging result is finalized and made available to the clinician. This ends the diagnostic turnaround time interval. | ||
|
Why it matters
Completes the 'Diagnostic Result Delivery Time' cycle and triggers subsequent treatment decisions.
Where to get
CLINICAL_EVENT table (for labs) or ORDERS status change to COMPLETED.
Capture
Logged when result status changes to AUTH (Authenticated)
Event type
explicit
|
|||
|
Discharge Order Signed
|
The event where the physician places the order to discharge the patient. This starts the discharge planning clock. | ||
|
Why it matters
The start point for 'Discharge Planning Cycle Time'. A gap between this and actual discharge indicates operational delays.
Where to get
ORDERS table, where catalog type indicates Discharge.
Capture
Logged when discharge order status is ORDERED
Event type
explicit
|
|||
|
Patient Discharged
|
The final administrative event closing the patient's stay. This timestamp is used to calculate the total Length of Stay. | ||
|
Why it matters
The primary end event for the process. Essential for LOS and readmission calculations.
Where to get
ENCOUNTER table, specifically the DISCH_DT_TM (Discharge Date/Time).
Capture
Logged when encounter status changes to DISCHARGED
Event type
explicit
|
|||
|
Patient Registered
|
Marks the beginning of the patient episode when the patient arrives and is entered into the system. In Cerner Millennium, this is captured when the encounter record is created or the registration timestamp is set. | ||
|
Why it matters
Establishes the start time for Length of Stay (LOS) calculations and initial wait time analysis.
Where to get
ENCOUNTER table, specifically the REG_DT_TM (Registration Date/Time) column.
Capture
Logged when transaction creates new ENCOUNTER row
Event type
explicit
|
|||
|
Triage Assessment Completed
|
Represents the completion of the initial nursing assessment or triage form in the emergency or admission context. This is typically a specific form or clinical event documented within the system. | ||
|
Why it matters
Critical for calculating the 'Initial Assessment Wait Time' KPI and identifying bottlenecks at the front door.
Where to get
CLINICAL_EVENT table, filtered by event codes associated with Triage or Initial Assessment forms.
Capture
Logged when clinical document/form is signed/verified
Event type
explicit
|
|||
|
Care Plan Activated
|
Represents the initiation of a PowerPlan or care pathway in Cerner. This signals that a standardized treatment protocol has been selected. | ||
|
Why it matters
Crucial for 'Treatment Protocol Deviation Analysis' to compare actual care against the planned pathway.
Where to get
ACT_PW_CAT (Action Pathway Catalog) or DCP_FORMS_REF, linking the pathway to the encounter.
Capture
Logged when PowerPlan is initiated
Event type
explicit
|
|||
|
Consultation Completed
|
Marks the completion of a specialist consultation, usually evidenced by a signed consultation note or document. | ||
|
Why it matters
Identifies when specialist input was received, which can be a bottleneck in complex care pathways.
Where to get
CLINICAL_EVENT table, filtering for document types classified as Consultations.
Capture
Logged when consult note is signed
Event type
explicit
|
|||
|
Follow-up Appointment Scheduled
|
Occurs when a future appointment is booked for the patient linked to the same episode or care plan. | ||
|
Why it matters
Supports 'Follow-up Scheduling Timeliness' dashboard. Measures continuity of care efficiency.
Where to get
SCH_APPT (Schedule Appointment) table, linked to the PERSON_ID.
Capture
Logged when appointment is created in scheduling module
Event type
explicit
|
|||
|
Medication Administered
|
Records the actual administration of medication to the patient as documented in the Medication Administration Record (MAR). | ||
|
Why it matters
Supports the 'Medication Admin Compliance' dashboard by verifying if meds were given on time.
Where to get
CLINICAL_EVENT table, filtered for medication administration events (Task Status = Complete).
Capture
Logged upon barcode scan or manual MAR entry
Event type
explicit
|
|||
|
Procedure Performed
|
The timestamp indicating when a surgery or major procedure actually took place. This is often captured in the perioperative documentation. | ||
|
Why it matters
Key milestone for clinical pathways and resource utilization analysis.
Where to get
SURGICAL_CASE table (Case Start/Stop times) or CLINICAL_EVENT for bedside procedures.
Capture
Logged via SurgiNet or procedure documentation
Event type
explicit
|
|||
|
Procedure Scheduled
|
Indicates that a surgical case or major procedure has been booked for a specific time. This helps in understanding resource allocation and pre-procedure wait times. | ||
|
Why it matters
Highlights scheduling efficiency and potential bottlenecks in operating room or procedure room utilization.
Where to get
SURGICAL_CASE table or SCH_APPT table linked to the encounter.
Capture
Logged when scheduling transaction is committed
Event type
explicit
|
|||