The skinny on the NoBlocking provisions of the CuresNPRM

In my own contribution to two reams, I put together a tweet stream of of over 150 tweets yesterday covering the information blocking related provisions of the Cures NPRM released by ONC during HIMSS week.  It's finally available from the Federal Register (but not yet "published"), and you can find the copy I used to summarize it from ONC here.  Next Monday you should be able to get to the web-based Federal Register content, and I've heard also that ONC will publish the Word version (which is going to be my source for comments given that I can modify electronic commenting tools I've developed for my HL7 work to gather feedback).

I'm NOT going to give the long details of that stream in this skinny post, but you can find the full set at tweet 18 in this 14-page unroll.

The information blocking provisions are the biggest addition to ONC oversight in terms of new regulation since inception of the CEHRT program, and also have potentially the biggest raw impact since then.  The provisions impact:

• Patients
• Data Providers
• Healthcare Providers
• Health Information Networks
• Health Information Exchanges
• Health IT Vendors
• Certified EHR Technology vendors

The most challenging aspects of this rule related to the fact that data blocking is essentially defined as a behavior that would restrict, restrain, discourage or otherwise prevent access to electronic health information UNLESS ... and then details 7 exceptions.  The exceptions together take about 17 pages of REGULATION, and somewhere around 180 pages of explanatory text in the preface.  That works out to about 2.5 pages per exception for the regulation alone, and around 25 pages of explanatory text per exception.

45 CFR 171 is all new content, and touches deeply on the rights and responsibilities of stakeholders with regard to exchange of electronic health information (EHI is the new acronym you need to learn), in ways that to my knowledge, are unprecedented in digital commerce.

In the main, past regulatory efforts regarding digital data tied to an individual have been related to what CANNOT flow, or in the cases of an individual, what data MUST flow to that individual.  In the case of the Information Blocking rule, the regulatory effort is about what must flow, and what legitimate reasons must exist that might inhibit that flow.  This is a very new approach.

The current challenge has to do with the fact that while the regulation touches on rights and responsibilities of stakeholders, it isn't written in a form that corresponds to any new or existing rights.  Instead, the form it is written in closely corresponds to the ruling law found in the 21st Century Cures Act.  This meets the test that all regulation must meet in being able to establish its ties back to the supporting legislation, but unfortunately doesn't make it very easy to understand.

I think my comments on this regulation are going to be an attempt to reinterpret it based on rights and responsibilities that appear based on the intent of the legislation.  But this is an area where I think I'm going to need to get some expert assistance.  Because while I can probably figure out the right model, I'm not entirely clear on the constraints that current law might impose in interpretation.

    Keith

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.

The ONC Information Blocking Rule

 

The Cures NPRM added a new section to regulations that covers not just certified EHR technology, but the behaviors of organizations in possession of patient data with regard to information exchange, which I covered earlier this week in my #NoBlocking tweet stream.

The rule itself is a difficult read, the preface, I hope is a lot easier to comprehend. Remember, I read the regulation text first, I haven't gotten to the preface yet.  It gives me an opportunity to get my own impression of the regulations without achoring myself on ONC's justifications for why they did what they did.  I'll be coming back to these again after going through the front matter.

Generally, as I understand this section, ONC is seeking to ensure that all parties who want to use APIs to enable access to patient data (with the patient's authorization) are treated fairly and equally, and that bars to competition are not raised on the basis of access to patient data.

By all parties, ONC applies this section (45 CFR 171) to health care providers, health IT developers of certified products (including API developers and technology suppliers), health information exchanges and networks.  So, if you are a user, developer, reseller, or other third party that essentially deals with deploying, maintaining, using, updating, or otherwise providing access to software certified to use APIs to facilitate the exchange of patient data, this applies to you.

The whole point of this rule authorized under the Cures Act is to prevent ANYONE from interfering with, preventing or discouraging exchange of health data.  ONC makes it clear, ignorance of the requirements aren't an excuse (knows or SHOULD KNOW is the specific wording).  Now, it's pretty clear that ONC understands that there are reasons to prevent access to data, either permanently or temporarily, and that some essential industry behaviors will be seen by some as "information blocking".  The very fact that organizations are making money from healthcare is anathema to some, and so ONC is working hard to try to figure out how to explain the behaviors that aren't considered to be information blocking by listing out the various practices that are allowed.  This is a difficult task for an organization that doesn't engage in business, and I suspect that this part of the Cures NPRM will be the most commented on.

There are a list of things that organizations are permitted, anything not explicitly permitted is at the very least behavior that could be questioned with regard to "information blocking", and this is a case where ONC is the referee who gets to make the decision.

1. Preventing harm
2. Promoting privacy and security
3. Recovering reasonable costs incurred,
4. Avoiding infeasibility,
5. Allowing for reasonable and non-discriminatory licensing fees
6. Maintenance and updates.

Arian Malec presents an excellent sound track and interesting commentary on items 3 and 5 above and a great follow up on contractual requirements that highlight some of the most difficult parts of 45 CFR 171.

Many of exceptions are pretty straightforward to understand.  The first of these falls clearly within the pervue of providers under "do no harm", and is also aligned with HIPAA.  HIPAA and the no blocking rule rule are also aligned on promoting privacy and security (my #2 above).  And lastly, allowing information providers to take information offline temporarily for maintenance and updates is something we all expect and should allow.

Sections 3-5 have to address API providers, but also those who might need to respond to a request for health information.  I think this section is having a little bit of an identity crisis simply because it has to cover so much territory.  I think ONC needs to divest some parts of this section which are already covered under HIPAA (perhaps even by referencing that regulation).  This could help greatly, and in fact make it easier to maintain this section of the regulation.

Avoiding infeasibility addresses a host of issues and concerns.  Many API providers today for example, place limits on the amount of information that can be accessed in a single request, which could be viewed as "information blocking".  These are essential constraints in order to enable responsiveness in technology (returning all of the lab results for the past ten years for a single patient who has been very ill could take a VERY long time, and prevent others from accessing data depending on implementation).  But this section also has to address other sorts of requests for information, which is part of  it's identity crisis.  In this section, ONC makes it very clear, using your access to electronic health information as a means to prevent competition or to force others into paying a fee to access it doesn't make a request for access infeasible.

So, health data is still a commodity under #NoBlocking, but no longer a strategic commodity that the "haves" can hold over the "have nots", and further more, treating it as such could be cause for a claim of "information blocking".  I'm pretty sure I'm in agreement with that general principle, but I'm also sure that this portion of the rule is going to be gone over (by me and others) with an extremely fine-toothed comb.

   Keith

The Cures NRPM

You will be getting a lot from me this week.  I'm going to start with the first part of the Cures Rule, prereleased by ONC and I'm just going through the regulatory text, rather than all the prefatory material.  That's next on my late night reading list (1000 pages is a lot to read, this cuts it down by at least 80%).

To start off with, some 2014 related materials were removed from the rule.  Thus stuff no longer applies now, so it's not material to any discussion.

Content Standards added include:

• C-CDA Templates for Clinical Notes R1 Companion Guide
• NCPDP Script Standard Implementation Guide, Version 2017071
• 2019 QRDA Category I Hospital Quality Reporting Implementation Guide
• 2019 QRDA Category III Eligible Clinicians & Professionals Quality Reporting Implementation Guide

API Standards (what we've all been waiting for include):

1. FHIR DSTU 2
2. API Resource Collection in Health (ARCH) (more on this in a bit)
3. Argonaut Data Query 1.0
4. SMART on FHIR
5. Open Id Connect
6. FHIR STU3
7. Consent2Share profiles (I'm guessing you are wondering what this is to).

Of these, 2 and 7 had me scratching my head.  #2 is pretty straightforward, just click the link.  It's a list of FHIR profiles that need to be supported according to the NPRM.  #7 was a downright bitch to locate, though I finally did.  I suspect that if John Moehrke had been awake, he could have found it a lot faster.  This is basically an STU3 profile of the FHIR Consent resource.  #6 and 7 basically mean that ONC is allowing STU3, but ONLY for the exchange of consent information, not allowing STU3 for anything not already covered by 1-3 above.

So, how did I do in my bet? If the proposed rule becomes the final rule, I lose it, but I picked the options correctly.  I still think my bet is sound, but I'll give it a 60% chance of being the final result, with the alternative being what we saw proposed this morning.  If I'd thought about it harder, I would have known that ONC couldn't have submitted a proposal with R4 because IT HADN'T been published at the time it was submitted to OMB, which still doesn't leave it out of the running.  The proposed rule text published by ONC does contain a reference to R4 in section 170.299.  My bet (and I'll know more tomorrow) is that the industry will push for R4 and the US Core specifications.

Even if they don't, ONC's changed the rules so that they (and you) can upgrade to newer standards, so that the rule can set both a lower and upper bar.

USCDI is something we are all going to have to become more familiar with.  I took my first look at it a year ago.  It's still not much more than the CCDS and a collection of C-CDA templates.  For the most part, there's nothing challenging here, it's just work for your engineers and validation staff.

There's additional guidance in the rule on how to use CCDA (see the companion guide link in the previous section), and on how to handle Assessment and Plan, Goals, Health Concerns, and UDI (device identifiers) data in the rule.  Expect test procedures to change (I imaging those folks are starting to think about what to change, but won't really get to work until the rule is final).  However, I don't expect a big lift here.

Section D; Conditions and Maintenance of Certification for Health IT Developers is brand new content for certification.  It applies to the organizations who certify product, and how they must behave, rather than what the product must do.  To summarize:

400: This is authorized by the Cures act.

401: As a developer you will attest to ONC that you won't block.  This is a regulatory form that basically makes it possible for you to be fined under the false claims acf if you say you won't and then you are found to do so (c.f. recent news), if I'm reading this correctly.  This is powerful stuff which makes enforcement possible by more than just ONC revoking a certification, the DOJ can get involved.

402: Prove it, and furthermore, don't do what other guys did (see the last link), and make getting that single patient data export document out easy peasy, and keep your records for 10 years, and you have 2 years to handle that patient data export change.

403: What I call the "No Gag Rule" clause says that a health IT developer cannot restrict communication regarding:

1. usability,
2. interoperability,
3. security,
4. user experience,
5. business practices,
6. ways in which the product has been used.

Anything is fair game to be communicated, including proprietary, confidential or IP content when the communication is about one or more of the above for communications:

1. required by law
2. regarding patient safety, to government agencies, accreditors or patient safety organizations,
3. about privacy and security to government agencies,
4. about information blocking to government agencies,
5. about certification non-compliances to ONC, an ONC-ACB 

Restrictions are permitted to or about:

1. contractors and employees,
2. non-user facing aspects,
3. IP except that screenshots ARE permitted with certain reasonable provisions, EXCEPT for cases of premarket testing and development until the product ships, after which they are subject to prior rules

And must notify (within 6 months) and make effective (within a year) that any existing contract provisions that contravene the above are basically null and void hereafter.

404: This section requires a close read by your staff involved in revenue generation from APIs.  Basically it says you have to disclose everything needed to use them, make clear how you are charging, be fair in the way you charge, not specifically designed to be anti-competitive, not require non-compete clauses, not require exclusivity or transfer of IP rights, or require reciprocation.

There are some other clauses in here as well, regarding "allowing production use" quickly, and publishing endpoint addresses for systems "in a computable format". 

405: Just as FDA requires post-market surveillance and corrective action, ONC is now requiring ongoing testing and maintenance for certified product, requiring the developer to make a plan, share it with ONC, execute it, and report on the results.  

And you've got 2 years to upgrade your products to the new standards.

406: The developer must attest to all of the aforemented, aforesaid, thereunto appertaining stuff at the time of certification and every six months thereafter, therefore becoming subject to additional enforcement opportunities by ONC and DOJ.

I'm not going to spend much time on section 500, as it mostly pertains to the operations of ACBs, but there's some impact on Health IT Vendors here to look at in this section, mostly in that adopting section D above ONC now has a responsibility to verify that section D is being complied with.  This means that they may perform surveillance about developer behavior in addition to product behavior.

And, as a result of that surveillance, ONC may also BAN a developer from the certification program based on their behavior, giving them yet more enforcement capabilities.

Section D is going to be the hardest discussed section in the industry, but I think in generally it is fairly written (if complex).  There's definitely some work that could be done to make the language simpler and easier to read.  A lot of that may already be written in the preface (which I have yet to read, I like to get my first opinions by reading the regulations, rather than the regulatory body's justifications for them).

I'll be covering what I call the "No Blocking" part of this rule later this week, as well as the Patient Access rule released by CMS.  NOTE: I'm reading the prerelease versions that were available from ONC (and CMS) prior to publication in the Federal Register.  I'll read those versions in my second full read through, just to see if there are any significant differences.

As always, I'm not a lawyer, and this is NOT legal advice, and you get what you paid for.  This also is my own opinion (as are all posts written here), and not the opinion of my employer nor any other organization I might have some affiliation with.  

Keith

My read through tweet streams can be found by searching my stream for #CuresNPRM, #PatientAccess and #NoBlocking.