EHR Report Building

What is EHR report building?

EHR report building is the work of turning a question about patients, visits or outcomes into a defined, tested report drawn from electronic health record data. It covers the specification, the data source, the query or measure logic, validation against charts, and the change control that keeps the report correct after the EHR or the definition changes.

The query is the smallest part of the job. Most of the effort goes into agreeing what the question means and proving that the answer is right, and most report failures trace back to skipping one of those two steps.

Which kinds of EHR reports are there?

EHR reports fall into five kinds, and each needs a different level of rigor. A worklist used by a nurse this afternoon and a quality measure sent to CMS are both reports, but they fail in different ways.

• Worklists: Patient-level lists for action today, such as patients due for a screening or results awaiting sign-off. They must be current and complete.
• Operational reports: Counts and rates for managers, such as no-show rates, visit volumes or time to third available appointment. They must be consistent week to week.
• Executive dashboards: Summary measures across sites and service lines. They must match each other and match the finance numbers.
• Regulatory and quality reports: Measures submitted to CMS, payers or registries. They must follow the published specification exactly.
• Research and extract reports: Cohorts or data sets for analysis outside the EHR. They must be reproducible and limited to the minimum data needed.

Name the kind on every request. It decides the data source, the validation depth and who signs off, and it stops a quick operational count from being reused, without review, as a quality measure.

How do you write an EHR report specification?

Write the specification as a short document that a second analyst could build from without asking questions. If two analysts could build it differently, it is not finished.

• Question: The decision the report supports, in one sentence, and who makes it.
• Population: Which patients or encounters are counted, with the exact rules: age on which date, which visit types, which departments, active or all.
• Measure: The numerator and denominator for a rate, or the field and aggregation for a count or average.
• Exclusions: Who is removed and why, such as deceased patients, hospice patients or test records.
• Time window: Visit date, order date or result date, and whether the window is calendar months or rolling days.
• Data elements: Each field used, with its source table or resource and the codes that qualify, such as a LOINC code list for a lab test.
• Refresh and audience: How often it runs, who sees it, and whether it shows patient names.
• Owner: The clinical or operational person who answers definition questions and signs off changes.

Code lists deserve special care. A diabetes report built on three diagnosis codes and one built on a full value set will disagree, and neither is wrong until the specification says which one is intended.

Where should an EHR report get its data?

Pick the data source by how current the report must be and how much history it needs. Live sources suit worklists; reporting databases and warehouses suit trends and dashboards.

• Built-in EHR reporting: The vendor's own report tools run on current data and respect the EHR's security, but limit complex logic.
• Reporting database: A nightly copy of the EHR in relational form supports complex queries, and trails the live record by a day.
• Enterprise data warehouse: Data shaped for analysis, often combined with claims and other systems, with shared definitions across reports.
• FHIR APIs and Bulk Data: Standardized resources for apps and external platforms, though not every field in the EHR is exposed.
• Interface feeds: HL7 v2 messages captured in near real time for event-driven worklists and alerts.

Record the source in the specification and on the report itself, with the time the data was last refreshed. A dashboard that silently shows yesterday's data during a morning huddle will be blamed on the report, not the load schedule.

How are quality measure reports built?

Quality measure reports are built to a published specification rather than a local one. Electronic clinical quality measures (eCQMs) define their logic in standard formats, and the EHR must record the data, calculate the measure and produce a standard file.

ONC's certification criteria at 45 CFR 170.315(c) split this into three capabilities: record and export the data needed for each measure, import and calculate each measure, and report the results electronically. The report criterion points to the CMS implementation guides for Quality Reporting Document Architecture (QRDA) Category I for inpatient measures and Category III for ambulatory measures.

The eCQI Resource Center explains the two formats. QRDA I is an individual patient-level report with data for one patient across one or more measures, used by hospitals. QRDA III is an aggregate report for a set of patients, used by eligible clinicians. It describes Clinical Quality Language (CQL) as the expression language that defines the data to retrieve and the logic to evaluate each measure.

• Use the published logic: Implement the measure's CQL and value sets rather than rewriting them in local SQL.
• Check data capture first: Most measure failures are documentation that lands in free text instead of the coded field the measure reads.
• Run patient-level detail: Produce the list of patients in each numerator and denominator, so clinicians can check why someone failed.
• Track the version: Measures are updated each reporting period, so tag every run with the measure version used.

How do you validate an EHR report?

Validate an EHR report by checking its numbers against charts, against other trusted figures and against cases built to break it. No report should reach users on the strength of the query looking right.

• 1. Chart review: Pull a random sample of included and excluded patients and have a clinician confirm each one against the chart.
• 2. Reconciliation: Compare totals with a figure people already trust, such as visit counts from billing or census from the bed board, and explain any gap.
• 3. Edge cases: Test patients who changed departments, merged records, canceled visits, late documentation and boundary dates at the edge of the window.
• 4. Peer rebuild: Have a second analyst build the core count from the specification alone and compare results.
• 5. Parallel run: Run the new report beside the old one or the manual process for at least one cycle and resolve every difference.
• 6. Sign-off: The report owner approves the results and the known limitations, which are written on the report.

Keep the validation evidence with the specification: the sample, the reconciliation and the differences found. When someone questions the number six months later, the answer is already written down.

How do you keep EHR reports correct after go-live?

Keep reports correct with version control, change control and monitoring. EHR upgrades, new templates and new departments all change the data underneath a report without anyone touching the report itself.

• Versioning: Store report logic in source control with the specification, and record which version produced each published result.
• Change control: Route EHR build changes that touch report fields, such as a new flowsheet row or note template, past the reporting team.
• Monitoring: Alert when a report's row count or key rate moves outside its normal range, which often means a data change, not a real change.
• Retirement: Review usage each year and retire reports nobody opens, so the remaining ones get proper care.

A short catalog helps: each report's name, kind, owner, source, version and last validation date in one place, so anyone can see which numbers are maintained.

Where EHR reports go wrong

• Undefined denominator: The report counts patients seen once in three years as active, so the rate looks worse than it is.
• Double counting: Joining encounters to diagnoses counts a visit once per diagnosis.
• Test patients: Training and test records are left in production totals.
• Time zones and dates: Visit dates stored in UTC shift late-evening visits into the next day.
• Copied logic: A report is copied for a new department and keeps the old department's filter.
• Free-text data: The measure reads a coded field that clinicians rarely use, and the report shows a care gap that is really a documentation gap.

Every one of these is caught by the validation steps above, which is the argument for never skipping them. When a report has already shipped with one of these faults, correct it openly: publish the corrected figure, note what changed and why, and tell the people who acted on the old number. Quiet fixes cost more trust than the original error.

How Agnotic can help

Agnotic Technologies builds EHR reports for clients the way they should be built: a written specification agreed with the report owner, a data source chosen for the use, logic in source control, and validation evidence kept beside the report. For quality measures, Agnotic implements the published logic and the QRDA output rather than a local approximation.

Agnotic also builds the pipelines that feed reports from EHR databases, FHIR APIs and HL7 v2 feeds, with refresh monitoring so a late load is flagged before anyone reads a stale number.

Sources

• 45 CFR 170.315: ONC certification criteria, clinical quality measures
• eCQI Resource Center: About QRDA
• eCQI Resource Center: Standards summary