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.