When the NoBlocking regulation is more complex than software

... it's time to apply software tooling.

So I went through various definitions in the Informatin Blocking rule and made a UML diagram.  The value of this became immediately apparent to me when I was able to see for example that Interoperability Element, Health IT Module, and API Technology were somewhat broken.  API Technology is certainly a Health IT Module, and should be defined in terms of that definition.

It also shows the various relationships associated with actors.  As I go through the rule, I imagine there will be other relationships that I can infer from the regulatory text (e.g., fees charged to actors by other actors).

You can see the results below, and more importantly, you can get the source.

Entities (people, organizations, and things) are classes.  Things that can be done (verbs) are represented as interfaces.  The SVG representation links back to the regulatory text, and has mouse-overs citing the source of the link or artifact.

   Keith

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 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