Build vs buy medical billing with your EHR: integrated module, separate system or custom layer?
There are three ways to bill from an EHR: use the EHR's own practice management and billing module, run a separate billing system that the EHR feeds through interfaces, or build a custom billing layer on top of one of them. The deciding factor is rarely features. It is how many interfaces each path needs and where charges can be lost between them.
Which interfaces does each billing path need?
Quick answer
Build vs buy medical billing for an EHR is a choice between three architectures: the EHR's own billing module, a separate billing system fed by HL7 v2 interfaces, or a custom billing layer. Each extra interface is a place where charges can go missing. Agnotic Technologies maps those interfaces and the reconciliation each path needs before you choose.
| Criterion | Integrated module | Separate system |
|---|---|---|
| Registration and demographics | Shared record: no feed needed | HL7 v2 ADT from the EHR to billing, plus updates back if billing staff edit demographics |
| Scheduling | Shared schedule | HL7 v2 SIU messages if billing runs eligibility checks before visits |
| Charges | Charges drop from documentation inside one system | HL7 v2 DFT^P03 messages or a charge file from the EHR |
| Eligibility | X12 270/271 from the module to the clearinghouse | X12 270/271 from billing; results may need to show in the EHR |
| Claims | X12 837 built by the module | X12 837 built by the billing system |
| Remittance | X12 835 posts in the same system as the chart | X12 835 posts in billing; payment status may need a feed back to the EHR |
| Patient balances and statements | One patient account | Decide which system owns balances, statements and payment plans |
| Where charges get lost | Unsigned notes and charge rules that never fire | The same, plus rejected DFT messages and unmapped charge codes at the interface |
| Daily reconciliation | Charges against completed visits | Charges sent against charges received, plus charges against completed visits |
| Changing later | Replacing billing means replacing or reconfiguring the EHR module | Billing can change while the EHR keeps running |
What they are
What is Integrated module
An integrated module is the EHR vendor's own practice management and billing component, sharing the same database as the clinical record. Registration, scheduling, charges, claims and payments live in one system, so there is no charge interface between documentation and billing.
What is Separate system
A separate billing system is a practice management or billing platform from another vendor, or one your billing company runs, fed by interfaces from the EHR. It can serve several EHRs or locations at once, but every charge crosses an interface before it can become a claim.
Key differences
Why do interfaces matter more than features here?
Feature lists for billing systems overlap heavily. What differs is the path a charge travels. In an integrated module it never leaves the database. With a separate system it crosses at least one HL7 v2 interface, gets mapped, may be rejected, and has to be reconciled. Each interface needs an owner, monitoring and a daily check, and that work lasts as long as the systems do.
What does HIPAA fix, and what does it leave to you?
HIPAA adopts the X12 837 for claims (45 CFR 162.1102), the X12 835 for remittance advice (45 CFR 162.1602) and the X12 270/271 for eligibility (45 CFR 162.1202), so the payer side looks the same on either path. The charge interface between EHR and billing has no such mandate: its content and codes are agreed per site, which is where most of the mapping work and most of the lost charges sit.
Who owns the patient account?
One system has to be the source of truth for balances, payment plans and statements, or patients receive two bills with different totals. With an integrated module the answer is simple. With a separate system, pick one owner, send payments and adjustments to it, and show a read-only balance in the other system for front desk staff.
When does a custom billing layer make sense?
When the claim logic is the product: a digital health company billing novel care models, a billing company with its own rules engine, or an MSO joining several EHRs into one work queue. A custom layer usually sits beside an EHR or a billing system, not instead of both. It adds the interfaces of the separate path plus your own code to maintain, so build it only for the part no product covers.
How do you get the data out when you switch?
Health IT certified to 45 CFR 170.315(b)(10) supports electronic health information export: a single patient export a user can run without developer help, and a population export, in a computable format with a public link to the format. Plan the billing migration around open accounts receivable, patient balances and payer enrollment as well, which an EHI export does not settle on its own.
When to use each
When to use Integrated EHR billing module
- Your EHR's billing module covers your specialties, payers and claim types.
- You want one patient account and one place for staff to look.
- Your team is small and cannot run an interface engine and reconciliation.
- Charge capture depends on documentation rules inside the EHR.
When to use Separate billing system
- You bill for several EHRs, locations or acquired practices from one system.
- A billing company or MSO standardizes on its own platform.
- The EHR's billing module does not support a specialty, payer mix or workflow you need.
- You want to change the EHR or the billing system without replacing both.
Where do charges get lost, and how do you reconcile them?
1. Notes that are never signed. No signature, no charge. Check: open encounters older than your charge lag, by provider.
2. Charge rules that do not fire. A new service or location has no rule. Check: completed visits with zero charges.
3. Rejected charge messages. A DFT fails on an unknown provider, location or code and sits in an error queue. Check: interface errors per day, with an owner who clears them.
4. Unmapped charge codes. The EHR code has no billing equivalent. Check: a mapping table with alerts on unknown codes.
5. Charges that arrive twice. A resend or a correction posts as a new charge. Check: duplicate charges per encounter and code.
6. Late charges after the claim went out. Check: charges posted after claim creation, routed to a corrected claim queue.
7. Count reconciliation. Every day, compare charges sent with charges received and completed visits with charged visits, and investigate any gap before it ages.