Are you lost on how GDPR is related to Health IT standards?

Yesterday, after posting for the first time in a while, Google alerts me that as a publisher of content on THEIR technology platform, using THEIR tools, that I have a responsibility to notify you (if you happen to live in a European Economic Area) of how I use your personal data, and if necessary obtain your consent, as a result of the General Data Protection Regulations (GDPR).

Conveniently, I don't use your personal data.  Instead, I let Google do it all for me.  If there are cookies generated by this site, they are generated by Google software.  If there is tracking being done by geography, cookie, topic or other data you supply to access this site.

If you happen to be reading this blog through a syndicated site, well, all bets are off because I don't control how those who syndicate this content use your personal data, but they are subject to the same requirements as I am.

I don't use cookies for Ads (because I don't do AdWords or anything like that here).  I do use Google Analytics with my blogger account.

But apparently, I still have some responsibilities to you, or at least, that is what Google is telling me.

Here's Google's policies and an explanation of how it uses your data, and how you can opt out of certain uses.

Now, here's what is interesting about what Google did.  They transferred their compliance risk to me even though I use their platform and their tools.  This is a classic technique to mitigate risk that we look at all the time in developing IHE profiles and other implementation guides.  It's one of several techniques for risk mitigation.  More often, we apply other technical mitigations (e.g., the use of ATNA or TLS, the requirement for authentication).

If you are reading this site in a European Economic Area, Google tells me that this site will display a notice to you.  I've not seen it yet because even though Google tells me I should be able to by using the blogspot.fr or .blogspot.co.uk or similar name, my browser conveniently redirects me to the .com site.  So, if you got the notice, please let me know.  Otherwise, I may need to do something more.

    Keith

P.S. Unlike HIPAA, GDPR doesn't really have an an easily acceptable pronunciation, although it does bring to mind several different acronym decodes.  In that, it's somewhat like BPPC.

On CMS 's Promoting Interoperability Program (the program formerly known as the EHR Incentive Program)

A while back I read through CMS's recent rule changing the EHR Incentive program to the Promoting Interoperability program.  I promised a blog update but for some reason (work), didn't get around to writing it.  I decided to take action and finally sit down and finish it.

The published rule is something like 1800 pages, 36 reams of paper when printed double-spaced (as preprints are).  You can find it at the link above.  It goes by the precise but lengthy title of:

Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long-Term Care Hospital Prospective Payment System and Proposed Policy Changes and Fiscal Year 2019 Rates; Proposed Quality Reporting Requirements for Specific Providers; Proposed Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs (Promoting Interoperability Programs) Requirements for Eligible Hospitals, Critical Access Hospitals, and Eligible Professionals; Medicare Cost Reporting Requirements; and Physician Certification and Recertification of Claims

I will only cover two parts: Quality Reporting Requirements, and the Promoting Interoperability Programs.  The first part is interesting because everyone who cares about the second part also has to deal with the quality reporting part.  You can find my raw read-through comments on Twitter.

Quality Reporting Requirements

If you haven't been paying attention to CQL, you really need to be.  The first publication of reporting requirements technical specifications will be this spring (coming REAL soon) for use in 2019 (coming sooner than you think).  According to CMS (and me) "We believe that compared to CQL, QDM logic is more complex and difficult to compute".  CMS will be using a sub-regulatory process to make technical corrections to the measure specifications.  This is good because it means that the quality measure specifications will be able to have more quality without going through a heavyweight process to fix mistakes.  But it also means you have to pay attention.

Hospital measure data will join the myriad of other public data out there, as it will .  Soon we'll be able to compare not just meaningful users and their EHR systems, but also the quality results they'll be able to get from the use of them.  That should be an interesting mashup.  Hey ONC! Are you listening?

A lot of measures are going to be eliminated, either because they are topped out (hospitals are doing so well its not worth measuring any more), duplicative, or cost too much to produce for value received or ...  There's are lists of the measures that CMS is proposing to remove in the rule.  While everyone is happy about measures being removed, just remember that also means that there are fewer choices to succeed with...

Promoting Interoperability Programs

Why did they change the name?  Well, they remind us in the rule that the EHR Incentive part of the program is about over for anyone participating (we're now in the penalty stage).  So that part makes sense.  One significant change is that the singular program became the plural programs. 

They are planning to require 2015 Certified EHRs for these programs because, in part, ONC has confirmed that at least 66 percent of eligible clinicians and 90 percent of eligible hospitals and CAHs have 2015 Edition available (see the link above at meaningful users and their EHR systems).  Also, the evaluation period is a minimum of any continuous 90-day period within each of the calendar years 2019 and 2020, as you all probably hoped and expect.  The rationale for this change was that health care providers may need extra time to fully implement and test workflows with the 2015 Edition of CEHRT.

Miscellaneous

Security Risk analysis is simply required, you don't get any extra points for doing what you are required by law and regulation to already do.

For ONC and CMS, it's pretty routine to ensure that whatever the latest and greatest healthcare crisis is, there needs to be something to in the regulations about it.  So new measures have been added to address opioid abuse, including Queries of prescription drug monitoring programs (PDMPs), and verification of opioid treament.

Closing the referral loop also gets some love with a new quality measure supporting that buzz phrase.

A number of exclusions (loopholes) are being removed, few are using them or they aren't warranted according to CMS.

Puerto Rico hospitals become eligible for the program, something that wasn't available to them previously.

Some capabilities will no longer be required to be used (though they will still exist in the certification requirement): Secure Messaging, View/Download/Transmit.

So, there you have it, my summary of about 10% of the rule.

For what it's worth

The section on Future Directions is worth reading for those of you who are worried about what is next, but that is merely non-binding self-promotion for the most part.  The really important part related to that is where CMS asks you to tell them where they should go.