ANNOUNCER: Centers for Medicare and Medicaid Services 2019 CMS National Provider Compliance
Conference, Keynote – DRLS, Melanie Combs-Dyer, Director, Provider Compliance Group, Center
for Program Integrity, Centers for Medicare and Medicaid Services.
MELANIE COMBS-DYER: I'm Melanie Combs-Dyer.
I'm your Keynote Speaker today.
I work for the Center for Program Integrity at CMS.
The DRLS or the Documentation Requirement Lookup Service is what’s going to allow
providers to discover the prior authorization requirements or the other documentation requirements
right at the time of service and right in their EHR or Practice Management System.
The goals of the DRLS program are to reduce provider burden, reduce improper payments
and appeals and to help improve the provider to payer information exchange.
Why is CMS interested in this?
Well, we have gone out on a listening tour.
I have toured much of the country, sometimes with others from CMS, sometimes with others
from the Office of the National Coordinator for Health IT or ONC.
And in those listening sessions I’ve heard a lot from providers about, gee, I really
think that the CMS requirements are excessive.
Well, I'm taking that back to our patients over paperwork team and our documentation
requirements simplification team.
I’ve also heard that providers are really afraid of audits.
And we’ve brought that back to the team and created the Targeted Probe and Educate
program and made some enhancements and changes to our recovery audit contractor program to
try to make them a little bit less scary.
But the one in the middle here, the documentation requirements are too hard to find, that was
one that really was tough for me.
I really heard it over and over and over again from providers.
Here’s what the AMA had to say.
Gee, we really wish that payers would publicly disclose in a searchable, electronic format
all of their requirements and what supporting documentation is needed for the provider to
make sure that whatever it is that they’re providing to their patient or they’re ordering
for their patient is going to be paid for.
This is a depiction of what the DRLS system will look like once it gets fully created.
Remember it’s not just Medicare fee for service program that has documentation requirements
that you the provider are trying to comply with.
There are Medicare Advantage plans.
There are Medicaid plans.
There are private health insurance plans.
And everybody has their own set of requirements for prior authorization or what needs to be
documented in the medical record.
The beauty of the DRLS mechanism is that it will allow the provider to discover right
in the EHR, right at the time of service what the rules are for the thing that they’re
about to order for their patient, regardless of what health insurance the patient has.
That’s what’s really cool about the DRLS system.
I really do think that this is an exciting program.
Let’s walk through just for a second how this DRLS mechanism will work.
The graphic depicts the provider interacting with their EHR, their Electronic Health Record,
probably at the time of service.
Maybe the physician is having a visit with the patient and evaluating their respiratory
needs and recognizing that this patient is going to need oxygen, they’re going to have
to write an order for oxygen for their patient.
They might wonder, hmm, I wonder if this patient’s insurance company requires prior authorization
for oxygen?
They’ll be able to push a button in their EHR and a transaction will go out and it will
ping the appropriate repository.
If it’s a Medicare fee for service patient it will ping the repository depicted in the
upper right-hand corner.
That’s the Medicare fee for service repository of rules.
If it’s a Humana patient or a United patient, it might ping one of the other repositories.
And it will come back and display to the provider, again right in their EHR, yes, there are prior
authorization requirements or no, there are not prior authorization requirements.
Or, yes or no, there are or are not documentation requirements.
In the case of oxygen if it was a Medicare fee for service patient it would say, no,
there are no prior authorization requirements in the Medicare fee for service program for
oxygen, but, yes, there are documentation requirements for oxygen in the Medicare fee
for service program.
The provider would then have the option to hit a second button that says, show me the
documentation requirements and if there are any templates that CMS has produced for oxygen
and what needs to be documented in the medical record.
Again, the transaction will go out and it will ping the appropriate repository, in this
case the Medicare fee for service program and it will return a card, a little list of
the documentation requirements for that particular item or service that the doctor is ordering.
You can also see from this graphic that the Medicare fee for service repository of rules
is also connected to the DME fee schedule, because there’s another really important
piece of information that the provider might want to know when he or she is getting ready
to write an oxygen order for their patient.
They might want to know how much is it going to cost my patient.
Price transparency is really important these days.
And this is one way that CMS is working to make that information available to providers
so they can share it with their patients.
Here’s what that card might look like coming back to the provider in the EHR.
Here are the five things that the doctor needs to make sure that they document in the Electronic
Health Record to ensure that the oxygen is going to be covered by the Medicare fee for
service program and here are the prices, the copays that the patient may have to pay.
CMS has hired Miter (ph.) to help us develop our DRLS system.
And they’re doing it through something called the Da Vinci Project, which I’ll be talking
about momentarily.
Miter and the Da Vinci Team are creating implementation guides based on FHIR standards.
FHIR stands for fast, health care, interoperability resources.
FHIR.
That’s what lets all that information go back and forth to different payers, but because
it’s all structured the same way, because we’re all speaking the FHIR language, all
that information can go back into the provider’s EHR and it can make sense.
We’ve also tasked Miter with creating reference implementations.
Those are sort of prototypes, little practice sessions.
We actually did a prototype demonstration when we were at HIMS (ph.) this year and showed
how an EHR could go out and ping various repositories of payer rules and display back into the provider’s
EHR what the rules were and in the case of Medicare fee for service what the price was
that the patient would have to pay.
We’re also planning to launch real world pilots.
We are looking to identify a number of providers who want to try to test this system with us.
We will use dummy data at first and then we will move into using real patient data in
our pilots.
So let’s talk a little bit more about Da Vinci.
What is the Da Vinci Project?
The Da Vinci Project was convened by HL7, Health Level 7.
It’s a standards development organization.
And the goal of this industry led effort is to try to produce very rapidly mechanisms
that will allow for the exchange of information between providers and payers or between two
providers.
We hope that this will help minimize the development time.
If I developed a solution and United developed a solution and Humana developed a solution,
providers would have to find a way to connect with all of us using our different solutions.
But because the Da Vinci team pulls us all together you can see there at the bottom of
the screen there is 12 separate payers who’ve all come together to help form the Da Vinci
team.
Ten HIT vendors, three EHR vendors, including Epic and Cerner (ph.).
Six providers so far, and the numbers are increasing.
Because we’re all working together we’ll be able to create things that will be seamless
for a provider to interact with a number of payers at the same time.
The Da Vinci Project is not just working on the standards that will support DRLS though.
The two standards that are supporting the Documentation Requirement Lookup Service are
circled here in red.
They’re called the Coverage Requirements Discovery, that’s the place where the doctor
can hit the button and see are there prior authorization requirements or documentation
requirements, yes or no?
And another standard called the Documentation Templates and Coverage Rules.
That’s what sends back to the provider here’s what the rules are.
Those two use cases are really exciting and I’m glad that I'm part of the Da Vinci team
to help develop them.
ANNOUNCER: Centers for Medicare and Medicaid Services.