Your Patient Journey Data Template

Oracle Health (Cerner)
Your Patient Journey Data Template

Your Patient Journey Data Template

This comprehensive template outlines the essential data you need to effectively analyze and optimize patient journeys. It provides a structured overview of the critical attributes to collect, the key activities to track, and practical guidance on data extraction. Use this resource to prepare your event log for a seamless process mining experience.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance
New to event logs? Learn how to create a process mining event log.

Patient Journey Attributes

These are the recommended data fields to include in your event log for a comprehensive analysis of the patient journey within your system.
5 Required 9 Recommended 6 Optional
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 CLINICAL_EVENT table, specifically mapping the EVENT_CD (Event Code) to its display value or using the EVENT_TAG. Consistent naming conventions here are crucial for readable process maps.

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 CLINICAL_EVENT table, this usually corresponds to EVENT_END_DT_TM. Accuracy here is vital for calculating wait times, such as the duration between 'Patient Registered' and 'Triage Assessment'.

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 ENCNTR_ID in the ENCOUNTER table within the Cerner Millennium database. It is the primary key used to link patient demographics, orders, and clinical events.

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 ENCNTR_TYPE_CD in the ENCOUNTER table, which references a code set value (e.g., 'Inpatient', 'Emergency').

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 LOC_NURSE_UNIT_CD on the encounter or tracking table.

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 ENCOUNTER table as DISCH_DISPOSITION_CD.

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 PersonId.

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 ORDERS table under ORDER_MNEMONIC. It acts as the 'Product' flowing through the process.

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 PERSON_ID from the PERSON table. It links multiple ENCNTR_ID records together.

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 DIAGNOSIS table, linked to the encounter.

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 PERFORMED_PRSNL_ID or UPDT_ID depending on the table (Orders vs Clinical Events). Mapping this to a generic 'User' attribute facilitates Segregation of Duties analysis.

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 ADMIT_SRC_CD in the ENCOUNTER table.

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 CLINICAL_EVENT or specific Medication Administration Record (MAR) tables.

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 FINANCIAL_CLASS_CD in the ENCOUNTER table.

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 CLINICAL_EVENT with specific status codes.

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
Required Recommended Optional

Patient Journey Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and bottleneck identification.
8 Recommended 6 Optional
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
Recommended Optional

Extraction Guides

How to get your data from Oracle Health (Cerner)