Blog Summary
Healthcare organizations planning an EHR migration typically pause all other software implementations until after the EHR is live. What if you didn’t? This article explores that instead, deploying a charge aggregation platform against an existing system first, then re-pointing the interface to EHR at go-live, produces measurably better outcomes. The charge workflow (interface testing, coding staff familiarity, and exception handling) takes 60 to 120 days to stabilize under real production conditions. Starting that process before the EHR cutover means the organization arrives at migration day with a tested, functioning charge operation rather than building it under pressure during the most disruptive period in the revenue cycle.
EHR migrations are among the most resource-intensive projects a healthcare organization undertakes. Charge capture sits at the intersection of clinical documentation and revenue cycle operations, and it is routinely treated as a project within the project: something to be addressed once the EHR is stable. Organizations that navigate this well treat it differently. They recognize that charge automation is not an add-on to the migration. It is the stable infrastructure that makes the migration manageable.
Is an EHR Migration the Wrong Time to Start Building Your Charge Workflow?
The assumption that the charge process should be built after the EHR is live is risky. An EHR migration introduces simultaneous disruption to clinical workflows, IT infrastructure, and staff training. Adding charge setup to that environment means debugging two things at once, under go-live pressure, with no stable baseline to test against.
The interface work alone illustrates the problem. Every charge automation deployment requires, at minimum, an HL7 ADT feed inbound and a DFT charge file outbound. Depending on the organization’s configuration, it may also require MDM or ORU feeds for charge reconciliation, scheduling interfaces, and outbound mapping to third-party billing systems. Setting up and testing those feeds against real production data takes time.
A CEO of a large multi-site physician group, currently managing charges across seven separate EHR hospital systems, described the sequencing decision that resolved her organization’s charge workflow challenge ahead of an upcoming migration: “Running the system against our current platform really allows us to fine-tune our processes before we turn on the EHR switch. It is going to streamline our EHR deployment.” Her plan at migration is direct: “All we are doing is changing where the interface is going once we migrate.”
That is the right model:
- Test the charge workflow under normal operating conditions.
- Build the coding team’s familiarity with exception handling.
- Identify the edge cases in a low-pressure environment: insurance mapping issues, facility identifier mismatches, provider ID discrepancies.
- Go live on EHR with a charge process that has already been through its instability period.
What Causes Delays in Charge Automation Setup?
Whatever format the sending system uses, medaptus can work with it. However, what is not resolved in advance is the workflow the data needs to support. When interface testing begins, the coders and clinical staff who will use the system encounter real data for the first time. That is when meaningful questions surface: why are certain patients appearing in a facility they should not be mapped to? Why are some visit records generating duplicate encounters? Which insurance identifiers from the sending system map correctly to the billing platform? Those questions are answerable, but they take time and they require the right people in the room. An IT-only testing process will miss the workflow gaps that coding and clinical staff identify immediately.
| Implementation Phase | Primary Activity | Who Must Be Involved | Typical Duration |
| Interface setup | ADT and DFT feeds established; test environment configured | IT, medaptus interface team | Weeks 1-3 |
| Data testing | Real production data validated; identifiers confirmed | IT, coders, billing staff | Weeks 3-8 |
| Workflow calibration | Exception types identified; coding team trained on holds and exports | Coders, RCM leadership | Weeks 6-12 |
| Go-live / re-point | Interface directed at production or new EHR destination | All stakeholders | Week 12-16 |
Organizations should plan for 60 to 90 days from kickoff to go-live for a standard implementation. When client-side IT bandwidth is limited, the realistic timeline is 120 days. That extension is not a function of technical complexity. It is a function of stakeholder availability. The organizations that stay on schedule are the ones that assign a dedicated project contact who understands the workflow from the clinical side, not just the IT side.
How Does Re-Pointing an Interface at Migration Actually Work?
The mechanics are straightforward. The feed architecture (ADT inbound, DFT outbound) does not change at migration. What changes is the source system sending the ADT and the destination system receiving the DFT. Because the charge workflow, coding rules, and exception-handling processes have been validated against the prior system, the migration introduces one variable instead of many.
For organizations operating across multiple facilities, this architecture extends further. A single inbound feed can serve multiple facilities when the HL7 message carries a facility identifier in the header segment. When a new rounding group is added at an existing facility, that feed can often be extended rather than rebuilt. The condition is simple: the message must include an identifier medaptus can use to route the data correctly.
Conclusion
An EHR migration is not the time to learn whether charge automation works. Organizations that arrive at migration day with stable revenue cycles are the ones that treated charge setup as pre-work, not post-work. Starting that process before the EHR cutover means the charge operation is tested, functioning, and understood before the migration happens.
Medaptus works with health systems at every stage of EHR migration planning. To discuss how Charge Pro, medaptus’s charge capture and reconciliation platform, fits into your organization’s migration sequence, talk to us about a demo.
FAQs
How long does a Charge Pro implementation take before an EHR migration?
Most single-facility implementations run 60 to 90 days from kickoff to go-live. When client-side IT bandwidth is limited, organizations should plan for 120 days. The timeline is driven primarily by workflow testing and stakeholder availability during the testing phase, not by the interface setup itself.
Can an existing Charge Pro configuration carry over when we migrate to EHR?
In most cases, yes. The feed architecture (ADT inbound, DFT outbound) does not change at migration. Re-pointing directs the same interface infrastructure at the new source and destination systems. Workflow configurations, coding rules, and provider and location setups carry over.
What interfaces does medaptus set up for a standard Charge Pro implementation?
The standard inbound interface is an HL7 ADT feed, which carries patient demographics and visit data. Outbound, medaptus sends a DFT charge file to the billing system in nearly all implementations. Organizations whose billing platforms cannot receive a DFT receive a custom-formatted delimited file with the same charge data. Depending on the organization’s workflow, additional feeds may include MDM or ORU interfaces for charge reconciliation and scheduling interfaces for outpatient settings.
What does our team need to have ready before the implementation begins?
You must have a project team with both IT and coding or clinical staff assigned, connectivity to the existing EHR and billing systems, and access to a test environment that processes real production data. The critical requirement is having coders and end users involved in testing from the start. Workflow gaps not identified until go-live create avoidable delays.
Does this work for organizations rounding across multiple facilities or EHR systems?
Yes. A single medaptus feed can serve multiple facilities when the HL7 message includes a facility identifier in the header segment. For physician groups rounding across multiple instances, each system’s data flows into one aggregation layer. The provider, group, and location configuration determines which providers and groups see which views. Adding a new facility to an existing feed is typically an extension, not a new build.
About The Author
Gary Bernklow is the Director of Product Management at medaptus, where he has spent nearly two decades shaping the company’s revenue cycle software solutions. With over 30 years of experience in hospital revenue cycle management, Gary brings deep expertise in charge capture, coding automation, and billing workflows.
Get the latest updates and news delivered to your inbox.
Subscribe to our newsletter today.
