> Continuous Process Improvement > Patient Journey > Veradigm (Allscripts) > Data Template

Your Patient Journey Data Template

Veradigm (Allscripts)

Patient Journey Attributes (20) Patient Journey Activities (13) Extraction Guides (2)

Your Patient Journey Data Template

This template provides a structured approach to collecting the necessary data for analyzing your patient journey process. It outlines the essential attributes and activities to track, along with practical guidance on extracting this information from your source system. Use this resource to prepare your data for comprehensive process mining.

Recommended attributes to collect for comprehensive analysis
Key activities to track for accurate process discovery
Practical guidance for data extraction from your system

New to event logs? Learn how to create a process mining event log.

Download Template

Patient Journey Attributes

These are the recommended data fields to include in your event log for a comprehensive analysis of the patient journey process.

3 Required 9 Recommended 8 Optional

	Name	Description
	Activity Name ActivityName	The specific clinical or administrative event performed.
Description Describes the step performed in the process, such as 'Patient Registered', 'Medication Administered', or 'Discharge Planning Initiated'. This attribute differentiates the various stages of the patient journey and is essential for process discovery and variant analysis. Why it matters Defines the nodes in the process map; without this, no process flow can be visualized. Where to get Derived from various transactional tables: ADT events, Orders, Results, and Clinical Documentation tables. Examples Patient RegisteredDiagnostic Test OrderedMedication AdministeredPatient Discharged
	Event Timestamp EventDateTime	The exact date and time when the activity occurred.
Description Records the chronological point of the activity. This is critical for calculating cycle times, durations, and ordering the sequence of events properly. In healthcare data, precision down to the minute is vital for accurate throughput analysis. Why it matters Enables the calculation of all time-based KPIs, including Average Patient Journey Cycle Time and Wait Times. Where to get Transaction timestamps in source tables (e.g., ADT_DATE, ORDER_DATE, RESULT_DATE). Examples 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Patient Episode PatientEpisodeId	Unique identifier for the specific patient visit or encounter.
Description The Patient Episode serves as the primary case identifier, grouping all events related to a patient's specific healthcare journey for a particular condition or period of care. This allows for an integrated view of diagnosis, treatment, and recovery phases, linking various departmental interactions into a cohesive whole. In Veradigm (Allscripts) systems (like Sunrise or Paragon), this usually corresponds to the Visit ID or Encounter Number. Why it matters It is the fundamental key for process mining, allowing the reconstruction of the end-to-end patient journey. Where to get Likely found in the header of the Visit or Encounter tables (e.g., VISIT_ID, ENCOUNTER_ID). Consult Veradigm (Allscripts) documentation. Examples EP-2023-998877VIS-10029384100029384ENC-554433
	Admission Date AdmissionDate	The date and time the patient was formally admitted.
Description The timestamp marking the beginning of the inpatient stay. Used in conjunction with Discharge Date to calculate Length of Stay (ALOS). Why it matters Critical anchor point for ALOS calculation and measuring admission delays. Where to get Visit/Encounter header table (e.g., ADMIT_DATE). Consult Veradigm (Allscripts) documentation. Examples 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Attending Provider AttendingProvider	The primary clinician responsible for the patient during the event.
Description Identifies the doctor, nurse, or specialist performing the activity or responsible for the care plan. Analyzing this attribute helps in understanding 'Clinical Resource Utilization' and variations in care pathways by physician. Why it matters Allows for resource bottleneck analysis and performance benchmarking across clinical staff. Where to get Transaction tables (e.g., ORDERing_PROVIDER, ATTENDING_PHYSICIAN_ID). Consult Veradigm (Allscripts) documentation. Examples Dr. Sarah SmithNurse Practitioner JonesRadiology Tech A
	Department Name DepartmentName	The hospital unit or department where the activity took place.
Description Indicates the location context, such as 'Emergency Room', 'Cardiology', or 'Radiology'. This is vital for the 'Admission & Transfer Bottleneck Analysis' to see where patients are getting stuck moving between wards. Why it matters Supports resource utilization analysis and identification of departmental bottlenecks. Where to get Location or Department master tables linked to the transaction. Consult Veradigm (Allscripts) documentation. Examples Emergency DepartmentICUGeneral SurgeryRadiology
	Discharge Date DischargeDate	The date and time the patient was discharged.
Description The timestamp marking the end of the episode. This is used to close the case in process mining and is essential for ALOS and Readmission calculations. Why it matters Defines the end of the process cycle; crucial for throughput analysis. Where to get Visit/Encounter header table (e.g., DISCH_DATE). Consult Veradigm (Allscripts) documentation. Examples 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Discharge Disposition DischargeDisposition	The status or location of the patient upon discharge.
Description Indicates where the patient went after the hospital stay (e.g., 'Home', 'Skilled Nursing Facility', 'Expired', 'Transfer'). This is important for analyzing readmission risks, as different dispositions carry different risk profiles. Why it matters Contextualizes the 'Discharge Planning' dashboard and helps explain variances in ALOS. Where to get Visit/Encounter header table (e.g., DISCH_DISP). Consult Veradigm (Allscripts) documentation. Examples HomeTransferred to SNFHome with Home HealthLeft Against Medical Advice
	Is Readmission IsReadmission	Flag indicating if this episode is a readmission within 30 days.
Description A calculated boolean attribute. It returns true if the patient had a prior discharge within 30 days of the current admission date. This drives the 'Avoidable Readmission Rate Monitor'. Why it matters Core KPI for hospital quality and reimbursement (especially for CMS regulations). Where to get Calculated in the ETL/Data Transformation layer using PatientMRN and Admission/Discharge dates. Examples truefalse
	Length of Stay LengthOfStay	Duration of the hospital stay in days.
Description The calculated duration between 'Admission Date' and 'Discharge Date'. Used for the 'Average Length of Stay (ALOS)' KPI. While it can be calculated in the dashboard, having it as an attribute simplifies filtering (e.g., 'Show me all stays > 7 days'). Why it matters Standard measure of efficiency and resource consumption. Where to get Calculated: DischargeDate - AdmissionDate. Examples 4.512.00.8
	Patient MRN PatientMrn	Medical Record Number uniquely identifying the patient across episodes.
Description The Medical Record Number (MRN) or Enterprise Patient ID. Unlike the Patient Episode ID, this ID remains constant for the patient across different visits. This is the critical key for linking separate episodes to calculate readmission rates. Why it matters Essential for '30-Day Readmission Rate' and identifying repeat customers. Where to get Patient master index or demographic tables (likely columns: MRN, PATIENT_ID). Consult Veradigm (Allscripts) documentation. Examples MRN-884422P-10022399887766
	Primary Diagnosis Code PrimaryDiagnosisCode	The ICD-10 or SNOMED code representing the main condition.
Description The coded reason for the patient's visit. This attribute is the filter for the 'Treatment Pathway Variation Explorer'. It allows analysts to compare how different conditions (e.g., Pneumonia vs. Heart Failure) flow through the system. Why it matters Required for segmenting processes by clinical condition and checking protocol adherence. Where to get Diagnosis or problem list tables (typically ICD-10 columns). Consult Veradigm (Allscripts) documentation. Examples I50.9J18.9E11.9
	Cost Center CostCenter	The financial code associated with the department or service.
Description Maps the clinical activity to a financial unit. This helps in analyzing the 'Activity Cost' or generic financial performance of different departments. Why it matters Connects operational process mining to financial impact. Where to get Department or Charge master tables. Consult Veradigm (Allscripts) documentation. Examples CC-1020CC-Rad-01Emergency-001
	Diagnostic Turnaround Time DiagnosticTurnaroundTime	Time duration between test order and test result.
Description Calculated duration between 'Diagnostic Test Ordered' and 'Diagnosis Confirmed' (or result received). Used for the 'Diagnostic Turnaround Time Overview'. Why it matters High turnaround times prolong Length of Stay; this metric pinpoints lab/radiology delays. Where to get Calculated: Timestamp(Result) - Timestamp(Order). Examples 2 hours45 minutes1.5 days
	Follow-up Appt Date FollowUpAppointmentDate	Date of the scheduled follow-up appointment.
Description Used to calculate the 'Follow-up Appt Scheduled Rate'. If this field is populated, it indicates a follow-up was scheduled. If null/empty, it was not. Why it matters Directly measures the 'Follow-up Care Compliance' KPI. Where to get Scheduling system or future appointments table linked to the patient. Consult Veradigm (Allscripts) documentation. Examples 2023-11-15T14:00:00Znull
	Is Protocol Compliant IsProtocolCompliant	Flag indicating if the case followed the standard care pathway.
Description A calculated attribute that checks if specific mandatory activities (e.g., 'Vitals Recorded' before 'Medication Administered') occurred in the correct order. Supports the 'Care Protocol Adherence Dashboard'. Why it matters Automates the detection of non-compliance without manual chart review. Where to get Calculated in the process mining tool or ETL based on activity sequence. Examples truefalse
	Last Data Update LastDataUpdate	Timestamp of when the record was last extracted or updated.
Description Indicates the freshness of the data used for analysis. This field helps users understand if they are looking at real-time data or a snapshot from a previous period. Why it matters Ensures transparency regarding data latency and assists in incremental data loading strategies. Where to get System generated timestamp during the ETL/extraction run. Examples 2023-11-01T23:59:59Z2023-11-02T06:00:00Z
	Medication Name MedicationName	The name of the drug ordered or administered.
Description Used specifically for the 'Medication Administration Time Gaps' dashboard. It helps identify if specific drugs (e.g., antibiotics, pain management) are experiencing administration delays. Why it matters Critical for clinical safety analysis and pharmacy process optimization. Where to get Medication Administration Record (MAR) or Pharmacy Orders. Consult Veradigm (Allscripts) documentation. Examples AmoxicillinHeparinMorphine Sulfate
	Order ID OrderId	Identifier for specific orders (Labs, Meds, Procedures).
Description Links the 'Order' event to the 'Result' or 'Administration' event. For example, linking 'Diagnostic Test Ordered' to 'Diagnostic Test Completed'. This granularity is required for the 'Diagnostic Turnaround Time' dashboard. Why it matters Enables the calculation of specific process steps' durations (e.g., Lab Turnaround Time). Where to get Order entry tables (e.g., ORDER_ID, PLACER_ORDER_NUM). Consult Veradigm (Allscripts) documentation. Examples ORD-998877LAB-112233RX-445566
	Source System SourceSystem	The name of the system where the data originated.
Description Identifies the software instance providing the data, such as 'Veradigm Sunrise' or 'Veradigm TouchWorks'. This is particularly important in multi-hospital environments or when merging data from acute and ambulatory settings. Why it matters Provides traceability and data lineage, which is useful when debugging data quality issues. Where to get Hardcoded during the ETL process or extracted from system metadata tables. Examples Veradigm SunriseAllscripts PMVeradigm TouchWorks

Required Recommended Optional

Patient Journey Activities

These are the key process steps and milestones to capture in your event log for accurate patient journey process discovery.

6 Recommended 7 Optional

	Activity	Description
	Diagnosis Confirmed	This activity signifies that a clinician has officially recorded a diagnosis in the patient's chart. This may be captured when a diagnosis code is added to the problem list or when a clinical note containing the diagnosis is signed.
Why it matters Confirming the diagnosis is a crucial turning point that dictates the subsequent treatment path. It allows for analysis of treatment pathway variations based on different diagnoses. Where to get Found in the patient's problem list, encounter diagnosis records, or clinical documentation. It can be inferred from the timestamp when a primary diagnosis code is entered and finalized for the encounter. Capture Use the creation or update timestamp of the primary diagnosis entry for the specific patient episode. Event type inferred
	Discharge Planning Initiated	Represents the formal start of the discharge planning process for a patient. This can be inferred from the creation of a discharge plan document, the placement of a discharge order, or the completion of a specific discharge planning assessment.
Why it matters This activity is the starting point for measuring the efficiency of the discharge process. Early initiation of planning is often correlated with lower readmission rates. Where to get Inferred from the creation timestamp of a discharge planning note, a discharge order set, or a specific assessment form within Veradigm. Capture Identify the timestamp when a discharge-specific order or document is first created for the patient's encounter. Event type inferred
	Initial Assessment Completed	Represents the completion of the first clinical evaluation by a nurse or physician, such as triage or initial intake. This is often captured when a specific clinical form or note, like a 'Nursing Initial Assessment', is signed and finalized in the EHR.
Why it matters This activity is a key early milestone. The time between registration and this assessment highlights potential delays in patient intake and initial care. Where to get Inferred from the finalization or signature timestamp of initial assessment forms or clinical notes within Veradigm's clinical documentation modules. Capture Identify the timestamp when the status of the initial assessment note or form is changed to 'completed' or 'signed'. Event type inferred
	Patient Discharged	Marks the official end of the inpatient episode, when the patient is formally discharged from the facility. This is an explicit, key event captured by the ADT system, which updates the patient's encounter status to 'discharged'.
Why it matters This is the primary end activity for most patient journeys. It is critical for calculating Average Length of Stay (ALOS) and overall process cycle time. Where to get Explicitly logged in the ADT module. The patient encounter record will have a discharge timestamp and disposition. Capture Use the discharge timestamp from the patient's main encounter or visit record. Event type explicit
	Patient Registered	Marks the official start of the patient episode when the patient's information is entered into the Veradigm system. This event is typically captured explicitly when a user completes the registration workflow, creating a new patient encounter record with a unique identifier and timestamp.
Why it matters This is the primary start activity for the patient journey. It is essential for calculating overall process cycle time, length of stay, and patient throughput rates. Where to get This event is recorded in the patient registration or ADT (Admission, Discharge, Transfer) module. Look for the creation timestamp of the patient encounter or visit record. Capture Timestamp from the patient encounter or registration table upon record creation. Event type explicit
	Treatment Plan Created	Represents the formalization of a patient's treatment plan by the clinical team. This is often captured when a specific 'Plan of Care' document or a set of initial treatment orders is created and signed in the EHR.
Why it matters This milestone initiates the active treatment phase. It is the baseline for measuring adherence to care protocols and the time to first treatment action, like medication administration. Where to get Inferred from the signature timestamp on a 'Plan of Care' form or the creation timestamp of the first major set of therapeutic orders following diagnosis. Capture Find the timestamp when a 'Plan of Care' document is finalized or signed by the attending clinician. Event type inferred
	Diagnostic Test Completed	Represents the point at which the results of a diagnostic test are finalized and made available in the patient's record. This is typically inferred from a status change on the original order from 'active' or 'in-progress' to 'completed' or 'resulted'.
Why it matters This activity is a critical milestone for measuring diagnostic turnaround times. Delays between ordering and completion can significantly impact the time to diagnosis. Where to get Inferred from the order status field in the orders module or from timestamps in the corresponding results module, like LIS or RIS. Capture Identify the timestamp when the order status changes to a terminal state like 'Completed' or 'Resulted'. Event type inferred
	Diagnostic Test Ordered	This event occurs when a clinician places an order for a diagnostic test, such as a lab test or imaging scan. It is captured explicitly through the Computerized Physician Order Entry (CPOE) system within Veradigm.
Why it matters This marks the beginning of the diagnostic sub-process. It is the starting point for measuring diagnostic turnaround times and identifying delays in ordering procedures. Where to get Recorded in the orders module or CPOE system logs. Each order will have a timestamp indicating when it was placed. Capture Extract the creation timestamp from the order entry records for relevant diagnostic tests. Event type explicit
	Follow-up Scheduled	This activity represents the scheduling of a follow-up appointment for the patient after discharge. This event is captured in the scheduling module when an appointment is booked that is linked to the discharged encounter.
Why it matters Ensuring follow-up care is scheduled is crucial for continuity of care and reducing readmissions. This activity helps measure compliance with post-discharge protocols. Where to get Recorded in the appointment scheduling module. Look for the creation timestamp of a new appointment for the patient that occurs after the discharge date. Capture Identify the creation timestamp of an appointment record in the scheduling system linked to the patient. Event type explicit
	Medication Administered	This event is recorded when a nurse or clinician documents the administration of a medication to the patient. This is captured in the Medication Administration Record (MAR) or eMAR module, which logs the exact time of administration.
Why it matters Tracking medication administration is vital for analyzing treatment timeliness and adherence. The gap between ordering and administration helps identify delays in the medication delivery process. Where to get Explicitly logged in the eMAR (electronic Medication Administration Record) module. Each administration event has a specific timestamp, medication, and dosage. Capture Extract timestamps from the eMAR table for each medication administration event linked to the patient encounter. Event type explicit
	Procedure Performed	Represents the completion of a clinical or surgical procedure. This is typically captured when a clinician signs the procedure note or when the status of the procedure order is updated to 'completed' in the system.
Why it matters Procedures are significant milestones in many patient journeys. Analyzing their timing helps understand resource utilization and scheduling efficiency. Where to get Inferred from the signature timestamp of a procedure note in the clinical documentation module or the completion timestamp in the orders module for that procedure. Capture Use the completion timestamp from the procedure order or the signature timestamp from the related procedure documentation. Event type inferred
	Transfer to Department	This event marks the physical transfer of a patient from one department or care unit to another, such as from the ER to an inpatient ward. This is captured by the ADT (Admission, Discharge, Transfer) system within Veradigm.
Why it matters Patient transfers are common points for bottlenecks and delays. Analyzing the duration and frequency of transfers helps optimize patient flow and resource allocation between departments. Where to get Explicitly logged in the ADT module. Each transfer event includes the patient, from/to locations, and a timestamp. Capture Extract event logs from the ADT system corresponding to patient movements. Event type explicit
	Vitals Recorded	This activity occurs each time a patient's vital signs, such as heart rate, blood pressure, and temperature, are recorded. This is an explicit event captured in the clinical documentation or vitals-specific flowsheet section of the EHR.
Why it matters Frequent recording of vitals indicates active patient monitoring. The frequency and timing can be analyzed to ensure compliance with monitoring protocols. Where to get Recorded in the clinical data repository or flowsheet tables where vital signs are stored. Each entry has a timestamp. Capture Extract timestamps from the vital signs flowsheet data for the patient encounter. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from Veradigm (Allscripts)

Steps

Identify the Target Interface Channel: Log in to the Allscripts Interface Engine (AIE) Management Console. Locate the primary interface channel processing inbound messages from the EHR (typically labeled 'EHR_Inbound' or similar). Ensure this channel handles ADT, SIU, ORM, ORU, RAS, and DFT message types to capture the full scope of patient journey activities.
Create a New Passthrough/Export Channel: Create a new destination channel named 'ProcessMining_Export'. Set the output type to 'File Writer'. This channel will receive a copy of the messages from the source channel and transform them into a flat file format (CSV) for ProcessMind.
Configure Message Routing: In the AIE routing rules, configure a copy/route rule to send messages from the primary EHR channel to the new 'ProcessMining_Export' channel. Filter the routing to include only the necessary message types: ADT (Registration/Transfer), SIU (Scheduling), ORM (Orders), ORU (Results/Vitals), RAS (Meds), and DFT (Billing/Procedures).
Define the Transformation Logic: Within the 'ProcessMining_Export' channel, open the Transformation/Script editor. You must implement a parsing script (see the 'query' section below) that reads the raw HL7 segments and maps specific Trigger Events and Status codes to the standard Activity Names required (e.g., mapping 'ADT^A01' to 'Patient Registered').
Map Attributes to HL7 Fields: Ensure the script extracts the 'PatientEpisodeId' from the PV1-19 segment (Visit Number) and 'PatientMrn' from PID-3. Map the 'EventDateTime' to MSH-7 or EVN-2. Extract clinical details like 'DepartmentName' from PV1-3 and 'AttendingProvider' from PV1-7.
Set Output File Parameters: Configure the File Writer settings. Set the output directory to a secure network path. Define the file naming convention (e.g., EventLog_YYYYMMDD_HH.csv). Set the file mode to 'Append' to continuously add rows to the log.
Handle Delimiters and Escaping: In the script, ensure that text fields (like Diagnosis or Department Name) are sanitized to remove commas or newlines to prevent breaking the CSV structure.
Activate and Test: Start the 'ProcessMining_Export' channel. Trigger a test event in the Veradigm test environment (e.g., register a test patient). Verify that a new row appears in the CSV file with the correct Activity Name and timestamp.
Configure Log Rotation: Set up a rotation schedule (e.g., daily at midnight) to close the current CSV file and start a new one. This ensures files are manageable in size for upload.
Historical Data Replay (Optional): If historical data is required, use the AIE 'Message Browser' or 'Log Replay' tool to resend archived HL7 logs from the past 3-6 months through the 'ProcessMining_Export' channel. Monitor system performance to avoid lag.
Retrieve and Format: Access the output directory, retrieve the generated CSV files, and verify headers match the requirement. Combine daily files if necessary.
Upload to ProcessMind: Import the final dataset into ProcessMind, mapping 'PatientEpisodeId' as the Case ID, 'ActivityName' as the Activity, and 'EventDateTime' as the Timestamp.

Configuration

Channel Type: File Writer / File System Output
Trigger Events: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
File Encoding: UTF-8 (Critical for special characters in names/diagnoses)
Delimiter: Comma (,) or Pipe (|)
Date Format: ISO 8601 (YYYY-MM-DDTHH:MM:SS) recommended for HL7 timestamp conversion
Log Rotation: Daily or when file size exceeds 100MB
Write Mode: Append (Do not overwrite)
Performance: Ensure the transformation script is lightweight to prevent message queuing/backlog in the engine.

a Sample Query config

// AIE Transformation Script (Pseudo-code for Config)
// Objective: Parse HL7 message and append line to CSV
// Output Columns: PatientEpisodeId, ActivityName, EventDateTime, PatientMrn, AttendingProvider, DepartmentName, PrimaryDiagnosisCode

// 1. Initialize Variables
var msgType = HL7.GetField("MSH-9-1") + "^" + HL7.GetField("MSH-9-2");
var visitNumber = HL7.GetField("PV1-19");
var mrn = HL7.GetField("PID-3");
var eventTime = HL7.GetField("MSH-7"); // Or EVN-2
var provider = HL7.GetField("PV1-7");
var dept = HL7.GetField("PV1-3");
var diagnosis = HL7.GetField("DG1-3"); // For Diagnosis events
var orderStatus = HL7.GetField("ORC-5");
var resultStatus = HL7.GetField("OBR-25");
var activityName = "";

// 2. Map Message Types to Activities
// Registration & Admission
if (msgType == "ADT^A04" || msgType == "ADT^A01") {
    activityName = "Patient Registered";
}
else if (msgType == "ADT^A02") {
    activityName = "Transfer to Department";
}
else if (msgType == "ADT^A03") {
    activityName = "Patient Discharged";
}
// Scheduling
else if (msgType == "SIU^S12") {
    activityName = "Follow-up Scheduled";
}
// Orders (Diagnostics, Care Plans, Discharge Planning)
else if (msgType == "ORM^O01") {
    var orderControl = HL7.GetField("ORC-1");
    var orderType = HL7.GetField("OBR-4"); // Check for specific service codes
    
    if (orderControl == "NW") { // New Order
        if (orderType.Contains("LAB") || orderType.Contains("RAD")) {
            activityName = "Diagnostic Test Ordered";
        }
        else if (orderType.Contains("DISCHARGE")) {
            activityName = "Discharge Planning Initiated";
        }
        else if (orderType.Contains("CARE_PLAN")) {
            activityName = "Treatment Plan Created";
        }
    }
}
// Results & Vitals
else if (msgType == "ORU^R01") {
    // Check if it is Vitals or Lab Result based on OBX codes or sending app
    var observationId = HL7.GetField("OBX-3"); 
    if (observationId.Contains("VITALS")) {
        activityName = "Vitals Recorded";
    } else {
        if (resultStatus == "F" || resultStatus == "C") {
            activityName = "Diagnostic Test Completed";
        }
    }
    
    // Initial Assessment Check (often a specific doc type in ORU or MDM)
    if (observationId.Contains("INITIAL_ASSESS")) {
        activityName = "Initial Assessment Completed";
    }
}
// Medication Administration (RAS)
else if (msgType == "RAS^O17") {
    activityName = "Medication Administered";
}
// Billing/Procedures (DFT)
else if (msgType == "DFT^P03") {
    activityName = "Procedure Performed";
}
// Diagnosis Updates (Often in ADT or DFT, logic depends on config)
else if (msgType == "ADT^A08" && diagnosis != "") {
    // Check if diagnosis segment is new/updated
    activityName = "Diagnosis Confirmed";
}

// 3. Write to File if Activity Identified
if (activityName != "" && visitNumber != "") {
    // Format Date to ISO
    var formattedDate = FormatDate(eventTime, "yyyy-MM-dd HH:mm:ss");
    
    // Construct CSV Line
    var csvLine = visitNumber + "," + 
                  activityName + "," + 
                  formattedDate + "," + 
                  mrn + "," + 
                  provider + "," + 
                  dept + "," + 
                  diagnosis;
                  
    File.WriteLine("[Configured_Output_Path]\\PatientJourneyLog.csv", csvLine);
}

Steps

Prerequisites and Access: Ensure you have valid credentials for the Veradigm (Allscripts) Unity API. You will need an Appname (Application Name) authorized for your organization, along with a valid UserID and Password (or token) for authentication. Verify that the user account has permissions to access clinical domains (Encounters, Orders, Results, Vitals, Problems).
Environment Setup: Install Python 3.8 or higher. Install the necessary libraries using pip: pip install requests pandas. These will be used for making HTTP requests to the Unity API and manipulating the resulting data.
Configuration: Open the provided Python script. Locate the CONFIGURATION section at the top. Update the API_URL to point to your specific Unity environment endpoint (e.g., unity.veradigm.com or an internal gateway). Replace the placeholder credentials ([YourAppName], [YourUserID], etc.) with your actual credentials. Set the START_DATE and END_DATE to your desired analysis window.
Script Logic Overview: The script functions by first authenticating with the API to obtain a security token. It then calls GetEncounterInfo to retrieve all patient episodes within the specified date range. This list of encounters serves as the central iterator for the extraction.
Activity Extraction Loop: For each identified EncounterID, the script performs secondary API calls to specialized endpoints. It calls GetOrders to find diagnostic tests and procedures. It calls GetResults to identify completed tests. It calls GetVitals for vital sign recordings. It calls GetPatientProblems for confirmed diagnoses. It iterates through clinical notes to find assessments and treatment plans.
Data Transformation: As raw JSON data is returned from the API, the script parses specific fields to map them to the ProcessMind schema. For example, OrderDateTime is mapped to EventDateTime for the 'Diagnostic Test Ordered' activity. The script ensures that the PatientEpisodeId (Encounter ID) is consistently applied to all child records.
Handling ADT and Transfers: The script logic includes a check against the encounter's location history (if available via specific Audit or ADT sub-calls) or infers transfers based on department changes in clinical documentation to generate 'Transfer to Department' events.
Follow-up Logic: After processing the encounter, the script queries GetSchedule for the same PatientID looking for appointment dates that occur after the DischargeDate to generate the 'Follow-up Scheduled' activity.
Validation: The script includes a local validation step that prints the count of rows per activity type to the console. Review this output to ensure no activity types have zero records (unless expected).
Export: The final dataset is aggregated into a Pandas DataFrame. The script calculates derived attributes like LengthOfStay and IsReadmission by sorting the data by Patient and Time. Finally, it exports the clean event log to a CSV file named veradigm_patient_journey_log.csv.
Final Review: Open the generated CSV file. Check that date formats are ISO 8601 (YYYY-MM-DD HH:MM:SS) and that text fields like ActivityName do not contain delimiter characters.
Upload: Import the CSV file into ProcessMind. Map PatientEpisodeId to Case ID, ActivityName to Activity, and EventDateTime to Timestamp.

Configuration

API_URL: The base URL for the Unity API services. This varies by client installation (e.g., on-premise vs. cloud). Ensure protocol (https) is correct.
Appname: The unique application identifier registered with Veradigm/Allscripts. This controls the scope of data access.
Date Range: Recommended extraction window is 3-6 months. Large ranges may timeout; consider chunking by month if volume is high.
Timeout Settings: The script uses a default timeout of 30 seconds for API calls. Increase this if the EHR system is under heavy load.
Batching: The script iterates per encounter. For high-volume systems, modifying the script to fetch data in bulk (if endpoints allow) or running parallel threads may be necessary.
Mapping Logic: The script maps 'OrderType' to activities. Ensure your system's specific order type codes (e.g., 'Lab', 'Rad') align with the logic in the process_orders function.

a Sample Query python

import requests
import pandas as pd
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
API_URL = class="hl-string">"https://unity.veradigm.com/[YourEnvironment]/unity/unityservice.svc/json"
APP_NAME = class="hl-string">"[YourAppName]"
USER_ID = class="hl-string">"[YourUserID]"
PASSWORD = class="hl-string">"[YourPassword]"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
OUTPUT_FILE = class="hl-string">"veradigm_patient_journey_log.csv"

class=class="hl-string">"hl-comment"># Global Session Token
TOKEN = None

def get_security_token():
    class="hl-string">"""Authenticate and retrieve security token."""
    payload = {
        class="hl-string">"Action": class="hl-string">"GetToken",
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Username": USER_ID,
        class="hl-string">"Password": PASSWORD
    }
    try:
        response = requests.post(API_URL, json=payload)
        response.raise_for_status()
        data = response.json()
        class=class="hl-string">"hl-comment"># Depending on Unity version, token might be in body or header. Assuming body here.
        return data[0][class="hl-string">'Token'] if isinstance(data, list) else data.get(class="hl-string">'Token')
    except Exception as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return None

def make_unity_request(action, params):
    class="hl-string">"""Wrapper for Unity API calls."""
    payload = {
        class="hl-string">"Action": action,
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Token": TOKEN
    }
    payload.update(params)
    
    try:
        response = requests.post(API_URL, json=payload, timeout=30)
        response.raise_for_status()
        class=class="hl-string">"hl-comment"># Unity often returns a list of dictionaries
        return response.json()
    except Exception as e:
        print(fclass="hl-string">"API Call Error ({action}): {e}")
        return []

def extract_patient_journey():
    global TOKEN
    TOKEN = get_security_token()
    if not TOKEN:
        return

    print(class="hl-string">"Token acquired. Starting extraction...")
    
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Get Encounters within Date Range
    class=class="hl-string">"hl-comment"># Using GetEncounterInfo or similar search action
    encounters = make_unity_request(class="hl-string">"GetEncounterInfo", {
        class="hl-string">"StartEncounterDate": START_DATE,
        class="hl-string">"EndEncounterDate": END_DATE
    })

    print(fclass="hl-string">"Found {len(encounters)} encounters. Processing details...")

    for enc in encounters:
        try:
            class=class="hl-string">"hl-comment"># Basic Encounter Data
            episode_id = str(enc.get(class="hl-string">'EncounterID'))
            patient_id = enc.get(class="hl-string">'PatientID')
            mrn = enc.get(class="hl-string">'MRN', class="hl-string">'')
            admit_time = enc.get(class="hl-string">'EncounterDate') class=class="hl-string">"hl-comment"># ISO string expected
            discharge_time = enc.get(class="hl-string">'DischargeDate')
            dept_name = enc.get(class="hl-string">'Department', class="hl-string">'General')
            attending = enc.get(class="hl-string">'ProviderName', class="hl-string">'Unknown')
            
            class=class="hl-string">"hl-comment"># --- Activity: Patient Registered ---
            if admit_time:
                event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Registered",
                    class="hl-string">"EventDateTime": admit_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># --- Activity: Patient Discharged ---
            if discharge_time:
                 event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Discharged",
                    class="hl-string">"EventDateTime": discharge_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># 2. Get Orders (Labs, Procedures, Consults)
            orders = make_unity_request(class="hl-string">"GetOrders", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for order in orders:
                order_time = order.get(class="hl-string">'OrderDate')
                order_type = order.get(class="hl-string">'OrderType', class="hl-string">'').lower()
                order_name = order.get(class="hl-string">'OrderName', class="hl-string">'Unknown Order')
                
                class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Ordered ---
                if class="hl-string">'lab' in order_type or class="hl-string">'imaging' in order_type or class="hl-string">'radiology' in order_type:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Ordered",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_OrderName": order_name
                    })

                class=class="hl-string">"hl-comment"># --- Activity: Procedure Performed ---
                class=class="hl-string">"hl-comment"># Often procedures are orders with status completed or specific types
                if class="hl-string">'procedure' in order_type and order.get(class="hl-string">'Status') == class="hl-string">'Completed':
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Procedure Performed",
                        class="hl-string">"EventDateTime": order.get(class="hl-string">'CompletionDate', order_time),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ProcedureName": order_name
                    })
                    
                class=class="hl-string">"hl-comment"># --- Activity: Discharge Planning Initiated ---
                if class="hl-string">'discharge' in order_name.lower():
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Discharge Planning Initiated",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 3. Get Results (Lab completion)
            results = make_unity_request(class="hl-string">"GetResults", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for res in results:
                result_time = res.get(class="hl-string">'ResultDate')
                if result_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Completed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Completed",
                        class="hl-string">"EventDateTime": result_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ResultName": res.get(class="hl-string">'TestName', class="hl-string">'Unknown Test')
                    })

            class=class="hl-string">"hl-comment"># 4. Get Problems (Diagnosis)
            problems = make_unity_request(class="hl-string">"GetPatientProblems", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for prob in problems:
                onset_date = prob.get(class="hl-string">'OnsetDate') or prob.get(class="hl-string">'DateEntered')
                if onset_date:
                     class=class="hl-string">"hl-comment"># --- Activity: Diagnosis Confirmed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnosis Confirmed",
                        class="hl-string">"EventDateTime": onset_date,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"PrimaryDiagnosisCode": prob.get(class="hl-string">'ICD10', class="hl-string">''),
                        class="hl-string">"Attribute_DiagnosisName": prob.get(class="hl-string">'ProblemDescription', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 5. Get Vitals
            vitals = make_unity_request(class="hl-string">"GetVitals", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for vit in vitals:
                taken_time = vit.get(class="hl-string">'DateTaken')
                if taken_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Vitals Recorded ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Vitals Recorded",
                        class="hl-string">"EventDateTime": taken_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 6. Get Clinical Notes (Assessments, Plans)
            class=class="hl-string">"hl-comment"># Sometimes accessed via GetNoteInfo or GetChart
            notes = make_unity_request(class="hl-string">"GetNoteInfo", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for note in notes:
                note_date = note.get(class="hl-string">'NoteDate')
                note_title = note.get(class="hl-string">'DocumentType', class="hl-string">'').lower()
                
                class=class="hl-string">"hl-comment"># --- Activity: Initial Assessment Completed ---
                if class="hl-string">'initial' in note_title or class="hl-string">'assessment' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Initial Assessment Completed",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })
                
                class=class="hl-string">"hl-comment"># --- Activity: Treatment Plan Created ---
                if class="hl-string">'plan' in note_title or class="hl-string">'care' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Treatment Plan Created",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 7. Med Administration (GetMedicationAdministration or inferred from Med History)
            meds = make_unity_request(class="hl-string">"GetMedicationAdministration", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for med in meds:
                admin_time = med.get(class="hl-string">'AdministrationDate')
                if admin_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Medication Administered ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Medication Administered",
                        class="hl-string">"EventDateTime": admin_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_MedicationName": med.get(class="hl-string">'MedicationName', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 8. Transfer Events (Infer from ADT or Audit log)
            class=class="hl-string">"hl-comment"># Simulating transfer extraction via AuditLog for Location changes
            audit_logs = make_unity_request(class="hl-string">"GetAuditLog", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for log in audit_logs:
                if class="hl-string">"Transfer" in log.get(class="hl-string">'EventName', class="hl-string">'') or class="hl-string">"Location Change" in log.get(class="hl-string">'EventName', class="hl-string">''):
                     class=class="hl-string">"hl-comment"># --- Activity: Transfer to Department ---
                     event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Transfer to Department",
                        class="hl-string">"EventDateTime": log.get(class="hl-string">'EventDate'),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"DepartmentName": log.get(class="hl-string">'NewValue', class="hl-string">'Unknown Dept')
                     })

            class=class="hl-string">"hl-comment"># 9. Follow-up Scheduled
            if discharge_time:
                future_appts = make_unity_request(class="hl-string">"GetSchedule", {class="hl-string">"PatientID": patient_id, class="hl-string">"StartDate": discharge_time})
                for appt in future_appts:
                    class=class="hl-string">"hl-comment"># --- Activity: Follow-up Scheduled ---
                    class=class="hl-string">"hl-comment"># Note: We want the time the appt was BOOKED, but Unity usually gives ApptDate.
                    class=class="hl-string">"hl-comment"># We will use the creation date of the appt if available, otherwise ApptDate as proxy
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Follow-up Scheduled",
                        class="hl-string">"EventDateTime": appt.get(class="hl-string">'DateBooked', appt.get(class="hl-string">'ApptDate')), 
                        class="hl-string">"PatientMrn": mrn
                    })

        except Exception as e:
            print(fclass="hl-string">"Error processing encounter {enc.get('EncounterID')}: {e}")
            continue

    class=class="hl-string">"hl-comment"># Post-Processing: Create DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Helper: Convert strings to datetime
    df[class="hl-string">'EventDateTime'] = pd.to_datetime(df[class="hl-string">'EventDateTime'], errors=class="hl-string">'coerce')
    df = df.dropna(subset=[class="hl-string">'EventDateTime', class="hl-string">'PatientEpisodeId'])
    
    class=class="hl-string">"hl-comment"># Calculate LOS and Readmission
    df[class="hl-string">'AdmissionDate'] = pd.to_datetime(df[class="hl-string">'AdmissionDate'], errors=class="hl-string">'coerce')
    df[class="hl-string">'DischargeDate'] = pd.to_datetime(df[class="hl-string">'DischargeDate'], errors=class="hl-string">'coerce')
    
    class=class="hl-string">"hl-comment"># LOS
    df[class="hl-string">'LengthOfStay'] = (df[class="hl-string">'DischargeDate'] - df[class="hl-string">'AdmissionDate']).dt.days

    class=class="hl-string">"hl-comment"># IsReadmission (Simplified: check if patient had previous discharge within 30 days)
    class=class="hl-string">"hl-comment"># Requires sorting by patient and admission time first
    class=class="hl-string">"hl-comment"># This is complex in a flat event log context, simplified here as placeholder logic
    df[class="hl-string">'IsReadmission'] = False 

    print(fclass="hl-string">"Extraction complete. Rows: {len(df)}")
    df.to_csv(OUTPUT_FILE, index=False)
    print(fclass="hl-string">"Data saved to {OUTPUT_FILE}")

if __name__ == class="hl-string">"__main__":
    extract_patient_journey()

Your Patient Journey Data Template

Your Patient Journey Data Template

Patient Journey Attributes

Patient Journey Activities

Extraction Guides

Allscripts Interface Engine Event Log Export

Steps

Configuration

a Sample Query config

Veradigm Unity API Extraction via Python

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize Patient Journeys in Veradigm Today

Your Patient Journey Data Template

Your Patient Journey Data Template

Patient Journey Attributes

Patient Journey Activities

Extraction Guides

Allscripts Interface Engine Event Log Export

Steps

Configuration

a Sample Query config

Veradigm Unity API Extraction via Python

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Optimize Patient Journeys in Veradigm Today