Executive Summary
Meridian Community Health Alliance (fictional), a five-site Community Connect spoke on a regional health system's Epic installation, entered its second post-go-live year with 340 unresolved report requests, inconsistent ED throughput metrics across three operational dashboards, and monthly quality reporting consuming 18 analyst-hours per cycle.
This proposal outlines how I would assess the current reporting environment, redesign the request workflow, build standardized Reporting Workbench templates and Radar dashboards, enable self-service analytics through Slicer Dicer, and automate recurring report distribution. The target outcome: reduce time-to-delivery by 4x, cut manual monthly reporting effort to under 4 hours, and surface a self-service analytics tier that deflects 30% of ad-hoc requests within 6 months.
Scenario
Organization: Meridian Community Health Alliance (fictional composite of a real Community Connect spoke environment)
Epic Environment
Community Connect spoke on Northeast Regional Health System's Epic production. Ambulatory, Emergency, Orders, ClinDoc, and MyChart active.
Scale
5 community health centers. 120,000 active patients. 85,000 encounters/year. 40+ clinical departments with reporting needs.
Team
2 report writers (one vacancy), 3 clinical application analysts, 1 analytics manager. 18 months post go-live.
Quality Obligations
8 HEDIS-aligned quality measures required for payer contracts. Reported monthly to QI team and quarterly to payers.
Current State Assessment
What's broken
| Problem | Evidence | Impact |
|---|---|---|
| 340 outstanding report requests | ServiceNow aging report: 60% unactioned for 60+ days | Clinical leadership lacks operational data |
| Metric inconsistency across dashboards | ED throughput in 3 Radar dashboards uses 3 different date anchors | QI team cannot compare sites accurately |
| Manual monthly reporting | QI coordinator spends 18 hrs/month on 8 quality reports | High error risk, slow feedback cycle |
| No self-service analytics tier | Every data question routes to analyst queue | Analyst time consumed by simple lookups |
| Missing spec documentation | Report templates lack data dictionary or Chronicles source annotations | Cannot maintain or hand off reports |
| Community Connect data bleed | 2 dashboards missing Department ID filters, pulling host-site data | Reports show inflated patient volumes |
Root cause
The implementation team prioritized go-live speed over governance. Reports were built to satisfy individual department requests without a template library, naming convention, or spec documentation standard. The result is a fragmented, unmaintainable reporting environment with no single source of truth and no intake process that sets or honors delivery commitments.
Proposed Solution
Four parallel tracks, starting from day one and reaching steady state by month three.
Track 1: Triage the Backlog
Classify all 340 requests: Standard (template exists), New Build, Self-Service Redirect, or Defer. Expected result: 30-40% resolved or redirected in 30 days.
Track 2: Fix Dashboard Data Quality
Audit 3 ED Radar dashboards. Standardize all ED timing to Arrival DT. Add CC site Department ID filters to all multi-site views.
Track 3: Standard Template Library
Build 12 core Reporting Workbench templates covering ED, ambulatory quality, population health, and access. Each gets a documented spec sheet.
Track 4: Automate Recurring Reports
Configure Report Broker for all 8 monthly quality reports. Output to secure SharePoint. Cut monthly analyst time from 18 hours to under 4 hours.
Workflow redesign
- Intake form, Standardized SharePoint/ServiceNow form captures: requester, department, site, business question, urgency, output format, and distribution recipients.
- Triage within 2 days, Analyst classifies request, estimates effort, and sets an expected delivery date with requester acknowledgment.
- Spec meeting, Confirm filters, groupers, output format, and recipients. Requester signs off on written spec before development begins.
- Build and QA, 3-step validation: spec check, cross-reference against source data, edge-case testing.
- UAT with requester, Department validates output against known data before go-live.
- Deploy and document, Add template to shared report registry with Chronicles source annotations. Archive spec sheet.
Security and HIPAA Compliance
Every reporting artifact I build is designed with HIPAA's minimum necessary standard from the start, not added as an afterthought.
- Reports containing PHI are scoped via Epic Security Points, accessible only to users with the appropriate security class and a documented clinical need
- Break-the-Glass access to sensitive population reports (SUD, behavioral health, HIV) is logged via Epic's audit trail; the analytics team reviews these logs monthly
- Automated report delivery via Report Broker distributes only to pre-approved recipients authenticated within the Epic environment, no unencrypted email attachments
- All extracts leaving Epic (for population health platforms or external reporting) are delivered via SFTP with in-transit encryption, no PHI in plain-text CSV over email
- Slicer Dicer data models are configured to respect Epic's row-level security; patients not in a user's care team do not appear in that user's model results
- Community Connect multi-site reports always include an explicit Department ID or CC Site filter as the first criteria to prevent cross-organization data visibility
- Annual report access audit reviews run history per template, flags dormant permissions, and confirms that recipient lists remain current
Epic Reporting Deep Dive
Reporting Workbench
Reporting Workbench (RWB) is Epic's primary analyst-facing report authoring tool, built around Chronicle's master file / item number addressing system. Every data element is identified by a 3-letter INI code and an item number.
| Master File (INI) | What it represents | Common use in reports |
|---|---|---|
EPT | Patient demographics and registration | Patient-level population reports, demographics, payer |
PAT ENC / CSN | Encounter records (contact serial number) | Visit counts, ED throughput, ambulatory quality |
HLX | Health maintenance milestones | HEDIS preventive care measures (colorectal screening, A1c) |
HSP ACCT / HAR | Hospital account records | Facility ED and inpatient billing reports |
CLB | Clinical results (labs, vitals) | Lab result trending, A1c control rates |
EMP | Provider and staff records | Provider productivity, scheduling reports |
Key RWB practices
- Always filter by Department ID first for Community Connect reports, prevents host-site records from contaminating spoke-site outputs
- For date-sensitive reports, explicitly document which date item is used (e.g., PAT ENC 12060 for arrival vs. PAT ENC 18520 for close) in the template description field
- Use statistics mode with numerator/denominator groupers for quality measure reports, output the rate directly rather than requiring manual calculation
- Store all production templates in a shared analytics folder with a standard naming convention:
[SITE]-[DEPT]-[METRIC]-[FREQ]
Slicer Dicer: enabling self-service
Slicer Dicer lets clinical end users explore data through pre-curated data models without analyst involvement. The ROI is deflecting routine ad-hoc requests from the analyst queue.
- Analyze the prior 6 months of ad-hoc requests. Identify the top 20 recurring question types.
- Map each question type to an existing Slicer Dicer data model, or build a custom curated model where one doesn't exist.
- Train 1-2 department super-users per site on Slicer Dicer navigation (half-day session, recorded for future onboarding).
- Publish a "what Slicer Dicer can answer" one-pager on the intranet, with example saved filters for the 5 most common questions.
- Track Slicer Dicer session counts monthly via Epic reporting. Target: 30% reduction in analyst queue volume within 6 months.
Radar dashboard standardization
The ED throughput fix illustrates how small configuration choices create large measurement inconsistencies. My approach to any Radar dashboard audit:
Data Quality and ETL
3-step QA for every new report
- Spec validation, compare report output to manually verified source data for a sample of 20-50 records. Verify that criteria filters produce the expected denominator.
- Cross-reference check, run the same population through an independent source (legacy report or direct Chronicles lookup) and compare counts. Acceptable variance: under 0.5%.
- Edge-case testing, run the report with extreme date ranges (start of go-live vs. a 1-day window) to confirm filters work correctly at boundaries. Verify Community Connect filter eliminates host-site records.
ETL for downstream platforms
When data flows to a population health platform (e.g., Arcadia or Innovaccer), the handoff is structured and auditable:
- Reporting Workbench extract scheduled via Report Broker with automated run and output to a dedicated SFTP landing zone
- Record count embedded in the filename (e.g.,
HEDIS-DM-20260501-4821.csv) so the receiving platform detects truncated files before ingestion - Data dictionary maintained mapping Epic field names to target platform field names, versioned in SharePoint
- Run timestamps and record counts logged to a SharePoint tracking sheet; any deviation from the prior-month baseline by more than 15% triggers a manual review
Python validation script
Monitoring and Dashboards
Report services operations dashboard
A Radar dashboard visible to the analytics team tracks the health of the reporting function itself, not just clinical data:
| Component | Metric | Target |
|---|---|---|
| Open request count by age | Buckets: 0-14d, 15-30d, 31-60d, 60d+ | 90% in 0-30d bucket |
| Requests closed this month | Running count vs. same month prior year | Upward trend |
| On-time delivery rate | % delivered by committed date | 95%+ |
| Top requesting departments | Bar chart by site | Informs self-service training priority |
| Automated report run status | Last run timestamp per report | All runs green, no missed cycles |
| Slicer Dicer session count | Monthly unique users | Upward trend = adoption working |
Report performance monitoring
Large Reporting Workbench templates can time out or overload the Epic server if poorly optimized. I monitor run times and flag any template exceeding 5 minutes for a criteria audit, a missing index filter on a date field is the most common cause.
- Epic logs execution time per template run, reviewed weekly for templates over 3 minutes
- CPU-intensive templates flagged in Epic System Pulse by the Epic technical team
- Report Broker failure notifications email the analytics team immediately when an automated job does not complete
- Scheduled report completion logged to tracking sheet; any missed run investigated before next business day
Change Management
Phased rollout for new dashboard suite
Stakeholder communication standards
- Every report request receives an initial triage response within 2 business days confirming receipt, classification, and expected delivery date
- If a delivery date changes, the requester is notified proactively at least 3 business days before the original deadline, not the day it's due
- Written spec sign-off is required from the requester before development begins, prevents scope creep and scope debate after delivery
- Completed reports include a brief "how to read this report" note explaining filters, date ranges, and any known data limitations
Root Cause Analysis
Incident: ED throughput metric discrepancy, June 2025
Detection
QI director flagged a 12% variance in ED visit counts for the same month across two Radar dashboards at sites with similar patient volumes.
Scope
3 dashboards affected. 214 encounters straddled the June/July month boundary. Affected 2 months of historical QI reporting.
Resolution time
Root cause identified in 4 hours. Fix deployed to all 3 dashboards within 24 hours. QI director sign-off within 48 hours.
Investigation steps
- Pulled underlying Reporting Workbench template IDs for all 3 dashboard components from Radar component configuration.
- Compared criteria filter definitions side by side in a spreadsheet. Identified 3 different date anchor fields across the 3 templates.
- Isolated the 214 encounters that opened in late June and closed in early July. Confirmed these accounts for the exact 12% discrepancy using a test Reporting Workbench run with each date anchor.
- Drafted fix: standardize all 3 templates to
ED Arrival DT(PAT ENC 12060). Confirmed with ED informatics lead that Arrival DT is the clinically appropriate anchor for operational metrics (not billing close date).
Fix and prevention
- Updated all 3 Reporting Workbench templates to use PAT ENC 12060 (ED Arrival DT) as the sole date anchor
- Added a description field entry to each template documenting the date anchor standard and the reason for the choice
- Added "date anchor field" as a required column in the report spec documentation template, all future templates must declare which date item they use and why
- Cross-reference validation (comparing output against a known-good source) added as a standing QA checklist item for all new report builds
- Sent a written summary to the QI team confirming the fix and explaining that historical data was not altered, only the reporting logic was corrected going forward
Disaster Recovery
Report template backup
RWB templates live in Epic production. If a template is accidentally deleted or corrupted, recovery depends on having a documented registry and exported copies.
- All custom templates documented in a SharePoint report registry: template ID, name, description, Chronicles sources, owner, and last-modified date
- Monthly export of template definitions stored in a versioned SharePoint library, 12 monthly snapshots retained at all times
- Tier 1 templates (8 HEDIS quality reports, ED throughput suite) reviewed and re-validated quarterly
- Template naming convention enforced:
[SITE]-[DEPT]-[METRIC]-[FREQ], enables quick search and sorting in the registry
Reporting service continuity during Epic downtime
Automation
Highest-impact automation targets
| Automation | Current effort | After automation | Tool |
|---|---|---|---|
| Monthly HEDIS quality reports (8 reports) | 18 hrs/month manual | <30 min exception review | Report Broker + SharePoint |
| Nightly ED throughput email to medical directors | Ad-hoc on request | Automated daily at 7 AM | Radar Burst Report |
| Report output row-count validation | None (manual spot checks) | Automated after every Report Broker run | Python script |
| Request queue aging alerts | Manager checks manually | Auto-alert at 21-day mark | ServiceNow workflow |
| Population health platform ETL | Manual CSV export and SFTP upload | Scheduled weekly automated extract | Report Broker + SFTP |
Report Broker configuration for HEDIS automation
Why I Stand Out
Automation-first mindset, proven in production
At Bright Horizons I reduced manual CI/CD effort by ~40% through AI-driven agentic workflows. I'll apply the same discipline here: find the highest-burden recurring report and automate it in the first month.
Data integrity through systematic comparison
I built an Inventory Configuration Comparison framework at Zoho that cut configuration discrepancies by ~80%. The same pattern applies to report QA: run two independent sources and compare. That's how I caught the date-anchor issue in the RCA above.
Comfortable with complex data models
Epic's Chronicles is hierarchical and proprietary, but data model reasoning (master files, item references, join paths) is terrain I know from AWS RDS schemas, Oracle configurations, and database systems coursework in my MS program.
Communication that closes the loop
Every project I've run has had explicit stakeholder sign-off milestones. I don't deliver reports and disappear. I validate with the requester, document the spec, and make the handoff clean enough that someone else can maintain it.
Boston-area, remote-ready
Based in Framingham, MA, BMCHS's primary market. I understand Massachusetts health system dynamics and can attend on-site for critical milestones without friction.
Self-directed learner, Epic-certified path
I hold an MS in CS and have taught myself cloud and DevOps tooling on the job. Epic's learning curve is a matter of time and commitment, both of which I have. Reporting Workbench Fundamentals and Slicer Dicer certifications are on my Month 1 plan.