If you manage provider groups or are part of a provider group, you likely have come across integrations with a facility, or healthcare system. Well, this article is for you! Today we are breaking down integrations between a hospital and the Revenue Cycle Management (RCM) vendor. There are many types of RCM integrations. Below is a version of my personal running list of integration types. You may be able to think of more, but this is the list I am currently working from, and regularly evaluating. The one we are going to focus on today is a "New Client Start Up," what I believe to be the most traditional.
New Client Start Up
New Client Bad Debt Vendor Integration
Existing Client RCM Transition
Existing Client Bad Debt Vendor Integration
New Client with prior RCM Transition
New Location Adds for Existing Client
RCM vendor Practice Management system Change for Existing Client
Facility EMR/EHR Change for Existing Client
EMR/EHR Change for Existing Client
Integrations begin well before you actually start communicating with the hospital. For me, I always ask for two pieces of information during the final steps of the contracting process.
What Electronic Medical Record (EMR) system is the facility on?
Who is my integration contact on the facility side?
These two questions are all I need from my contracting and leadership teams to get a running start. Now, true, there is a lot more information that needs to be scoped out. But with this set of information, I can form a plan and have someone to whom I can direct my questions.
Where to Start
I start with the EMR. If you have spent any amount of your career with RCM integrations, you may have picked up certain limitations or opportunities that come with each system. It's messy, it's variable, and often the facility teams themselves are not fully aware of what the system is capable of producing. Before we get into some examples, let's go over what I call the core of integrations.
Main Types of Core Integrations
There are really two types of integrations, and it all comes down to the type of provider group. Either they are (1) a group that does not do their own coding, or (2) a group that does their own coding (also called charge entry). That's it. That's the two types.
The more straightforward integration type for me are those where the providers do not code. When you throw in provider coding, you have to add in the variable of where the providers are doing this coding.
ONE: Facility integration for a provider group that does not code
(Examples: Urgent Care, Emergency Department, Observation)
These standard integrations require four things. Just four things, and only four things. In the past nearly six years, I have overseen 62 integrations that fall under the integration types listed above, and this list has been pretty standard for any facility integrations.
Daily Insurance and Demographic Report
Per patient copy of the Medical Record (MR) for the care rendered
EMR System Access
Daily Unit Census Log Report
Each integration requires collaborative assessment of what both the facility system, and technical staff are capable of providing within the integration timeline. This may mean that your wish list of optimized data feeds and transmission pathways is not established in time for client go-live. Here is where it is critically important to have knowledge of the system, what short term plans can be defaulted to, and how long your RCM team can maintain a less optimized plan. It also undoubtedly will impact claim processing and therefore reimbursement. So aim high with full automation, and work back from there.
Here is my simple grid for how to drive discussions around integrations. It starts with most manual to most automated, and of course, we want to start with pursuing most automated.
For short term planning, you may be dependent on a regional or national integrations team for your facility. This is where options for flat files or direct coding come into play to meet a go-live date. The facility technical team also may not even know if their system stores data in a way that allows HL7 feeds. This is especially true for MR transmissions.
Typically, I get the ADT feed via HL7, a PDF MR transmission via SFTP, and then some sort of restricted EMR access, and a Census Log. And that is completely okay! It gets me to semi-automation, and allows for account processing that most RCM teams can consume and build out programming (put a pin in this as we will discuss it more below). But the question has to be asked. If these level of "Great" to "Most Automated" types are fine for getting things up and running, why push for more automation? Oh I am so glad you asked.
There is this little issue with this Type One of integrations, we are dependent on both the facility and the providers to ensure complete data that allows for processing.
Facility Registration Dependencies: From a facility standpoint, there are so many registration gaps and errors in these spaces of UC, ED, and OBS. Those gaps and errors are flowing real time to the external provider RCM. If the facility is not updating the patient demographics and insurance timely, or if they update them only in their back-end system, then our external RCM process will not be getting the most accurate patient data. This is tell tale by a high number of rejections and/or denials. We need patient information to be automated and timely so programming can produce the best outputs.
Provider Documentation Dependencies: It would be absolutely ridiculous to say a provider can complete their entire charting by end of day. There are so many dependencies, specification within procedures, lagging labs, or documentation from a Advanced Practice Provider (APP) is incomplete and therefore the supervising Physician cannot review and co-sign. Having a MR transmission if not automated in an HL7 feed, requires further integration discussions on Auto-re-transmission functions. Traditionally, if the method is a PDF MR, I try to get the initial record (regardless of level of completion) three days (or 72 hours) from the patient's Date of Service (DOS). And then I try to have programming added that auto-re-transmits a record that has had any addendum. That way we get any updates to deficiencies. Why not wait for the final completed record? Because I need to educate the providers on timely and complete records processing. I need to see what they are consistently missing, what is preventing processing through coding without manual intervention.
For any integration I always say plan for seven months. One month of prep, three months pre-go-live integrations with the facility and RCM team, and then three months of post go-live optimization. I have some optimization projects that go well past three most past the provider group go-live. Sometimes, it takes 9 months to a full year. These nearly are always due to facility regional or national dependencies, or timeline restrictions. So plan and plan again.
TWO: Facility integration for a provider group that does code
(Examples: Intensivists, Hospitalists, Specialists)
I would love to say that this second type of integrations is easier than type one. The providers are doing their own coding, so that is one less thing, right? Wrong. We have a new variable. As mentioned earlier, providers must code into a system. Traditionally, it is a new contract with a new vendor to facilitate this activity. It also depends on how the group and RCM vendor are set up. I have experienced multiple versions of this set up. Some integrations result in (A) choosing a front end EMR for our providers where they can enter CPTs, others are (B) relationships with the facility and building out charge router programming, and then most common, (C) selecting a secondary vendor that hosts charge entry/coding by providers that can then be passed to the primary RCM vendor.
A lot of this integration is standard however, it just takes on a different plan. The RCM vendor is still dependent on getting a feed or file from the facility for patient registration data. And we still need restricted access and a census log report. The part that is different is the switch of the requirement of a copy of the patient's medical record, to a feed or report of the CPTs/Charges the provider coded.
Why wouldn't I still want the MR? In some cases, I do! But it's generally less required than the Charge Entry, since my RCM vendor is not doing coding or re-coding. They are picking up the workflow at time of claim/bill creation.
The workflow for a type Two integration requires more repetition of communication. In the case where I have a second vendor for the provider charge entry, I need to ensure both them and my primary RCM vendor get an ADT feed. And then I need to get a feed from the secondary vendor to my primary RCM vendor via a report or DFT feed. It is a lot of coordination and timing, and there are less manual options that allow for short-term solutions. Don't get me wrong, they are there, it is just painfully slow to build and put into production with this extra variable.
I have the Pieces of the Puzzle; How do I make a Picture?
Sometimes I get various types of pushback on why I would want a specific type of data, or report or feed, or even access. I get it, the facility wants to ensure the patient data they provide is protected. And I am 100% onboard with their concerns, which is why this is the minimum necessary to ensure my RCM teams get what they need to code and bill where applicable. I need all 4 components for necessary claim/bill processing. But I also need to make sure I can communicate what these pieces all do once you combine them. Back to our type One example!
We have:
An ADT feed via HL7,
A PDF MR transmission via SFTP,
Restricted EMR access, and
A Census Log report via SFTP.
Pretty much any RCM vendor is going to have a type of middleware software. Think of this as the translator, coin sorter, and the information syncing machine.
As a Translator: Easiest example is if the data comes over with patient name in one field = Last, First. But then in the back-end RCM practice management (PM) system, I have separate fields of First and Last in that order. I need something to remap the data.
As a Coin Sorter: The example here is noting if RCM received a specific report or data type. Or, did they receive data from multiple facilities that need to be mapped into a specific location on the PM side.
As an Information Syncing Machine: Just because I have reports and data, they do not just fall into the PM system haphazardly. Programming has to perform reconciliation. The Census Log report creates a trigger for account creation (we saw X patients on day Y). Then the ADT feed brings in the details of those patients into the account shell (here is a patient's insurance and demographic info). Finally, the system waits, and says okay, where is my MR so I can begin coding? Once that MR is received a few days later, the Mid-stream RCM process begins! Accounts with MRs are pushed to coding teams to begin the process.
Each RCM vendor and middleware may have its own design and programming for this workflow. But I find this overview above is the most failproof for successful transmission monitoring. If I do not get a Census Log report, I have noting to reconcile to. If I do not get ADT data, who is this patient and who am I supposed to bill? And if I do not get an MR, I cannot code to create billable charges. Each piece plays an important part in the reconciliation process.
I hope you caught that we did not talk about access in our quick run-through of reconciliation. It was on purpose, and here is why. If I received 100% accurate patient name, address, DOB, insurance information, and any guarantor information, AND if providers never made errors, and always documented 100% of their care within a few days of the patient's DOS, AND if the facility never had transmission issues, well then, I really wouldn't need that EMR access would I?
Alas, healthcare is not error proof, and there are delays and issues and missing information.
I need my RCM teams to have this access for this very reason.
I need them to look up any alias of patients when middleware spits the account out as an error.
I need them to confirm primary and secondary insurance or updated insurance.
I need them to validate addresses for bad address returned mail.
I need them to perform a MR merge or mismatch reviews notified to us by the facility.
I need them to pull MR to review provider documentation issues for education.
I need them to pull MRs for denials or regular 3rd party audits.
I need them to check what transmitted via facility programming vs what we actually received (example: missing orders, or procedures).
I could go on and on. It goes back to the two dependencies (facility and provider) we went over in the beginning. Without access, I am limited on patient satisfaction, provider education, and reimbursement opportunities.
Concluding Thoughts
Okay, so maybe this isn't a 101 type overview of profee integrations. It's about as 101 as I can get to in a few pages. I could go on about those various EMR system-specific limitations and opportunities. I could even explain some of the common hurdles I have encountered based on these systems and various regional or national teams. The point of all of this is understanding where to start, with the four main things you should be requesting for an integration. I hope these grids of manual to automated workflow help you in your next integration!