Thread by @motorcycle_guy

OK, now it's time to review @AMugge's rule, more formally titled: Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients’ Electronic Access to Health Information for...

Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-facilitated Exchanges; Health Information Technology Standards and Implementation Specifications

A title so long, it fills two tweets.

Simplified it's the second full length novel in the Payers on FHIR series from CMS, subtitled the Beginning of the End of EDI

If you followed this series from the starting novel: The Patient Rises (aka, the Patient Access Rule), you are aware that CMS has learned to spell FHIR too. Which they go on to do 252 times, about 1.3 pages / reference

FHIR as a protagonist is a great character, and has a name that you can even pronounce. It's a lot better than past protagonist Extwelven, which sounds like something vaguely out of Tolkien but with a Russian accent

The main action starts on page 291, but let's start at the beginning, because there's going to be a long build of tension here, then a really tedious section on cost / ROI which I might actually read (I don't always, but here it matters).

The first mention of FHIR is on page 4.

improving [data] exchange & achieving appropriate & necessary access to complete health records for patients, providers, & payers (PPP), while simultaneously reducing PPP burden by improving prior authorization processes, & helping to ensure that patients remain at center of care

Prior auth is that nasty, time consuming, annoying thing your doc (usually his/her staff) has to do to make sure that you will be covered by insurance for stuff payers don't like to pay for b/c it's expensive. It's an essential component of Fee For Service cost containment ...

CMS wants to make this more effective for Medicaid, CHIP, QHP (with some exclusions for SADP/SHOP and those on SBE-FPs [whatever those acronyms mean, you know who you are])

Which leads me to editorializing on the CMS series, b/c frankly, there's too damn many characters to follow. Like what happened to that Medicare Advantage guy we saw in book 1? Why isn't he here?

And why does every single one of these characters go through a slight variation of the same thing and have similar but not quite the same experience. Honestly, I want to write a whole nother post on "there can be only one [single payer]"

If you thought the HIPAA rule's 1.32 million dead tree count on notice of privacy practices is high, just think about the number of trees that could be saved if we could combine all these different CMS payment programs into a comprehensive payment solution with common rules...

CMS conforms on page 10 that the Medicare Advantage character isn't going to be showing up in this novel. But MA plans can use these APIs voluntarily.

There's at least three different kinds of APIs in this rule:
* Patient Access
* Provider Access
* Payer (to Payer) Access

Sorry, suffering from COVID-19 pandemic response interuptus on at least two different attack fronts, back to the CMS Rule...

<3 when CMS defines a term like "churn":
“Churn” in health care refers to the movement of patients between payers & in & out of health care coverage. Churn occurs when a patient moves between payer types & plans or dis-enrolls ... (voluntarily or involuntarily) for a period...

I dunno, it just makes them seem so human, to have to justify the use of a term like churn. I mean, it's got a professional definition (e.g., en.wikipedia.org/wiki/Churn_rate), but it is also raw and earthy

And next they have to explain “patient”, “consumer”, “beneficiary”, “enrollee”, and “individual.”
And then “payer”, “plan”, and “issuer”,
then “items and services”
and finally “provider” and “supplier”...

At this rate we could frankly be here all day but worry not,

B/c now they are going to tell you what they are going to do:
* Propose some things (rules)
* Ask some questions (requests for information)

It's all very educational in its approach...

CMS is proposing to enhance the Patient Access API for impacted payers by requiring the use of specific IGs, proposed for adoption by @ONC_HealthIT [so some of this early Christmas present is to ONC's credit/fault]

& are proposing to require that impacted payers establish, implement, & maintain a process to facilitate requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions

Wait, what? What does that actually mean? We'll come back to that, I don't really know yet, but it sounds important and all like security/privacy kind of stuff that you need your best people on ... yeah, you probably do ...

& payers to report certain metrics about patient data requests via the Patient Access API quarterly
& to require use of a specific IG for Provider Directory
& to extend patient-initiated Payer-to-Payer Data Exchange requirements to state Medicaid & CHIP FFS programs.

& to enhance and expand the Payer-to-Payer Data Exchange,
& to require this exchange be conducted via a specified FHIR API
& payers must implement and maintain a Payer-to-Payer API to facilitate the exchange... between ...payers w/ approval & at the direction of the patient ...

& and when [churn happens], & in accordance with applicable law.

Specifically, we are proposing that impacted payers implement the Payer-to-Payer API ... with FHIR R4, as well as the HL7 FHIR Bulk Data Access (Flat FHIR) specification...

... to support exchanging patient data including but not limited to:
* adjudicated claims and encounter data (not including cost information),
* clinical data as defined in the USCDI, and
* information related to pending and active prior authorization decisions.

Provider API = FHIR R4 and USCDI ...
CMS demonstrated & payers are expected to implement and maintain a similar prior authorization Documentation Requirement Lookup Service (DRLS) API.

FHIR-based Prior Authorization Support (PAS) API

OK, so to make a long story short, Da Vinci specs = WEDI on FHIR, and they are burning it up with CMS.

I feel a blog post coming on, working title: EDI is dead. Long live EDI on FHIR.

Finally, on behalf of HHS, @ONC_HealthIT is proposing to adopt the implementation specifications described in this regulation at 45 CFR 170.215—Application Programming Interfaces—Standards & Implementation Specifications as ... specifications for health care operations.

Hmmm ... thinking this through if EDI is dead, what happens to NCVHS, and do we still need it or could some of its functions be merged with HITAC? Now there's a can of worms nobody wants to look at ...

Because if it's all health care and communication between health care covered entities supporting interoperability, why should we have more than one ...

Climbing out of that rathole (it's pretty deep)

@ONC_HealthIT is proposing these ... specifications for adoption by HHS as part of a nationwide health [IT] infrastructure that supports reducing burden and health care costs and improving patient care.

"By ONC proposing these ... specifications in this way, CMS and ONC are together working to ensure a unified approach to advancing standards in HHS that adopts all interoperability standards in a consistent manner, in one location, for HHS use.

... Once adopted for HHS use, these specifications would facilitate implementation of the proposed API policies in this rule if finalized."

So yeah, maybe this really was an end run around the whole EDI / HIPAA transactions process ... hmmm...

... Although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement these proposed provisions, if finalized. ...

... the Medicare implementations would conform to same requirements applying to ... payers under this rulemaking ... Medicare FFS beneficiaries would also benefit. & we encourage others ... not directly impacted by this rule to join us in moving toward reduced burden & > interop

Several RFIs for more rules:
Should patients & providers have granular access controls wrt data

Can APIS support behavioral & community based care w/o EHRs

Enable > use of prior auth for those benefitting directly in their workflows

How can we kill faxes

UR thoughts on SDOH

Patient Access API proposes The CARIN IG for Blue Button, the PDex IG, and the PDex US Drug Formulary IG are proposed for HHS use at 45 CFR 170.215(c). The US Core IG was adopted by HHS at 45 CFR 170.215(a)(2) in the ONC 21st Century Cures Act final rule.

we propose to amend [a bunch of stuff] to provide that, if finalized, regulated entities would be permitted to use an updated version of any or all IGs proposed for adoption in this rule if use of the updated IG does not disrupt an end user's ability to access the data ...

we are also proposing to require that information about prior authorization decisions be made available to patients through the Patient Access API

"... this proposal would help give patients more agency in their health care journey and reduce burden on both the providers and the payers working through prior authorization requests,"

Throughout the final rule, we noted the limitations to our authority to directly regulate third-party applications ... We are now proposing to make it a requirement that ... payers request a privacy policy attestation from 3rd party apps to connect to the Patient Access API...

we do not wish to be overly prescriptive regarding how each payer could implement this process. For instance, a reliable private industry third party may offer a pathway for apps to attest that they have established a minimum set of privacy provisions to be in compliance ...

Regardless of this proposed flexibility, impacted payers must not discriminate in implementation of this proposed requirement, including for the purposes of competitive advantage.

Whatever method a payer might choose to employ to meet this proposed requirement, the method must be applied equitably across all apps requesting
access to the payer’s Patient Access API.

All that to say, there will be some way to attest to privacy, we aren't going to say how, it should be automatic, and fair and accessible to everyone.

I think there's a tremendous opportunity here for next generation QTF to specify how to do this technically a bit better...

payers can look to industry best practices, including the CARIN Alliance’s Code of Conduct and the ONC Model Privacy Notice for other provisions to include in their attestation request that best meet the needs of their patient population ...

Still feels a bit weak here on guidance and approach. It's a good start, but not a finished solution. I'd like to see a bit more leading this horse to water, unfortunately, locations of water aren't provided in this rule, which means they won't get to it IN THIS RULE.

We are proposing to require impacted payers to report metrics about patient use of the Patient Access API to CMS.

Specifically, we propose that these payers report quarterly:
● # of unique patients whose data are transferred via the Patient Access API to a patient designated 3rd-party app; &
● # of those whose data are transferred via the Patient Access API more than once.

We do not intend to publicly report these data at the state, plan, or issuer level at this time, but may ... publish them at an aggregate, de-identified level. We are proposing that by the end of each calendar quarter, payers would report the previous quarter’s data in '23

beginning March 31, 2023 all impacted payers would need to report to CMS the first set of data, which would be the data for October, November, and December 2022.

Patient API redefined from “clinical data, including laboratory results.” to become “clinical data, as defined in the USCDI version 1 (which includes labs).

Minor language changes made to support reuse of content wrt to discontinuation of of access, across Patient, Provider, Payer API sets.

Another "Although Medicare FFS is not directly impacted by this rule, " we do note that they can take advantage of our direction...

And I might add, CMS could regulate FFS in future so pay attention NOW and be ready...

Blue Button to become the CARIN IG Flavor, which is good, because it takes it out of government crafted (CMS) specification space and moves it into publicly defined standards space.

we are proposing that the Provider Directory API be conformant with the HL7 FHIR Da Vinci PDex Plan Net IG: Version 1.0.0. hl7.org/fhir/us/davinc…

Warning, warning, this is a plot complication ...

That's an odd duck, and CMS (and ONC) are usually more careful. They've referenced this guide as if it's a published standard "FHIR Da Vinci PDex Plan Net IG: Version 1.0.0.", but the footnote references hl7.org/fhir/us/davinc…

Here's why that might be a foul ball: It's NOT an HL7 standard or even STU yet (though it is an HL7 published document). It might be one by the time the rule is finalized, but the version number cited does NOT in fact exist (though it might very well soon).

I'm thinking this one is headed for the foul line and will hit it fair, but that's a pretty narrow margin. I'm not quite sure how you can cite something by reference without it actually existing.

To be fair, there's a reconcilliation package, the content passed ballot, and the last steps are to make edits, get approval for publication, and publish, so it's probably VERY close to done. In fact, it might just be missing that last step.

Somehow I though I'd scrolled in the wrong direction, because it felt like I was reading the same thing again. It's sort of like one of those novels where the same thing happens to different characters over and over again.

First the patient needs access to the Patient API, now we're onto the provider, who needs access via the Provider API.

...the Patient Access API is a significant first step ... we believe the benefits of making patient data available via ... API would be greatly enhanced if providers had direct access to their patients’ data.

"While we have no data, we anticipate that putting patient data in the hands of the provider at the point of care would reduce provider burden and improve patient care" No data? Let me help with that: himss.org/resources/deve…

Now, clearly that's a clinical example, rather than a payer based example, but go talk to some of the people on the EHR side of that white paper, I can tell you they've also got some experience sharing data with payers to identify gaps in care.

HHS has not adopted a HIPAA transaction standard for communications of claims or encounter data that are not sent for the purpose of requesting payment ... and so CMS can pick one and is allowed to use FHIR for the aformentioned, heretofore and otherwise preceding paragraphs

In other words, there's nothing saying CMS cannot use FHIR, and so they did (and good for them).

Through a proposed cross-reference to the Patient Access API requirements, the Provider Access API also requires adherence to the same technical standards, API documentation requirements, and discontinuation and denial of access requirements.

Translated: Provider and Patient APIs are the same. We have to have different names for them b/c there are different policies based on usage, but underneath, a rose is still a rose by any other name.

Someone else will have to translate this next bit: In the context of Medicaid managed care, we are proposing that NEMT PAHPs, as defined at 42 CFR 438.9(a), would not be subject to the requirement to establish a Provider Access API. MCOs, PIHPs, & non-NEMT PAHPs are in this rule.

Someone else will have to translate this next bit: In the context of Medicaid managed care, we are proposing that NEMT PAHPs, as defined at 42 CFR 438.9(a), would not be subject to the requirement to establish a Provider Access API. MCOs, PIHPs, & non-NEMT PAHPs are in this rule.

It's an alphabet soup of program participant entity types, that part I get. WHY this needs to be so complicated I never will. I'm just hoping to God that when and if we get to single payer, it's also SINGLE program, or we'll be in the nearly the same place we started.

If giving entities access to data a patient at a time is good, giving to them in bulk is better, and this is why CMS wants to standardize on "Flat FHIR", other wise known as FHIR Bulk Data Access.

Payer's do batch, not real time. And they often need to do batch with each other, especially to exchange data about past prior auth decisions and other stuff.

And so as a payer you'd have to implement payer APIs using FHIR Bulk by 1/1/2023

If you are a state program, there's a list of ways CMS is showing you that can help you pay for implementation starting on page 60. Yeah, sorry, it's going slow, only about 20% through.

We are therefore proposing that each payer establish, implement, and maintain for itself, a process to facilitate generating each provider’s current patient roster to
enable this proposed payer-to-provider data sharing via the Provider Access API.

That sounds a bit like tough slogging: ...as one example, we are planning to test a process that allows for the provider to add their active patients to a roster through self-attestation, further checked against claims to verify the provider has furnished services to the patient

proposing 42CFR431.61(a)(2) for Medicaid FFS
@ 42CFR438.242(b)(7) to comply to 42CFR431.61(a) for Medicaid MCPs except NEMT PAHPs,
@ 42CFR457.731(a) for state CHIP FFS,
@ 42CFR457.1233(d)(4) to comply w/ 42CFR457.731(a) for CHIP managed care
@ 45CFR156.222(a)(2) for QHP on FFE

Parse error at line 4, @ expected.

In other words, trying to boil that down to its essentials shows how tight a rope a CMS program entity participant must walk through the regulatory digital paper.

We are proposing that payers make educational resources available to providers that describe how a provider can request patient data using the payer’s Provider Access APIs in nontechnical, simple, and easy-to-understand language.

I am proposing that CMS make education resources available to normal humans that describe how a person can understand what the heck all this stuff is in a non-jargonish, simple, and easy to understand language.

If a state believes it has a need for an extension due to trying to understand or implement any of this, it should read page 68.

I'm gonna skip the rest of these exceptions b/c my brain just blew a gasket. CMS stuff is so much harder than ONC b/c there are so many programs trying to fix what's not working, or that which needs support or ...

on to Prior Auth: American Hospital Association (AHA) described the ongoing impact of prior authorization on patient care, health system costs, and burdens.

Here I would say that Prior Auth is mostly only essential in fee for service programs. Get rid of that, and the need for Prior Auth goes away, only to re-emerges as "where can I get that prior diagnostic report NOW"

This is what Grahame Grieve talks about with respect to "whack-a-mole" approaches to simplifying complexity. But what I like about the re-emergence of the problem is that it is no longer disguised as an overpayment/excess cost issue.

one of the most highly burdensome parts of the prior authorization process for <del>payers and providers</del><ins>patients</ins> include identifying the payer rules and determining what documentation is required for an authorization

reminder to CMS, while payers and providers are bitching about the pain, patients are the ones who are actually LIVING THROUGH PAIN while this happens. Just saying.

And yes, it is in fact pretty complex. There's no damn guidebook, and you can only see snippets of it as a provider so that you cannot game the payer, and the patient can never see it ever.

</rant>

we propose that, beginning 1/1/23 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after 1/1/23), state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, & QHP issuers on the FFEs...

implement & maintain a FHIR-based Documentation Requirement Lookup Service API conformant with the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG: Version STU 1.0.0 and the HL7 FHIR Da Vinci Documentation Templates and Rules (DTR): Version STU 1.0.0 IG

impacted payers implement a Prior Authorization Support API that facilitates a HIPAA compliant prior authorization request and response, including any forms or... documentation required by the payer for items or services for which... is seeking authorization.

I hate it that we have to move so awkardly around the HIPAA transactions rule to make this work. It's a kludge.

The PAS API would provide an opportunity to leverage the convenience of API technology, while maintaining compliance with the adopted HIPAA transaction standard.

And if that is the only reason for its existence, maybe the HIPAA transaction standard for prior auth needs to die, and we could just start off all over again. There is SO much complexity working around the HIPAA transactions to make the process work

"We are aware that the flow of the payer API may not be intuitive to all readers, therefore, please refer to the implementation guides for payer API flow details." -- Putting it mildly.

And here's the kicker on why current Prior Auth should die according to the proposals in this regulation:

"we are proposing that impacted payers implement a Prior Authorization Support (PAS) API that facilitates a HIPAA compliant prior authorization request and response"

In other words, Payers should build a FHIR based API that translates what you get in FHIR to an X12 278 transaction, w/ appropriate 275s for extra content you need, so that the required HIPAA 278 transaction is used.

But if PAS is really so much better for prior authorization, and if payers are as interested in using it as the Da Vinci project would seem to imply, aren't there other regulatory levers that can or even should be pulled?

But I digress:

Basically: CHIP FFS and Managed Care entities, Medicaid FFS and MCPs, and QHPs of FFEs are expected to implement the HL7 FHIR Da Vinci Prior Authorization Support by 1/1/23.

The next proposal addresses streamlining denials. CMS "proposes that impacted payers transmit, through the proposed PAS API, information regarding whether the payer approves (and for how long), denies, or requests more information related to the prior authorization request."

b/c (in part) "payers do not provide consistent information about the status of a prior authorization or the reasons for a denial, nor do they use the adopted X12 278 HIPAA standard transaction to communicate prior authorization status information"

This is yet another section of the rule that basically says "278 is a failure", we need to replace it.

I'm completely, totally behind this idea. However, it seems that CMS is using one set of authorities (21st Century Cures) to void and/or circumvent another (HIPAA transactions)

That seems to be destined to blow up in CMS's face, and I hope and pray that they have a plan to address this when it does, and a way through the regulatory/legal tangle that will result from it. Because PAS is a much better way than 278 to handle prior auth.

"a prior authorization is currently only a determination by a payer that an item or service is medically necessary, & is not a promise of payment"

Here's MY challenge: The definition of authorization is the granting authority, essentially saying "yes, you can do this"

merriam-webster.com/dictionary/aut…

So CMS is requesting input on "what would be included in a new policy, and the potential costs of such a policy on payers ...what requirements would be appropriate to include in a policy to ensure that claims that meet certain guidelines for approved authorizations are not denied

What bugs me here is the focus on costs to payers, and not on costs to patients and providers if such a rule was to be implemented. Because the economic benefits of eliminating a double decision on a payment accrue to all those parties.

A denial of a claim that was prior authorized, will likely suck an hour at least from the patient, provider and payer side in time from individuals trying to address the issue when it is fought. And this isn't computer time, this is people time, the most expensive.

A lot of that people time is truly wasted time. It goes like this:

So "We also seek comment on whether all payer types should be required to comply with a policy to prohibit payers from denying a claim for payment after approving a prior authorization for covered items and services... " [Hell YES!]

Sadly: "If we were to address these topics, we would do so in a future notice and proposed rulemaking."

But at least they'd do something, so make your comments!

Next up is timeframe: "The AMA study reported that 28 percent of physicians stated that delays in care due to the prior authorization process, specifically the wait for approval, led to serious, life-threatening adverse events, including death, for their patients"

I can tell you that my wife spent an extra day in the hospital awaiting prior authorization for rehabilitation, after being thrown from a horse and breaking a rib and other bones.

Which delayed getting into the rehab queue, which delayed getting into rehab probably another day.

Of course those hospital days were paid by insurance.
Minus our copay for two days, and the additional two days lost wages? Nope. Was rehab provided in the hospital? No.

What I find somewhat remarkable is that most of CMS questions regarding this are addressed to payers and providers. What about patients? I think patient organizations need to make themselves heard LOUDLY on these prior authorization questions.

"we request comments on the impact of proposing a policy whereby a payer would be required to respond to a prior authorization request within the regulated timeframes, & if the payer failed to meet the required timeframe, the prior authorization would be automatically approved."

"We propose to remove the option for states to follow existing state law regarding prior authorization of health services, requiring states to instead follow these updated timeframes. [but states are not prohibited from being more stringent]"

Skipping the various exceptions for programs, but there are a few pages worth on these topics. I don't have the background to understand the CMS alphabet soup of programs well enough.

Gold-carding: The practice of allowing providers that have demonstrated quality care to skip some prior auth requirements is encouraged by CMS, and is proposed to be included as a factor in quality start ratings.

Moving on to Payer to Payer b/c the rest of the Prior auth is not really about interop, but more about patient rights to hearings and communications, all of which I think I will comment on as a patient, but later.

Payer to Payer used the FHIR Bulk Data APIs to enable sharing between payers. It allows patients to "opt-in" to sharing by the payer during enrollment. Finally, it expands on the 3- and 4-letter acronym entities that are required to support payer-to-payer exchange.

If you think about each of these entities as a character in the second volume of the CMS novel on simplifying data access, they are basically being funneled into the same place. I think what we are seeing here is really "Close encounters of the FHIR kind" ...

Did you catch the hidden FHIR pun? If not, count to four in German. Now understand that FHIR really is HL7 Version 4, and it's been sitting in front of you the whole time, and many of you have missed it for over a decade.

This is an interesting statement: "patients’ payers have a more holistic view of a patient’s care across providers over time."

While true from one perspective, that view is in regard to cost and payment, and not in regard to health or treatment. It's a wholistic view, but from one angle. (c.f. 4+1 architecture)

Ideally, we'd have views from several angles, and not just the view of what's been paid for.