Jump to Section:
You can see why the software needs to be as limitless as the possibilities, and this is just a partial list. Let’s go through these and others in a more logical order starting with the last item mentioned: CRM.
No one knows better than you how competitive the behavioral health and addiction treatment world has become. Facilities are “going all out” to attract people in need of help, and present a picture why their organization should be considered.
We’re talking about television and radio commercials, videos, print and online advertising, billboards, “back of the bus” advertising, email and social media outreach campaigns, website presence, postcards, even fly-by advertising at the beach.
Unfortunately, this is mostly due to the opioid epidemic plaguing the US. There’s probably not a single family or workplace that doesn’t have or know of someone in need of help. On a crowded summer day at the beach, there are probably dozens and dozens of people, maybe hundreds of them who take more than a glance at that fly-by advertisement for addiction treatment.
The point is, marketing has become a huge, almost impossible to avoid aspect in the behavioral health / addiction treatment industry. With millions of dollars being spent on marketing and advertising, treatment facilities need a way to measure the success of these efforts…what is or isn’t working, what needs to be tweaked, how much revenue can be attributed to any one campaign, etc., etc.
For that, a CRM is needed.
A stand-alone CRM can be extraordinarily expensive depending on the system size needed and the “bells and whistles” features selected. It would have to be integrated - almost assuredly at an additional cost - into your EHR / billing / management system for optimal use. And don’t forget the ongoing maintenance cost that would also no doubt be needed for keeping the integration live and working.
It’s not a stretch to be looking at a six figure number just for a CRM.
BUT…if CRM capabilities are built into the EHR / management system at no additional cost, well that’s exactly what it means: it’s built in at no additional cost, and there are no interface or CRM-specific maintenance costs either. It’s one nice, neat, tidy package with the moving parts all talking to each other.
That’s what you want, assuming the built-in CRM is robust enough to handle the job. So when considering automation for your facility or organization, see what it has in the way of a CRM for tracking your marketing and the source of new clients / patients.
Note: if you’re already using a stand-alone CRM and want to keep it, or if you’re determined - no matter what - to get a stand-alone CRM, that should be your decision. That’s why the new EHR / management system and vendor should be open to interfacing with CRMs such as Salesforce®, Sugar®, Zoho®, HubSpot® or any other commercially available CRM.
The hotline numbers advertised for treatment organizations almost never ring through to the organization itself. Most rely on 24 x 7 x 365 incoming call centers whose operators are trained to take these types of calls.
Depending on the call center, service might range from simply taking the person’s name and contact information for a call back from the treatment center, to the service obtaining the information needed for registering the person, and then actually scheduling the initial appointment, interview or tour of the facility.
Also keep in mind, an online portal should also enable scheduling an appointment and provide at least preliminary forms, releases and questionnaires which can be completed securely online. Often, an ability to schedule the initial appointment can be made as well.
Regardless of how your intake works, the information obtained needs to be turned into a preliminary or an “instance” patient / client record in the system. It should only become a regular system record once the person actually arrives for treatment or for their stay if it’s an inpatient center.
Until that point, the record can’t really be a record. Otherwise, the system becomes clogged with “dummy” accounts that have to be deleted, assuming someone remembers to do that.
On the other hand, instance records should be retainable in the system for as long as you choose to keep them, and be ready to activate if or when the person arrives.
So, intake needs to be part of the picture really from the initial call through to the person actually showing up. The system must accommodate each step correctly.
“Take in” and “intake” are two different things. Once the person walks through your doors and says “I’m here” they are now in “take in” mode. Take in mode should have its own, integrated automation capability attached to it through the facility’s main system: a kiosk.
Kiosks are used everywhere today: airports, train and bus stations, theaters, arenas, fast food outlets, governmental offices, and medical practices. Your facility can use kiosks as well as enabling patients / clients under any level of care to register themselves and complete any additional forms that may be needed, or any that weren’t completed by using the portal in advance.
Clipboards of paperwork that need to be manually completed by patients / clients and then manually entered into the system by staff are eliminated with kiosks. Kiosks also eliminate the handwritten list of people who’ve already registered which is sometimes inadvertently viewable at the front desk.
Kiosk functionality is actually available through a practice or facility-provided iPad®, or tablet / laptop PCs. It can also be accessible via a stationary desktop at a workstation. A secure kiosk system will shut down if the person using it is idle for 30 - 60 seconds.
Up to this point we’ve seen how a fully rounded electronic health records / practice management system may be used by an IP, PHP, IOP, or OP treatment facility for CRM purposes in tracking any marketing or advertising efforts, and then how the same system should be able to handle appointment scheduling, intake, and take in.
Next, we‘ll go deeper into using the scheduler as a workflow and yes, a financial tool. The scheduler has to handle patient / client appointments. Doing that is the essence of having a scheduler. But if that’s all the scheduler did, you’d be in trouble in a number of ways operationally and financially.
Operationally, you might want to schedule certain people on certain days based on their treatment reason, insurance, gender, date of birth, particular providers, or any / all of these (and even more) parameters. The scheduler should accommodate this type of “logical scheduling” approach, with “logical” meaning whatever is logical for your organization.
Using the scheduler in this way generally helps to create efficiencies in terms of the facility’s human and physical resources. Of course, it also helps keep things humming and on track, giving administrators and staff a bird’s eye view of “who’s where, and when” at any time. And by “who” we’re not only referring to patients / clients, but to providers as well.
The scheduler must support group as well as individual sessions or appointments, and be flexible enough to allow a specific patient / client to become part of multiple groups as established by the facility, and then for any one-on-one sessions for that person.
So…a highly visual scheduler really should provide a minute-to-minute encapsulation of everything that’s going on at any time throughout the facility while minimizing, if not eliminating, bottlenecks.
In other words, the scheduler should really be a workflow manager that also happens to connect patients / clients to their appointments, sessions or groups.
The scheduler should have a built-in capability for sending interactive appointment reminder texts whereby the recipient can confirm or cancel simply by replying as such. Ideally, either reply type would be automatically inserted into each person’s appointment on the scheduler. Cancelations would have an extra alert on them.
People who cancel can be called to reschedule, while others with future appointments may be able to fill in gaps keeping the schedule tight, resources humming, and revenue flowing.
We also said the scheduler should be a financial tool, and it should be, in a number of ways.
First, it would be fair to include appointment reminder texting under “financial” as well since it does work to keep missed appointments and no-shows to a minimum. So, texting really is an operational and financial scheduling asset.
Next, if your treatment organization assigns particular providers to patients / clients, it would be great if the system can produce immediate alerts on scheduling if the provider or any of the providers do not participate in the person’s insurance.
You’d be able to either immediately schedule a different provider(s), or you’d at least be able to make the person aware that the reimbursement payment(s) might go directly to him or her, and that he or she would be expected to make that payment to you...that the payment does not belong to the patient / client.
Next, next, the system must support an ability to batch verify eligibility of benefits through the scheduler in advance of services being provided, and issue red flag alerts (literally, on the scheduler) for any appointments with eligibility problems. You’d be able to contact the person enough days prior to the appointment so that any coverage issues can be corrected.
Next, next, next…as part of scheduling the appointment, how great would it be to provide a good approximation of what the patient / client will owe once insurance has paid? Very great.
Being able to alert the person right then goes a long way in empowering you to successfully obtain patient / client due amounts by avoiding surprises later. And, the approximation amount should be calculable when the person has more than one insurance. We’re talking about providing an approximation of their amount due once all of his or her insurances has reimbursed.
Additionally, any co-payments should also be displayed giving you a chance to remind the person about those as well while scheduling the appointment.
System alerts like these are invaluable in having the scheduler also act as a financial power tool that actually helps to protect your revenue in advance.
Whatever levels of service you provide, you need this type of system and built-in scheduler (not a second or third party piece of software). It also must be able to handle centralized or individual place of service scheduling depending on your preference.
You’ll be confident in knowing your assigned providers are approved, that incoming people have their coverage intact and that they have a good idea as to what they’ll owe, and that things will be operating at peak efficiency with streamlined workflow.
Now they’re receiving treatment which means you have:
All of these should be doable through the same single, unified system without requiring any outside programs, interfaces, and other vendors involved making things complicated and messy.
Let’s take each point in the order shown.
Regardless of the level of service, the EHR portion of the system should be used by facilities that are JCAHO and CARF assessed, be 2015 certified, and have a built-in MACRA dashboard for MIPS reporting if you are reporting, and the vendor should have a MACRA resource for assisting on reporting.
The EHR should be browser-based with mobility and connectivity linking your three “spheres of influence” neatly in a circle: your (1) patients / clients, (2) physicians / clinicians / therapists, and (3) the facility itself all via iPad, iPhone, Android, tablet, laptop, or desktop PCs.
Ideally, the EHR isn’t one-dimensional. It should be comprehensive and versatile enough to handle other related specialties such as internal medicine and neurology. Of course psychiatry is an assumed specialty.
The EHR should be versatile enough to handle any or all levels of care to the point where it will “travel” with the patient / client throughout their entire treatment with you even as their levels of care may change.
We already mentioned about the EHR having its own portal and kiosk which work to keep patient / clients engaged while empowering them to self-serve, and the need for integrated telemedicine.
Those are some general EHR / vendor requirements.
Now depending on the level of care, the EHR portion of the system must be able to properly handle capabilities such as:
We want to elaborate a little about telemedicine which is technology that’s no longer emerging. It’s actually become mainstream for the psychiatry / behavioral health / addiction treatment industry. Ideally, it should be an inherent part of the EHR…not an added-on, outside product that needs to be interfaced, or that’s “powered by” another company. You want it “powered by” the EHR and its own vendor.
What exactly should telemedicine visits accomplish?
They should be reimbursable, and today, they are in almost every state. Being reimbursable, they’re excellent for generating revenue by enabling providers to see more patients and clients without expending any physical resources since the telemedicine waiting room is virtual.
Assuming the EHR supports it, visits are bi-directional and face-to-face, and can be conducted securely from anywhere in the world using an iPad, iPhone, or Android.
And, telemedicine appointments should be schedulable the same way in-office or in-facility appointments are scheduled.
The unified EHR and PM should handle telemedicine scheduling, the CPT codes needed for telemedicine encounters, and the encounters themselves all as incorporated capabilities without requiring any “powered by” pieces.
Now that the encounter, treatment, or session has happened either live or via a telemedicine visit, the financial side of the system needs to get that information as the first step in being paid.
Again, if the EHR and PM are within the same system, then getting the billing data to that side is (or should be) clean, immediate and essentially hands-free. It should just know to go.
Once it’s there, the system now must be enabled to submit it without requiring manual intervention, assuming that’s what you want. In that scenario, claims - whether HCFA or UB - are continually being submitted without holding them until a certain number of them have accumulated.
If the person has more than one insurance, the system must be intelligent enough to know that as soon as reimbursement from the first payer is posted, it will now be submitted to ensuing payers in the same cascading format, all automatically without requiring any hands-on assistance.
By the way, you’ll want to identify a system that submits claims with a nearly 99% success rate on first attempt HCFA and UB clearinghouse claims, and which maintains that rate as balances cascade for those who have more than one insurance.
As for posting, the system must support an automated way to reconcile EOBs through electronic remittance advices (ERAs).
Then as soon as a balance become the patient’s / client’s responsibility, the system must know to generate a statement showing exactly how the balance due was arrived at, and with that balance as “current” regardless of how long it took insurance(s) to reimburse.
Statements should be system generated but even better, an offsite statement production resource would be available to economically produce and send statements eliminating you from having to print, fold, stuff, seal, affix postage and mail. You’d also save on paper, envelopes (two per statement), cartridges and printer wear and tear. Generally offsite statements would cost only pennies more each than the postage.
Reminder that if the portal supports it, patients / clients can make their payments securely online through it.
This entire claim submission-to-reconciliation-to-patient / client statement must be automated and free flowing. It should be a perpetual motion routine that no one needs to think about, because it’s an incredibly huge factor in generating revenue from insurance and patients / clients.
All of that said, there are other things that should be enabled that put you firmly in the driver’s seat once claims are submitted.
The first thing is claim tracking in real time. You’ll want that in order to ensure your claims aren’t idling unworked. If you see any that are, you’d be able to nudge that payer to find out why there’s no activity on them.
It works in your favor when payers know you have a way of seeing what they’re doing, or not doing.
We mentioned the importance of having a nearly 99% success rate on claims. That’s because 100% just isn’t possible. And because of that, you’ll want a system that has a quick, on-the-fly method of handling denials.
Ideally, you’d be able to see your denials and their reasons for being denied, make the needed edits, and resubmit them all from one window view quickly turning them into revenue as well instead of having what can be thousands, or tens of thousands of dollars’ worth of denials sitting unworked simply because they’re too unwieldy to deal with.
Having that type of capability is great, but what’s even better is when the system can issue pre-submission alerts on claims likely to be denied based on the payer’s history. With that, you’d be able to re-code those claims proactively, then submit them avoiding what would likely become denials.
So, having a great denial manager is an excellent system feature, but being able to proactively avoid denials or dramatically minimize them is even better.
Claims with a high first time success rate. EOBs via ERAs. Statements. Claim Tracking. Denial Management. These all work to keep cash flow flowing.
And remember, all of this should be doable in one, integrated solution that includes the EHR as well. Just need to keep reminding about that! One system, one vendor, one overall solution.
The system needs financial intelligence to help ensure you’re not wasting time needlessly. One simple yet powerful example of that is when it remembers the average length of time it takes for insurance carriers to pay.
If a certain insurance payer never pays before 37 days on average, does it make sense to try to collect at day 25? You should be able to process a report showing your insurance payers’ average length of time to pay, and any claims for each that have now exceeded their time periods. You’d focus on those and not waste time with the others.
Remember that you should also have claim tracking which helps in displaying your unpaid claims and their status.
Tools like these help make things more efficient and less unproductive.
You’re there to help people overcome terrible situations and move on with their lives, families, friends, and work. It’s perhaps the noblest of all endeavors.
At the same time, you’re operating a business which means you need to know how things are going operationally, financially (even if you’re a not-for-profit), and on the clinical side, clinically.
You want that data to be intrinsic from within the system (again, the one system that handles everything) without requiring expensive and clunky outside report generators, interfaces, and months of training on how to compile reports.
On the clinical side, you need to compile reports on things such as outcomes, population health, medications prescribed including clinical trials, laboratory results, allergies, social criteria (married, smoker, etc.), and then no doubt with diagnoses, procedures, gender, age, perhaps “from” and “to” time periods, and so on blended in.
The parameters for clinical reports are almost endless, and the EHR should provide an unlimited ability to create the reports you need, and then display them in a variety of user-defined formats.
Really, the expression that best describes this type of clinical reporting is the very unscientific “easy peasy.”
For operations, you’ll want to know about productivity, practice or organization analysis, numbers of encounters / visits perhaps by payer and within specific time periods, “no show” reports for appointments, encounter intake times vs. appointment times to see how on or off track wait times may be and then perhaps to include provider names to see if any in particular stand out.
You’ll want to track referral sources whether they’re through the person’s physician, or as being recommended by a previous patient / client, or through any marketing or advertising efforts, etc. As mentioned, the system should have its own CRM functionality which does this type of reporting.
If you have certain resources or diagnostic equipment dedicated to specific encounter or visit types, you’ll want to generate utilization reports on that.
For IP facilities, any reports needed regarding bed management should be available directly through the system’s built-in bed management section.
On financials, you’ll want to know receivables by insurance and by patients / clients, which insurance payers are paying the highest and lowest based on specific procedure or facility utilization, how long it takes for each payer to reimburse (as already described), payments received and by source for any specific time period.
If you’re reporting on MIPS - which also has an operational element to it - you’ll want to know how that’s going, the thresholds being met by providers, and if you’re on track at least to avoid penalties and to perhaps also obtain incentives.
You should be able to do that kind of reporting if the system has a built-in MACRA dashboard culling the needed data as it's happening.
Hundreds of user defined financial and operational reports and KPIs should be exportable to Excel®.
Reports must be able to be created and saved by user, and then be set to automatically compile at specific times (daily, weekly, day of the week, hour of the day, etc.) in a “set it and forget it” approach eliminating having to remember when they’re needed and what parameters or filters are required for each.
In general, specific data points on a report should be able to be drilled-into for more details on that particular item.
Lastly, all reports should be compilable by specific location, specific provider or tax ID (more on that follows), specific patient / client type, etc. or by any combinations of these parameter types, or by all in a roll-up reporting approach across the entire enterprise.
Saying it again: everything mentioned here on reports should all be doable directly from the system without requiring outside vendors or add-on components other than Excel which you probably already have anyway.
With this type of reporting and data mining capability, your practice, treatment center or network is very much empowered to operate like the business it really is.
Shakespeare would’ve never said it like that, but the idea is the same. You definitely need at least one tax ID. If so, that’s fine. Obviously the system should have no problem with that.
What if you need more than one? Maybe dozens? The system should support whatever is your number. In fact, it should be able to support an unlimited number of them.
They absolutely help keep things in the system neatly segregated with patient / client data that should only be in a certain tax ID(s) out of view or access by anyone not having authorized entry into that tax ID(s).
System operators shouldn’t have to continually log out of one tax ID in order to log into another. Instead, operators should be able to easily flip between all of the tax IDs to which they have authorized access.
And, it should be easy to insert a person’s data from one tax ID into another if that person also becomes assigned to another provider. You shouldn’t have to re-enter all of that data.
As already mentioned, system reports should be compilable by a particular tax ID, or by multiple tax IDs, or by all of them.
Sometimes organizations need to have themselves be more rigidly segmented in the system, perhaps by location or by type of service, or perhaps under a different operating name. When this happens, you shouldn’t be required to get an entirely new system for each if directories are available.
Directories are essentially like having additional copies of the software. And they can also have their own unlimited number of tax IDs for providers within each directory.
Think of them as separate apartments in an apartment building with each apartment having multiple residents. Everything is all together in the building, but segmented within it.
Now imagine the apartments having connecting doors between them which can be opened if or when needed. In other words, directories and their content can also be viewable across the enterprise, and you might even need to have the data in tax ID #4 in directory #2 be inserted into tax ID #6 in directory #3. No problem.
As with tax IDs, entry into directories is also limited to only those having authorized access to them, and reporting should be doable by directory/ies.
Here’s another visual: a big bowl of spaghetti with your favorite accoutrements thrown in all mish mashed together. That’s one system scenario you don’t want. The scenario you do want is the apartment building which is exactly what your system should support.
Rule #1 on implementation is this: you want the system deployed the way you want it, not the way the system or vendor wants it, because there really are many variations assuming the software and vendor are versatile enough to accommodate them.
What we’re saying is this: the systems needed and the way they’re deployed must be your call. If you’re being swayed or pressured into something you don’t want, that’s not good.
Outsourced revenue cycle management actually presents yet another implementation type but of course, goes much deeper than simply how it’s implemented.
RCM does work best via the cloud since it needs to make its clients’ data available to their clients at any time, and for that, cloud is ideal.
A few RCM clarifications and highlights:
What if an EHR isn’t wanted or needed? It would be unusual for sure, but what if? The RCM company should have an electronic superbill that supports “grabbing” and transmitting encounter or visit data to the RCM company’s system for billing.
So whether you’d want to use the RCM company’s EHR, your existing EHR, or no EHR, any of these scenarios should be accommodated by the RCM company.
Regardless if you’d want to have your own in-house system in the cloud, or on your servers, or if you prefer engaging with an RCM company, any of these should be your choice.
And if you identify a vendor and system that provides all of these choices, all together in one system and under one umbrella with zero finger pointing, that seems like a best of all worlds solution worth exploring.