What a Healthcare Business Analyst Does in RCM and EHR

What a healthcare business analyst does on RCM and EHR projects

A healthcare business analyst turns clinical, billing and payer rules into requirements a build team can use, and then proves the system follows those rules before and after go live. On a revenue cycle or EHR project that means workflows, claim edits, interfaces and test cases. My view is simple. If the project touches claims or clinical data, hire the domain first and the tools second.

The catch is that the role sits between three groups who speak different languages. Clinicians talk about orders and documentation, billing staff talk about charges, modifiers and denials, and the IT team talks about fields, tables and messages. The analyst has to be comfortable with all three, and the requisition should say which one matters most. For any of the business analyst and project roles on a healthcare project, that one decision changes the search more than any tool on the job description.

Claim edits are a good example of the detail involved. CMS runs the National Correct Coding Initiative, and according to the CMS page on NCCI edits the procedure to procedure edits and the medically unlikely edits are updated every quarter and applied by Medicare Administrative Contractors in claims processing. An RCM business analyst has to know where each edit lives, in the payer system, the clearinghouse or the billing system's own scrubber, and write a requirement that keeps it current. A requirement that says "apply NCCI edits" with nothing about the quarterly update will be wrong in three months.

The claim format itself is fixed by regulation. The CMS overview of HIPAA transactions explains that HHS adopted standard transactions for claims, eligibility, claim status, payment and remittance advice and several others, and that covered entities who conduct them electronically must use the adopted standard. So the analyst does not design the claim file. The analyst maps the client's data to it and decides what the system does when a value is missing or wrong, and that is where most of the real requirements are.

On the EHR side the analyst works on order entry, documentation templates and the charge capture that flows from clinical documentation into billing. Many of these systems are certified under the ONC Health IT Certification Program, a voluntary program that ONC manages and that supports the CMS Promoting Interoperability Programs. An EHR business analyst should ask early whether a change touches functions the client uses to report under those programs, because nobody wants to find that out during an audit.

Payer projects carry their own deadlines too. The CMS Interoperability and Prior Authorization Final Rule, released January 17, 2024, gives impacted payers primarily until January 1, 2027 to meet its API requirements. An analyst on that kind of project should read the rule itself and trace each requirement back to it, not work from someone's slide deck.

How the role differs from a general IT business analyst

The healthcare business analyst role uses the same core craft as any other analyst job. Discovery with people who disagree, clear requirements, user stories, acceptance criteria and a traceability matrix. The difference is what the analyst already knows before the first meeting. The Bureau of Labor Statistics says in its Occupational Outlook Handbook entry for computer systems analysts that analysts must understand the industry they work in, and it gives a hospital example where the analyst needs to understand programs such as Medicare and Medicaid. That is the whole difference in one line.

Here is how it looks in a real requirement. A general analyst writes that the system shall calculate the patient balance. A healthcare analyst knows the balance depends on how the payer adjusted the claim, whether an amount is a contractual write off or patient responsibility, whether a secondary payer still has to be billed, and what happens when the payer takes money back on a later remittance. Same sentence on the surface, very different build.

The same BLS page reports a median annual wage of $105,850 for computer systems analysts in May 2025, and $101,570 for those working in health care and social assistance. These are employee wages, not contract bill rates, so use them to check a direct hire offer, not to price a contract.

I do not think every analyst at a hospital needs healthcare depth. A patient portal redesign, a CRM rollout or an internal reporting tool can go very well with a strong general analyst. We cover where that line sits in healthcare IT versus general IT consultants. But claims, remittance, coding and clinical documentation are not places to learn on the job.

Testing and go live support on a revenue cycle project

A healthcare business analyst should own the test scenarios, because the build team does not know which claims break. A good set covers an original claim, a corrected or replacement claim, a void, a claim with a secondary payer, a zero pay remittance, a denial, a partial payment and a takeback. Each scenario should name the expected result on the acknowledgment and on the remittance, as well as on the screen. An analyst who works this close to the claim file needs some of the same knowledge we test in our questions for healthcare EDI analysts.

Interfaces need the same care. Registration, charge and result messages move between the EHR, the billing system and outside parties, and the analyst writes the mapping and the error handling. When the work is mainly message design, a dedicated interface analyst may be the better hire, and we explain how to screen for that in hiring HL7 and FHIR interface analysts.

Go live is where the analyst earns the rate. In the first weeks someone has to watch charge lag, claim rejections, the first remittances and early denials, and trace each problem back to a requirement, a configuration or a payer rule. My opinion is that the analyst who wrote the requirements should stay at least until the first full payment cycle posts, because nobody else knows why each rule was built the way it was.

What a hiring manager should look for in a healthcare business analyst

Resumes in this field look alike, so the interview has to do the work. These are the checks I would use.

1. Ask the candidate to walk one claim from scheduling and registration to payment posting, and to name where it can fail at each step.
2. Ask what it means for the patient balance when a remittance adjustment carries the group code CO versus PR. The X12 claim adjustment reason code list defines CO as contractual obligation and PR as patient responsibility, and a working analyst knows the difference without looking it up.
3. Ask for a redacted requirement or test case they wrote, and ask them to explain one decision in it.
4. Ask how they handled a payer rule change or a quarterly code update after go live.
5. Ask which side they came from, billing, clinical or IT, and where they are weakest. Honest answers here are a good sign.
6. Ask how they keep patient data out of test files and screenshots. You want someone who is HIPAA aware in daily work, with habits that show in the files they share.

For candidates, the strongest healthcare analysts often started in billing, coding or clinical roles and learned the systems later. If that is your path, our guide on moving from medical billing into IT explains how to present that experience.

Wanware Technologies is a division of iCareBilling LLC, and my own background is healthcare IT and revenue cycle, so these are the questions I care about most. You can read how we staff these roles on our healthcare IT and revenue cycle staffing page.

Written by

Israr Kazmi

Israr Kazmi is the founder of Wanware Technologies, the IT staffing, recruitment and consulting division of iCareBilling LLC, an American health tech company based in Chicago, Illinois. He writes about technology, healthcare, health tech and AI automation, with a forward-looking view of where these fields are heading. He also covers recruitment, talent placement, vendor partnerships and careers on the corporate side of technology and healthcare.

More about the author