Visual Workflows, Clinical Reporting

Praveendhra Rajkumar  |  Report Writer /Applications Developer Work Sample
← Back to Work Sample
Epic Report Development Lifecycle
End-to-end flow from a clinical department's data question to a validated, deployed Reporting Workbench template or Slicer Dicer data model, including stakeholder checkpoints that prevent scope creep and rework.
Trigger
Process step
Decision
Milestone / sign-off
Completion
Clinical Department Request
Submitted via ServiceNow intake form: business question, urgency, site, recipients
Analyst Triage (Day 1-2)
Classify: Standard, New Build, Self-Service Redirect, or Defer. Set delivery date.
Can Slicer Dicer answer this?
Is this a routine ad-hoc lookup that a curated data model can handle?
Yes
Route to Slicer Dicer
Provide saved filter or train super-user. Log as deflected request.
Self-Service Resolution
No
Spec Meeting (Day 3-5)
Define filters, date anchor, groupers, output format, CC site scope, and recipients
Written Spec Sign-off
Requester approves spec document before development begins
Build in Reporting Workbench
Select master file (INI), add criteria filters, configure groupers, set output columns
3-Step QA Validation
Spec check, cross-reference against source, edge-case testing
Requester UAT Sign-off
Department validates output against known data before go-live
Deploy to Shared Template Folder
Add to report registry: ID, Chronicles sources, spec sheet, retention schedule
Report Live + Documented
Note: For recurring reports, the deployed template is also registered with Report Broker for scheduled automated delivery. The spec sheet includes the delivery schedule, recipients, and SFTP/SharePoint destination path.
Data Validation Flow
Three-step QA gate that every Reporting Workbench output must pass before delivery. Designed to catch filter errors, date anchor mismatches, and Community Connect data bleed before they reach clinical decision-makers.
Trigger / start
Process step
Decision point
Success / pass
Failure / error
Info / log
Milestone / sign-off
Completion
Report Build Complete
Reporting Workbench template saved. Ready for validation.
Step 1: Spec Validation
Compare output to manually verified source records for 20-50 patients. Verify denominator matches expected population.
Denominator matches spec?
No
Audit Criteria Filters
Check date anchor, Department ID filter, and value list definitions. Revise template.
Return to Build
Fix identified filter issue. Re-run from Step 1.
Yes
Step 1 Passed
Step 2: Cross-Reference Check
Run the same population through an independent source (legacy report or direct Chronicles lookup). Compare counts.
Variance under 0.5%?
Step 2 Passed
Step 3: Edge-Case Testing
Run at go-live date boundary and 1-day window. Verify CC site filter excludes host-site records.
All edge cases clean?
Validation Complete
QA checklist signed. Proceed to requester UAT.
Report Cleared for Delivery
Template deployed + spec documentation archived in SharePoint registry
Python QA script runs after every automated Report Broker job: counts rows in output CSV, compares to prior-month baseline, flags deviations over 15%, and logs results to SharePoint tracking sheet. Catches truncated files and missed filter conditions before reports reach clinical leaders.
Request and Change Management Lifecycle
How a report request travels from department submission through prioritization, development, and production deployment, with explicit stakeholder checkpoints that prevent scope creep and ensure delivery commitments are met.
Trigger / start
Process step
Decision point
Success / redirect
Info / deferred
Milestone / sign-off
Completion
Request Submitted
ServiceNow form: department, site, business question, urgency, frequency, intended recipients
Auto-Acknowledgment (Same Day)
Requester receives confirmation email with ticket number and expected triage window (2 business days)
Analyst Triage (Day 1-2)
Classify request type. Estimate effort. Assign to analyst. Set committed delivery date.
Request type?
Self-Service
Redirect to Slicer Dicer
Send guide + offer training. Log deflection. Close ticket.
Standard
Configure Existing Template
Apply site filters, adjust date range, validate output. Deliver.
New Build
Spec Meeting Scheduled
Define filters, date anchor, groupers, PHI scope, CC site, recipients
Written Spec Sign-off
Build + QA
3-step validation. Get approval before UAT.
UAT Sign-off
Defer
Defer with Explanation
Communicate timeline, constraints, or re-prioritization rationale to requester
Deploy to Production
Template added to shared folder. Registered in SharePoint report registry. Recurring reports configured in Report Broker.
Ticket Closed + Documented
Requester receives delivery confirmation. Spec sheet and Chronicles source archived.
21-day alert: Any open ticket without an update after 21 days triggers an automated alert to the assigned analyst and the analytics manager. Prevents unacknowledged requests from aging silently.
Incident Response + Root Cause Analysis
Detection-to-resolution flow for the ED throughput metric discrepancy, a 12% variance across three Radar dashboards caused by inconsistent date anchors. This flow generalizes to any data quality incident in the reporting environment.
Anomaly / failure detected
Investigation / process step
Key finding / callout
Stakeholder sign-off
Incident closed
Anomaly Detected
QI director flags 12% ED visit count variance between two Radar dashboards for the same month and similar-volume sites
Scope the Incident
How many dashboards affected? Which date range? Which sites? How many patients impacted?
Finding: 3 dashboards, 2 months of data, 214 affected encounters
Variance = encounters that opened in late June and closed in early July (month-boundary straddle)
Retrieve Underlying Template IDs
Pull template IDs from each Radar component configuration. Open in Reporting Workbench.
Side-by-Side Criteria Comparison
Compare all filter definitions across 3 templates. Look for field ID differences in date criteria.
Root Cause Identified
Dashboard A: PAT ENC 12060 (Arrival DT). Dashboard B: PAT ENC 18520 (Close DT). Dashboard C: HAR field (Check-in DT). Three different anchors, three different counts.
Confirm Fix with Clinical Stakeholder
Confirm with ED informatics lead that Arrival DT (PAT ENC 12060) is the clinically correct anchor for operational throughput metrics
Apply Fix to All 3 Templates
Update date anchor to PAT ENC 12060 across all 3 RWB templates. Add description field annotation documenting the standard.
Validate and Deploy
Re-run 3-step QA. Confirm metrics align within 0.1% residual variance. Deploy updated templates.
Stakeholder Communication Sent
Written summary to QI team: what happened, why, what changed, and confirmation that historical data was not altered. QI director sign-off within 48 hours.
Prevention Measures Added
"Date anchor field" added as required column in all future spec documentation. Cross-reference validation added to QA checklist for all new builds.
Incident Closed
Total resolution time: 48 hours from detection to stakeholder sign-off
Timeline: Anomaly reported Monday AM. Root cause confirmed Monday PM (4 hours). Fix deployed Tuesday AM. Stakeholder confirmation Tuesday PM. Spec template updated Wednesday. Total elapsed: 48 hours.
Automated Report Distribution
How recurring reports flow from Epic Report Broker through the validation layer to secure delivery, replacing 18 hours of monthly manual analyst effort with a fully automated, audited pipeline.
Trigger / start
Process step
Decision point
Validation passed
Failure / alert
Manual fallback step
Analyst review gate
Completion
Report Broker Trigger
Scheduled job fires on the 1st of each month at 06:00 AM. Targets all 8 HEDIS quality report templates.
Reporting Workbench Templates Execute
Epic runs each template against Chronicles. Applies date range, site filters, and CC Department ID restrictions.
All templates completed successfully?
No
Failure Alert Sent
Report Broker emails analytics-team with template name, error code, and timestamp
Analyst Investigation
Check Epic system status, template configuration, and Chronicle connection. Escalate to Epic technical team if needed.
Manual Re-run After Fix
Yes
Output Written to SFTP / SharePoint
CSV files saved to secure landing zone. Filename includes measure code, YYYYMM, and row count: DM-20260501-4821.csv
Python QA Script Runs
Counts rows in each output file. Compares to prior-month baseline. Flags deviations over 15%. Logs to SharePoint tracking row.
All row counts within 15% of baseline?
Validation Passed
Delivery Notification Sent
QI coordinator and analytics manager receive email with links to reports, run timestamp, and row counts
Analyst Reviews Exceptions Only
If QA flagged any deviation: analyst investigates before QI team uses the data. Target: under 30 minutes of analyst time per month.
Monthly Reports Delivered
All 8 HEDIS quality reports available in SharePoint by the 2nd of each month. Analyst manual time: 18 hrs reduced to <30 min exception review.
Secondary automation: A Radar burst report emails daily ED throughput summaries (visit counts, door-to-provider time by site) to ED medical directors each morning at 7 AM, no analyst involvement after initial configuration.