The short and long of the PatientAccess rule

I never did finish up my regulatory summary post on the patient access rule last week, even though I finished reading the regulation text on Monday of last week. So I'm going to combine that with the detail review.  While the rule still hasn't been published in the Federal Register, you can find the preprint from CMS here.

The Short of It

This is what the reg says, and my responses to it. I start there because I don't want to anchor myself in the regulator's thinking just yet. It's also a LOT less text to read.  

Patient Access

Think of "mom" below as Medicare enrollee, and Kingle as Medicaid enrollee. These are real people for me, which helps me to think about the impacts of the rule.  

Patient Access for Mom

Mom's MA organization has to provide APIs that allow her to use an app after mom approves it to access standardized claim data, adjudications, appeals, provider payments (remittances) and co-payments (cost-sharing) within one business day of claim processing. This is an API form of an EOB essentially, but CMS doesn't use that phrase anywhere in the rule, however see how they describe things here.

Mom can also get standardized encounter data within 1 day, provider directory data, including names, addresses, and phone numbers within 30 days of update, and clinical data and lab results within one day.

And because Mom is also covered by a Part D plan, she'll be able to get information about medications covered too and pharmacy directory data, and formularies,

All using the standards that are adopted by the Secretary at 45 CFR 170.215, which includes FHIR DSTU2, ARCH, Argonaut Data Query, SMART, OIDC and FHIR STU3 ... or some more advanced version of the standards unless specifically prohibited; what @HealthIT_Policy (Steve Posnack) calls raising the upper bar.

Mom can tell her Medicare advantage organization to go get data from her previous plan up to five years after changing the plan.

MA providers have to participate in a trusted exchange where they can exchange this data.

Patient Access for Kingle

Now, Kingle, a Medicaid beneficiary I know basically gets the same rights as Mom, because the States have to do this for them too. And just like Mom, Kingle gets access to the same data. With all the same aforementions and aforesaids thereunto pertaining.

And MA and States must provide web sites in which mom and Kingle can get all the information they need about this stuff, including their rights, and how to bitch to the OCR and the FTC if need be.

And 438.242 of the rule says that Health Information Systems must "Participate in a trusted exchange network" which exchanges health information, supports secure messaging or query between payers, providers and PATIENTS.

Patient Access for Any Life CMS Touches

All of the aforemented, aforesaids and thereuntos apply to CHIP beneficiaries as well, and qualified health plan members in federally facilitated exchanges (27 states), and some other stuff. So, basically, if the Feds give money to states or MA organizations to provide healthcare, they have to give mom, Kingle or any other beneficiary access to their data.=

Conditions of Participation

Conditions of Participation translated means if you get paid by CMS funding, you have to do this. If you happen to be a hospital participating in Medicare or Medicaid and you have an EHR (just about all of them), implementing HL7 V2.5.1 ADT messages (all of them), then the system must send notifications with patient name, doctor, hospital and diagnosis.

Critical Access Hospitals and Psychiatric hospitals have the same responsibilities as other hospitals. The reason for separating these out is so that CMS can change there mind about them individually in the final rule, because some of them might complain very loudly, and this gives CMS a way to codify their requirements differently.

Qualified Health Plans in Federally funded (facilitated) Exchanges have to do the same thing as MA, States, CHIP plans, et cetera, or get a special exception and have a good reason for non-compliance and a timeline for correction. And even then, there special exception becomes public.

Thus ends my analysis of the rule itself, and you know just about everything I do about what the proposed regulation says.

The Long of It

This is where I analyze the front matter, which contains the regulator's justifications for the regulation content. In here, you also find the alternatives which they consider (and which are still fair game in the final text), and the other questions they are specifically asking you to respond to, and what they say that aren't going to do, or may do later. This is good reading, but I don't want to read it first, because I want to have my own thoughts in front of me before I read theirs.

For whom the bell tolls

The Patient Access rule applies to Medicare/Medicaid Fee for Service, CHIP and CHIP entities, Medicare Advantage, Managed Care, prepaid inpatient & ambulatory health plans, and qualified health plans in federally facilitated exchanges. Nearly anywhere CMS writes a check, as best I can figure.

All patients can have their clinical and administrative data travel with them, with complete records available to their providers, and Payers should be able to exchange with other payers. Of course, APIs play a significant role "without special effort". Everyone in government’s definition of  interoperability references the now famous “without special effort” IEEE text which I was writing about here in 2013.

APIs will use FHIR as the Standard

The most important part of the history in this section for me is the call out of the Da Vinci Project Coverage Requirements Discovery (CRD) profile with CMS, and work on prior auth for CPAP.  Between that and the recent letter of thanks that CMS sent to HL7, we can get a very strong idea of some of the directions of CMS thinking around APIs for Medicare/Medicaid in the future.  There's also some potential here for FHIR to supplant X12N EDI transactions for HIPAA in the future, and some appetite in the industry for the same ... just as a related trend to think about.

HIPAA allows for APIs

In a somewhat long winded response, @CMSGov reminds covered entities that patients are not covered entities and that they can direct covered entities to third parties (and Apps by association) by right under HIPAA (as revised by the OmniBus regs). You might recall my own observations on the impacts of the HIPAA Bus and e-mail, well, they apply equally to APIs according to this text (and my own analysis).

Everyone to Use FHIR

The rule would require “MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs (excluding issuers of SADPs)” use HL7 FHIR for APIs. CMS intends “to prohibit use of alternative technical standards that could potentially be used for these same data classes and elements, as well as earlier versions of the adopted standards named in 42 CFR 423.160 [the HIPAA ePrescribing standards], 45 CFR 162 [the HIPAA transaction standards] & proposed at 45 CFR 170.213” 

CMS also reports a “wish to assure stakeholders that the API standards required of ...[that list of payees]... under this proposal would be consistent with the API standards proposed by ONC [in the Cures rule]."  Where no standards are elsewhere mandated and HIPAA transaction standards are the only ones available, the rule would “require entities subject to these proposals to use these HIPAA standards when making data available through the API.”  In payer to payer information exchanges, they could still use HIPAA trasaction standards they already have or could use FHIR et. al. for exchange required by the rule, not throwing the baby out with the bathwater.

Pages 32-57 is mostly about use of FHIR and APIs and some not quite so new stuff already in regs from CMS.  If you read the cures rule, you'll see a lot of similar discussion here.  It's mostly background though.  The key point is that the APIs are going to be FHIR, same set as selected by ONC (though I imagine some thought will be needed around claims, and EOB statements as that work progresses in HL7).

Page 57 starts the discussion from CMS’s view on standards update process, and is following ONC's lead in the Cures rule.

The open API in the rule “would include: adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where available).” Simplifying that for the non-EDI crowd: Claims data is what docs send to payers, cost/remittance/cost-sharing is what patients get from insurers on an EOB statement, and clinical data what providers put in their EHR (using USCDI).  Also available via APIs would be provider directories and medication formulary data. 

CMS has to say much of the same things over and over because different regulations apply to different entities they pay under programs legislated at different times, and some require slightly different variations because of those variations.

Miscellaneous but Important Short Topics

Timelines

Much of the rule is to be applicable by January 1, 2020, but for some (CHIP), by July 1, 2020. That’s not a typo. Shot and a beer that the industry response is going to push for a later date is a bet I think nobody will take, maybe we should bet on the actual date appearing in the final rule.  Given rule deadlines, Jan 1, 2020 is very short notice.  The rule still hasn't been published, let's say it is on March 1, then the comment period goes through March and April, and then CMS can start putting together it's responses afterwards.  I'd allow for another 60 days or so for that to get done, and it still has to go through another week or more at OMB before publication as an FR.  So, call it about 90 days total.  That means an FR could show up in the late July early August time frame, with an implementation date 6 months away?  That seems VERY tight, especially for the payer space.  I'm guessing those dates will move in response to industry push back.

Color Commentary

CMS claims patient access is “designed to empower patients by making sure that they have access to health information about themselves in a usable digital format and can make decisions about how, with whom, and for what uses they will share it.”

It sure as hell will as I read it!

This kind of data will make unprecedented price transparency available to patients through APIs, and the third parties they wish to share it with under the rule. Imagine if you will what one could do with EOB and price data from millions of patients, think of intervention studies where the intervention is a change in health plan for example.  Think about what patients who pool their data with others might learn:  Under plan 1, doctor D charges X$ for procedure P, what does doctor D charge under plan 2?  What does doctor E charge under plan 1?  How many procedures P do doctors D and E do?  What's the cost of procedure Q? As I think these parts through, this could be earth-shattering to enable patient cost controls, almost makes me sorry to not be on Medicare just yet.

The scary part is who else will try to take advantage of it... and I see many opportunities for abuse here... especially in terms of resale of patient data gathered by apps, even anonymized or aggregated.  I think much thought is needed on the unforeseen consequences, and a risk analysis on these components is something I think the industry should certainly do in response, with feedback to CMS on the results.

Trusted Exchange Network

As I read through the section on Trusted Exchange Networks in in the rule, I don't see enough words for me to equivilate [yes, that’s a word] it to the same as trusted exchange framework, though I see parallels. A Framework is not a network (just ask someone from Carequality/Sequoia if they are a network).  I think there will certainly be tie-ins between the two, but I don't think they are the same thing.

Complexity in the Rule

CMS comments on the need to align Medicare and Medicaid to support care, but the rule also makes it clear that CMS needs to align many programs (MA, part D, CHIP, FFE and others) on standards. A better rule structure with common content might improve compliance.  This, as I said earlier has in part to do with the legislative background associated with CMS responsibilities under so many programs.  I think a "Chinese Menu" approach might be applicable here though, where, like ONC, CMS creates a list of requirements that other sections reference as appropriate.

(Some) States need to Up there Game on Dual Eligible Patients

Under Increasing the frequency of federal-state data exchanges for dually eligible individuals CMS is telling states that do this monthly is that daily exchange is necessary, and will help them cut costs and improve patient outcomes for both CMS AND the states that are behind.

The new "Wall of Shame"

CMS runs through background on Information Blocking from page 126 through 135, and the fact that CMS will publish attestations regarding information exchange publicly on the three questions in section I here.

NPPES to support Electronic Contact Information

Under the rule, CMS would use its NPI provider directory to publish digital contact information for both individuals and facilities eliminating the problem I described here.  This was a thought that I've dropped in various suggestion boxes of many years, and was discussed very early on in the Direct project.

ADT Notifications

Under conditions of participation for hospitals, the rule would require some form of notification (i.e. a functional capability) to be give to other providers upon patient admit, transfer or discharge, but not requiring a specific standard for it, for those providers with 2015 CERHT having HL7 V2.5.1 ADT messages (see 170.299(f)(2)).  Special call-outs for psychiatric hospitals and critical access hospitals allow CMS to use same or different requirements for these kinds facilities in the final rule.  This is a smart move by CMS to alleviate the challenges that might be raised by those institutions with special requirements.

Requests for Information

The last part of the Patient Access NPRM isn't about rules, but rather questions that CMS wants to get feedback on before it makes more policy in this space.  There are three key topics, and I'd suggest you read and respond to these:

1. Supports for Long-term and Post-Acute Care
2. Patient Matching
3. Innovation Center Models for Advancement

The End (for Now)

And that takes us to the end of the interesting stuff in the front matter.  The rest (from page 172 to the start of the regulation) cover regulatory disclosures that talk about costs of the rule, data collection, and other stuff that is required of the regulatory, but generally very difficult to analyze without deep economic expertise.  However, if you have that ability, and provide feedback in this space (not many do), it would probably wake someone up.