The Reporting Work
Regulatory reports & data summaries (EPIC + SQL)
I created regulatory reports and data summaries for clinicians through EPIC and SQL. The consumers were clinicians, not analysts, so the output had to answer the question they were actually asking — in the shape they could use it — not just return rows.
Vocera device-usage reporting (SQL)
As the Vocera system administrator, I created SQL reports on device usage data from different departments — which units were using the voice system, and how much — giving the organization a factual view of adoption and load on a system the hospital depended on for communication.
Data Quality Starts at Capture
A report is only as good as the data entered upstream. A core part of my EPIC support work was making sure data was being captured correctly — and showing users how to enter data based on the application's logic, so entries landed in the right fields, in the right form, the first time.
Coach the entry, not just fix the report
When a report looked wrong, the cause was often an entry pattern, not a query problem. Educating end users on how the application expected data to be entered fixed the source instead of patching the symptom every cycle.
Escalate the structural issues
Problems with application setup or data capture that coaching couldn't solve went to the appropriate departments with a clear description — the support queue doubled as a sensor for where the system's data design fought its users.
Why It Matters for Data Architecture
Most data roles see one end of the pipeline. This one showed me both: how data is created by busy people under time pressure, and how it is consumed by people making decisions. That full-path view — capture, structure, reporting, decision — is the foundation I build on when I think about data systems now, including the regulatory systems work at Organon in this portfolio.