EHR / EMR enhancement and optimization
Make the clinical work you already do visible to the systems that pay for it
Everything else (alerts, templates, order sets, crosswalks) is a mechanism for that single outcome. We work in four phases with a signed gate between each, and build six specifications in a fixed order, each with a test you can run yourself.
- Four phases, signed gates
- Six build specifications
- Method fitted to your platform type
Who it's for
Built for the organizations that carry this work
The same method, sized to where the build actually breaks.
Solo and small practices
One to three providers carrying the same reporting obligations as a fifty-provider group, with none of the infrastructure.
Independent groups of 4–15 providers
Enough providers to create variation in how a measure is captured, and not enough infrastructure to control it.
Single-specialty practices
A narrow measure set concentrates risk, and the specialty platform was not built for chronic care or population health.
Large groups and MSOs
Every site adapted the build to local preference; the problem becomes whether the build is the same everywhere.
FQHCs and community health centers
UDS, MIPS or APP, payer programs and accreditation each want a version of the same clinical work, counted differently.
Practices inside a health system
The platform can do what is required, but the build queue belongs to somebody else; we write the specification in their format.
ACOs, IPAs and networks
Reporting is centralized but documentation is not; each member practice is a separate build and a separate failure point.
What we do
What you receive
Six build specifications, built in order. Code mapping comes first because everything downstream maps to it; registry reporting comes last because it reports on everything above it. Each one ends with a test.
- 01
1 · Code mapping
One maintained crosswalk tying every code you use to the measure or risk category it affects.
- 02
2 · Templates and macros
Documentation that produces codable, measure-ready data without adding time to the encounter.
- 03
3 · Alert system
Gaps close at the point of care, and codes attach before the claim drops.
- 04
4 · Patient education library
Condition-specific education that fires with the order, documents itself and satisfies the measures that require it.
- 05
5 · Assessments and order sets
Screening instruments that fire at the right trigger, score into structured data and drive the required follow-up.
- 06
6 · Registry reporting and reconciliation
Internal reports that match the measure specification exactly, and a submission file that reconciles to them.
How it works
Four phases, with a gate between each
A gate is a written artifact you sign. Nothing proceeds past a gate until you have agreed what it contains.
- 1
Access
Baseline audit of your current build, measure performance, capture rates and eligible panel.
Gate: You accept the baseline in writing.
- 2
Design
Measure selection, crosswalk architecture, template map, alert logic and release sequence.
Gate: You sign the build plan. Scope freezes here.
- 3
Execute
Build in test, validate on test patients, promote under change control, and train at each release.
Gate: You accept each release, not one acceptance at the end.
- 4
Monitor
Capture rate against baseline, quarterly review and an annual specification rebuild.
Gate: Renewal, or a documented handoff.
Program facts
How the work is structured
Why the gates matter to you
- A signed baseline means there is no argument later about what was working before we arrived.
- A signed build plan means additions become change orders with a stated cost, rather than silent scope drift.
- Per-release acceptance means a delay on one workstream does not hold up everything else.
- A documented handoff means the retainer is a choice. You should be able to leave.
The six build specifications in detail
- 1
ICD, CPT and procedural code mapping
Objective. One maintained crosswalk tying every code your practice actually uses to the measure or risk category it affects.
What's included
- Crosswalk matrix across ICD, CPT, HCPCS, CPT II and modifiers
- Diagnosis specificity upgrade list with the documentation each requires
- Denominator, numerator and exclusion reference per measure
- Orphan code list: codes in use that map to nothing
- Capture gap list: measures with no current code path
- Maintenance protocol with a named owner at your practice
How you know it worked
Ten recent encounters are pulled at random. Every code is locatable in the crosswalk, and every measure each encounter should have touched has a documented code path.
- 2
Template and macro builds
Objective. Documentation that produces codable, measure-ready data without adding time to the encounter.
What's included
- Template-to-measure map
- Structured field specification per template
- Text expansion library for recurring narrative
- Structured macro library with codes attached to field values
- Provider quick-reference card
- Naming convention and governance document
How you know it worked
A provider completes a representative encounter using only the template and macros. It produces every expected measure element and code with no cleanup afterwards, and takes no longer than their current workflow.
- 3
Alert system for measures and code capture
Objective. Gaps close at the point of care, and codes attach before the claim drops.
What's included
- Measure gap alerts tied to denominator membership, suppressing once satisfied
- Code capture alerts firing where documentation exists without its code
- Firing point map across pre-visit, intra-visit, pre-close and post-visit
- Dismissal taxonomy with reporting, so you can see which alerts are wrong
- Alert burden count before and after
- Tuning protocol and review cadence
How you know it worked
A test patient with a known open gap fires the alert. Acting on it closes the measure and attaches the code. A patient already satisfying the measure does not fire.
- 4
Patient education library
Objective. Condition-specific education that fires with the order, documents itself, and satisfies the measures requiring it.
What's included
- Authored education pieces per condition, in English and Spanish
- Additional languages as specified
- Clinical review sign-off with dates
- Attachment map: which piece fires from which order, diagnosis or visit type
- Documentation capture specification
- Version register and review calendar
How you know it worked
Placing the relevant order produces the correct education, and the education-given status lands as structured data the measure can read.
- 5
Assessment and order set mapping
Objective. Screening instruments fire at the right trigger, score into structured data, map to their measures, and drive the follow-up the measure requires.
What's included
- Assessment inventory mapped to measures and codes
- Structured instrument build with discrete scoring
- Score-triggered follow-up logic
- Order sets by visit type with assessments and education embedded
- Order set to code mapping
- Periodicity rules and full-chain validation record
How you know it worked
Selecting the visit type loads the correct order set. A positive score triggers the follow-up requirement. The encounter produces the code and closes the measure, with no step performed from memory.
- 6
Registry report build and reconciliation
Objective. Internal reports that match the measure specification exactly, and a submission file that reconciles to them.
What's included
- Registry report per measure with denominator, numerator and exclusion logic
- Gap worklist sorted by closability
- Provider-level performance view
- Continuous data completeness monitor
- Reconciliation workbook, internal against submission
- Variance log and a monthly reconciliation routine
How you know it worked
Your internal report and your submission file agree at the patient level for every measure. Where they do not, every variance has a documented cause and a correction at the source.
Working with your platform
Platforms differ in how they are built, and the type determines our method, our hours and who does the building. We type yours during the baseline audit.
Enterprise governed
- Examples
- Epic, Oracle Health, MEDITECH
- Our role
- We design; your system's team builds. We write the specification in their format and carry it through their queue.
Self-configurable
- Examples
- eClinicalWorks, NextGen, Greenway, Veradigm
- Our role
- We build directly in your environment under change control.
Vendor-maintained logic
- Examples
- athenahealth
- Our role
- We configure rather than construct. Fewer build hours, and custom logic cannot deviate far.
Lightweight
- Examples
- Tebra, Practice Fusion, DrChrono
- Our role
- Limited structured capture. We will tell you honestly if the platform cannot carry the program.
Specialty-native
- Examples
- ModMed, Nextech, Kipu
- Our role
- Strong inside the specialty; chronic care and population health usually need something external.
Programmable
- Examples
- Canvas Medical
- Our role
- Protocols as code. Highest ceiling, and it needs a maintainer after handoff.
What we need from you
- An executed Business Associate Agreement before any access to protected health information.
- Administrative access to the platform, or a clear statement that it is not available so we can scope the coordination honestly.
- A named provider champion with review time committed. Templates that no provider reviewed do not get used.
- A named owner for the crosswalk at handoff. Without one it degrades within a year.
- Access to twelve months of billing data for the mapping work.
- Your practice TIN and credentials where reporting registration is in scope.
What is not included
Stated plainly so there is no ambiguity later.
- Claims submission or billing services. You remain the billing party at all times.
- Direct patient care of any kind.
- Platform licensing, module or interface fees.
- Retrospective chart abstraction projects, which are scoped separately.
- Payer contracting and credentialing.
- Platform migration. If the assessment concludes your system cannot support the program, that is a finding we deliver rather than a project we run.
FAQs
Common questions
Do you build in Epic, Oracle Health or MEDITECH?
On enterprise-governed platforms we design and your system's team builds. We write the specification in their format and carry it through their queue. On self-configurable platforms such as eClinicalWorks or NextGen we build directly in your environment under change control.
What if our platform cannot support the program?
We will tell you. Lightweight platforms have limited structured capture, and if the assessment concludes your system cannot carry the program, that is a finding we deliver rather than a migration project we run.
What happens if we want to add something after the build plan is signed?
Scope freezes at the signed build plan. Additions become change orders with a stated cost rather than silent scope drift.
Do we have to keep you on retainer?
No. The monitor phase ends in renewal or a documented handoff, with a named owner for the crosswalk at your practice. The retainer is a choice; you should be able to leave.
Do you submit claims or bill for us?
No. Claims submission and billing services are not included; you remain the billing party at all times.
What do you need before you can start?
An executed Business Associate Agreement before any access to protected health information, administrative access to the platform (or a clear statement that it is not available), a named provider champion, and twelve months of billing data for the mapping work.
Ready to simplify the complex?
Let’s look at your program together.
A consultation is a working conversation about your panel, payers and EHR, and whether this service fits. Please do not send patient information.
Related services
Practice Transformation & Quality Improvement
HEDIS and Star measures, care gap closure, AWV campaigns and care team redesign.
Learn moreRisk Adjustment & Coding Optimization
CMS-HCC V28 risk capture: prospective review, retrospective audits and provider education.
Learn moreAdvanced Primary Care Management (APCM)
G0556–G0558 monthly care management, levels by complexity.
Learn more