Thread by @motorcycle_guy

Starting at page 221 with the regulation itself (see how I do this...I skip to the regs first, I’ll go back through the preface material later) #PatientAccess cms.gov/Center/Special…

In the following, mom is simply how I think about the phrase "Medicare Enrollee". It could be dad, uncle Fred, my buddy Glen et cetera. #PatientAccess is about the patient.

So, 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. #PatientAccess

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

All using the standards that are adopted by the Secretary at 45 CFR 170.215, which you might recall in my tweets about #CuresNPRM included FHIR DSTU2, ARCH, Argonaut Data Query, SMART, OIDC and FHIR STU3 ... to support #PatientAccess

Or some more advanced version of the standards unless specifically prohibited ... this is what @HealthIT_Policy calls raising the upper bar #PatientAccess

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

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

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. #PatientAccess

And Medicare Advantage 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 #PatientAccess

An 438.242 of #PatientAccess 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,

All of the aforemented aforesaids and thereuntos apply to CHIP beneficiaries as well. 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 #PatientAccess to their data.

And 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 DX #PatientAccesss

This part falls under "Conditions of participation", which translated means "if you are in Medicaid or Medicare", you have to do this. #PatientAccess

And CAH's and Psychiatric hospitals have the same responsibilities as other hospitals #PatientAccess

And now we move on to Qualified Health Plans in Federally funded (facilitated) Exchanges. You 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. #PatientAccess

Thus finishes my flash review of #PatientAccess. Now back to 42 CFR 171, which I'll track under the #NoBlocking tag.

So, #NoBlocking is a new part of CEHRT authorized by 21st Century Cures Act. It basically defines things that "Aren't considered information blocking". Anything not on this list is thus questionable at best.

#NoBlocking applies to Health care providers, #HealthIT Developers building certified products (including API developers and technology suppliers), health information exchanges and networks

So interfering with, preventing, or discouraging exchange or use of information by a developer, network, or exchange is not allowed under #NoBlocking, and IGNORANCE of the regulation, or the impacts of technology decisions is NOT an EXCUSE (knows ... OR SHOULD KNOW )

The next part of the rule talks about reasonable and necessary #NoBlocking exceptions, which include: Preventing harm, promoting privacy and security, recovering reasonable costs incurred, and infeasability, reasonable and non-discriminatory licensing fees, and maintenance

#NoBlocking is a difficult read, the preface is probably easier to comprehend. Essentially, the point as I understand it (before reading the preface) is that a) all parties are treated fairly, and equally b) bars to competitors are not allowed,

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

Remember, I'm not a lawyer, none of this is not legal advice, you get what you paid for. #NoBlocking, #CuresNPRM, #PatientAccess

Starting with front matter now on #NoBlocking, which includes Conditions and Maintenance of Certification on page 19 healthit.gov/sites/default/…

This section addresses the behavior of developers (organizations, not products) at the outset, and ongoing that must be met if they certify products. It also covers behavior or products ... but the key point here, is that organizational behavior is much broader. #NoBlocking

[not in the text, merely an observation made by an expert I trust] If Organization A certified product B, and non-certified product C, behavior by developers of non-certified product C COULD lead to a finding of "Information Blocking" by a developer A. #NoBlocking

The behavioral constraints in #NoBlocking could have more far-reaching effects for larger #HealthIT Vendors. Just as everyone in a covered entity often gets HIPAA training whether or not it might apply to them, the same might be true in a Health IT entity wrt "Blocking"

#NoBlocking The Cures Act requires that a health IT developer, ... not take any action that constitutes information blocking as defined in section 3022(a) of the Public Health Service Act (PHSA). @ONC_HealthIT adds content in a new section proposed top appear at 45 CFR 170.400

And then, there's the #NoGag clause in #NoBlocking that prevents restrictions of communication for a number of reasons to a number of recipients about: performance of Health IT, developer business practices, or even design of a product.

Conditions of certification would require any existing "gag clauses" in current agreements to be null and void ("the prohibition or restriction will not be
enforced by the health IT developer" is the exact wording) in #NoBlocking and new contracts wouldn't have them. More later..

Real world testing is another new component for maintenance, not really about #NoBlocking, but more about #ItActuallyWorks. This requires developing, executing, and reporting on real world testing plans. Smart #HealthIT organizations already have this in play but ...

The Real world testing would need to integrate what organizations already do into material that would be reported to ONC or their ACB. #NoBlocking
Real world testing ensures that information flow actually works.

A side effect of all of this is that ONC would have access to information about the advancement of standards that #HealthIT developers take advantage of and report to their ACBs, enabling standards advancement

Attestations are important, because an attestation that after investigation turns out to have been untrue, makes the attester subject to the False Claims act. Another Condition of Certification and Maintenance is attestation to compliance with these conditions. #NoBlocking

Consider that the two large ONC settlements regarding certification involved DOJ and that False Claims act ($155M and $57M), and you can see that this section enables powerful enforcement response #NoBlocking

. @ONC_HealthIT has "not yet established an EHR reporting program. Once ONC
establishes such program, we will undertake rulemaking to propose and implement the associated Condition and Maintenance of Certification requirement(s) for health IT developers" #NoBlocking #ThreeReams?

. @ONC_HealthIT's Direct review process would be expanded to cover #NoBlocking and Conditions and Maintenance of Certification, and would add banning of developers and termination of certification as enforcement options.

The guts of #NoBlocking, exceptions must:
1. clearly promote public confidence (e.g., privacy, security, patient safety) or competition & innovation
2. enable precautions & maintenance to continue without fear of it being called "Blocking"
3. be reasonable & necessary

Seven exceptions to #NoBlocking are proposed, in three areas:
1. promoting public confidence
2. promoting competition and consumer welfare
3. promoting the performance of #HealthIT

Under promoting public confidence, actions taken to protect
1. patient safety
2. patient privacy
3. security of Electronic Health Information (EHI)
are permitted under #NoBlocking

under promoting competition and consumer welfare, actions taken to:
1. recover reasonable costs,
2. excuse an actor from infeasable requests
3. permit licensing of technology on reasonable and non-discriminatory terms
are permitted under #NoBlocking

However, these three #NoBlocking exceptions include subjective terms, such as "reasonable" and "infeasable" which could result in disagreements among stakeholders.

Furthermore, the phrase "reasonable and non-discriminatory" using in #NoBlocking has quite a specific meaning in the area of standards (see en.wikipedia.org/wiki/Reasonabl…), but that case law hasn't been applied to licensing of services, so much as it has to processes or methods.

"Reasonable and Non-Discriminatory" licensing is definitely an area where good legal advice in understanding and commenting on #NoBlocking would be highly valuable (cc: @HealthBlawg maybe not your area, but any thoughts or referrals here?)

The last section of #NoBlocking exceptions is easy to understand. You can take the system down for maintenance and upgrades. "This proposed exception recognizes that actors may make health IT temporarily unavailable for maintenance or improvements ..." [p27]

Recent @ONC_HealthIT enforcement may have influenced points made in "Full Compliance & Unrestricted Implementation of Certification Criteria Capabilities". In this, CEHRT "conforms to the full scope of the certification criteria to which its health IT is certified. #NoBlocking

To sum that up, if certified, it works, completely, you have to test it routinely to verify it continues working, and you have to attest to all of the previous. You cannot block by doing a stupid and saying you didn't know it didn't work. #NoBlocking

To quote @ONC_HealthIT in #NoBlocking: "developers would be prohibited from taking any action that could interfere with a user’s ability to access or use certified capabilities for any purpose within the scope of the technology’s certification." ... continued ...

"Such actions may inhibit the appropriate access, exchange, or use of EHI and are therefore contrary to this proposed Condition of Certification and the statutory provision that it implements." #NoBlocking (EHI = Electronic Health Information)

failures include: "failing to fully deploy or enable certified capabilities; imposing limitations (including restrictions) on the use of certified capabilities once deployed; or requiring subsequent developer assistance to enable the use of certified capabilities," #NoBlocking

My reading of all of this: two gals in a garage can design, implement, and deploy an App using a #HealthIT Vendor's APIs w/o any human intervention except PERHAPS in their application registration process, with a limit of 5 days max for that #NoBlocking

And #HealthIT developers must keep records of their efforts wrt certification and compliance for 10 years, which applies both to #CuresNPRM and #NoBlocking provisions of the rule. Or 3 years after removal from certification (whichever is less)

There's a ton of content on #NoGag portions of the rule at p167-176 that deserve close reading, especially to those in the #HealthIT space that may have such clauses in their contracts. @ONC_HealthIT seems pretty firm on these points w/ ample backup (20 footnotes)

OK, let me restate the pages: 167-201 ... yeah, @ONC_HealthIT spends a lot of time in this #NoGag section, and that means it's important to them.

Speaking as an informed patient, I've seen a LOT of EHRs in use, and sadly, there's little earth shattering to look at

I skipped this in #CuresNPRM I'm gonna cover now, even though it's not #NoBlocking
Statutory Interpretation and API Policy Principles: This is aboput @ONC_HealthIT's interpretation of the "without special effort" quote in Cures. API users are who exert special effort or not

And API Users "could include third-party software developers, the health care providers that acquired this API technology, and patients, health care providers, and payers that use apps/services that connect to API technology." in #CuresNPRM

"APIs, and the health care ecosystem in which they are deployed, have three attributes: standardized, transparent, & pro-competitive" in #CuresNPRM
standardized = same tech capabilities
transparent = freely available documentation
pro-competitive = vendors don't decide on access

Tech documentation includes published, API accessible endpoints!!! #CuresNPRM

Frankly, that fits under #NoBlocking, because if you have to spend three days finding your doctor's endpoint, that's special effort. Been there, done that: motorcycleguy.blogspot.com/2017/08/whats-…

#NoBlocking This long quote starts at page 244: 'API Technology Suppliers may establish additional mechanisms to vet app developers. Such mechanisms could fit into the “value-added services” permitted fee & result in the app being acknowledged or ...

... listed by the health IT developer in some special manner (e.g., in an “app store,” “verified app” list). While our proposals do not specify any explicit limits to the nature and governance of these approaches, we wish to caution health IT developers that ... #NoBlocking

... even though such processes have a reasoned basis in providing an added layer of trust above and beyond the basic production-readiness of an app, they can equally be used as a means to prevent, limit, and otherwise frustrate innovation, competition, and access ... #NoBlocking

to the market." #NoBlocking

So, that is a very clear statement from @ONC_HealthIT about aspects of program conditions existing today that says "be careful" b/c "API Data Providers" are who "provides access via the API technology to data it produces and electronically manages"

So this who section related to fees is really, REALLY important, and I'm going to have to give it a deeper read through at this stage. #NoBlocking

A lot of organizations realize that patient data is a commodity, and are thinking about how to capitalize on it.

But as I've said previously in different words, patient data monopoly power appears to be nullified by much of what @ONC_HealthIT is proposing wrt APIs, and #NoBlocking

Patient Data "Haves" can't hold it over the "have nots"

#NoBlocking § 170.404(a)(4) that API Technology Suppliers must grant API Data Providers (i.e., health care providers who purchase or license API technology) the sole authority and autonomy to permit API Users to interact with the API technology deployed by the API Data Provider.

#NoBlocking proposes to "require that API Technology Suppliers must provide API technology to API Data Providers on terms that are no less favorable than they would provide to themselves and their customers, ... & other persons with whom they have a business relationship."

That last could be pretty big for #HealthIT Vendors. I haven't gotten to section 8 in #CuresNPRM (appropriately numbered in the rule I think) yet, but noting that there could be some "unanticipated consequences" of the provisions here that folks need to consider.

Some of the terms in this section on fees might already be covered elsewhere in federal regulation, e.g., non-compete clauses, exclusivity clauses, however, these often apply to non-regulated industries, hardly the case in healthcare #NoBlocking e.g., ftc.gov/tips-advice/co…

#NoBlocking A lot of the material on fees is beyond my current experience, and I feel out of depth on this topic, though not outside my ability. I'm just going to have to take a lot more time to process it, as I suspect many in #HealthIT are going to have to do as well.

Section 8 (VIII) starts on page 324 and goes to 502. This is the bulk of the #NoBlocking provisions in #CuresNPRM.

"The information blocking provision was enacted in response to concerns that some individuals and entities are engaging in practices that unreasonably limit the availability and use of electronic health information (EHI) for authorized and permitted purposes." #NoBlocking

"survey reported that perceived motivations for such conduct included,for EHR vendors,maximizing short-term revenue & competing for new clients,& for hospitals & health systems, strengthening their competitive position relative to other hospitals and health systems." #NoBlocking

The enforcers of #NoBlocking: @OIGatHHS, coordinating with @ONC_HealthIT, @HHSOCR and @FTC [p327]

#NoBlocking "individuals and entities that may engage in information blocking and which include: health care providers, health IT developers of certified health IT, networks, and exchanges." @ONC_HealthIT will define and clarify (later pages I expect) -- term used is "actors"

API Data Provider refers to the organization that deploys the API technology created by the “API Technology Supplier” and provides access via the API technology to data it produces and electronically manages. [This is generally a Health care provider organization] #NoBlocking

#NoBlocking API Technology Supplier refers to a health IT developer that creates the API technology that is presented for testing & certification to any of the certification criteria adopted or proposed for adoption at § 170.315(g)(7) through (g)(11). [basically #HealthIT Vendor]

And finally: "API User includes, but is not limited to, third-party software developers, developers of software applications used by API Data Providers, and patients and health care providers that use apps that connect to API technology on their behalf." #NoBlocking

So, I've just become qualified and defined as an "API User", and could become an "API Technology Supplier", but not an "API Data Supplier" because I'm not a credentialed healthcare professional #NoBlocking. Note which comes first in my mind...

. @ONC_HealthIT clarifies "that the information blocking provisions and OIG’s authority extend to individuals or entities that develop or offer certified health IT." #NoBlocking

#NoBlocking Long quote asserting what I said earlier about business practices: "the Cures Act does not prescribe that conduct that may implicate the information blocking provisions be limited to practices related to only certified health IT. ..."

"...Rather, the information blocking provisions would be implicated by any practice engaged in by an individual or entity that develops or offers certified health IT ... " #NoBlocking

"...that is likely to interfere with the access, exchange, or use of EHI, including practices associated with any of the developer or offeror’s health IT products that have not been certified under the Program." [If I could bold two words, it would be ANY and NOT] #NoBlocking

"...the scope of the information blocking provision should not be limited to practices that involve only certified health IT is further evidenced by no such limitation applying to health care providers, ... (HIEs), & ... (HINs) ..." #NoBlocking

If I read this right, that means that OIG can also investigate #NoBlocking acts by healthcare providers, health information exchanges, & health information networks, even if they aren't developing certified products. The definition of API Data Provider helps me understand that

Which means I have to go back and reread some regulatory text to understand what exact words are used in the prohibitions ... that's part for the course. A rule takes at least 2.5 read-throughs to fully grok. I haven't eaten this one fully yet.

Certified Health IT developers can be subject to #NoBlocking claims if "at the time of the claim" it had "health IT (one or more) certified under the Program"

Furthermore, "claim" is not "limited, in any way, to a specific form, format, or submission approach or process"

Under #NoBlocking, @ONC_HealthIT is "considering additional approaches to help ensure that developers and offerors of certified health IT remain subject to the information blocking provision for an appropriate period of time after leaving the Program."

. @ONC_HealthIT seeks comments on which model to apply to developers: a) those continuing to store EHI or b) within 1 yr of leaving certification.

It's an either/or question, if you read my last non-regulatory post, you know my answer. Yes -- whichever is longer. #NoBlocking

Note to self: mark all occurences of the phrase "seek comment" in the document(s) for responses #NoBlocking #CuresNPRM #PatientAccess

e.g. 'seek comment on whether there are particular types of arrangements under which certified health IT is “offered” in which the offeror should not be considered a “health IT developer of certified health IT” for the purposes of the information blocking provisions.' #NoBlocking

I think @ONC_HealthIT should have said "should or should not" in that last part, b/c I think that hospitals offering EHR access to other providers under Stark Relaxation rules might well be considered under #NoBlocking provisions, and suggest commenting as if it was that way

Which brings up another important point, if you like what @ONC_HealthIT wrote in #NoBlocking (or elsewhere), or @CMSGov wrote in #PatientAccess and think it should stand, TELL THEM SO! It helps to provide a contrasting message to those who want it changed. (cc: @S4PM)

. @ONC_HealthIT also clarifies 'that the proposed definition of “health IT developer of certified health IT” and our interpretation of the use of “health information technology developer” applies to Part 171 only' tells me that #NoBlocking should be use their other defined terms.

. @ONC_HealthIT propose to define the terms “network” and “exchange” "so that these individuals and entities that are covered by the information blocking provision understand that they must comply with its provisions" #NoBlocking cc: @CommonWell @CarequalityNet et al

To all readers of #NoBlocking: Seek out sections § 170.102 Definitions and § 171.102 Definitions. If these terms define you or your organization, seek out those terms especially when you read the rule (or any other rule you happen to have the misfortune to be provided).

"there is no need for a separate entity to be created … be … a HIN." e.g. "a health system that administers business&operational agreements for facilitating the exchange of EHI that are adhered to by unaffiliated family practices&specialist clinicians … be a HIN." #NoBlocking

. @ONC_HealthIT notes "that the proposed definition would also encompass an individual or entity that ... nonetheless exercises control or substantial influence over the policies, technology, or services of a network." #NoBlocking

Let's think about this for a moment, is @DirectTrustorg a HIN under #NoBlocking?
DirectTrust is a self-proclaimed "Framework that comprises technical, legal, and business standards that members of the DirectTrust community agree to follow, uphold, and enforce."
Me: Yes

. @ONC_HealthIT seeks comment on the proposed definition of a HIN.
Is it broad enough, or too broad.

My gut is that this is baby bear's definition (just right), but I'm still evaluating.

Music break:

Should have used this for #PatientAccess or #CuresNPRM but what the hey

HIEs include ... "... (RHIOs), state health information exchanges ..., and other types of organizations, entities, or arrangements that enable EHI to be accessed, exchanged, or used between or among particular types of parties or for particular purposes" #NoBlocking

EHI (electronic health information) has a long definition, and "is not limited to information that is created or received by a health care provider, health plan, health care clearinghouse, public health authority, employer, life insurer, school, or university." #NoBlocking

"EHI may be provided, directly from an individual, or from technology that the individual has elected to use, to an actor covered by the information blocking provisions." #NoBlocking

"...this definition provides for an expansive set of EHI,which could include information on an individual’s health insurance eligibility&benefits,billing for health care services,&payment information for services to be provided or already provided,which may include price info..."

"Consistent with its statutory authority, the Department is considering subsequent rulemaking to expand access to price information for the public, prospective patients, plan sponsors, and health care providers." #NoBlocking
[HELL YES!]

Should future @ONC_HealthIt rules require #healthIT developers to include in their platforms a mechanism for patients to see price information, & for health care providers to have access to price information, tailored to a patient, & integrated into workflow through APIs? [YES!!]

To the extent that patients have a right to price information within a reasonable time in advance of care, how would such reasonableness be defined? @ONC_HealthIT wants to know... and boy do I feel an essay coming on here. And not just from me cc: @ePatientDave

This is gonna hurt. There's SO much in #NoBlocking for me to comment on, and it's going to be good stuff, but dang, where's the time going to come from? Responding to this section is like being in school, or writing a book alongside a full time job. Thanks @HealthIT_Policy ;-)

Interoperability Element's definition is crucial, and so I include it here in full, especially in light of of the fact that an entire section of #NoBlocking is devoted to the licensing of material defined below under RAND terms

As I think about where I'm going to get all the time for this, here's another music break:

#NoBlocking "establishes penalties, including civil monetary penalties, or requires appropriate disincentives, for practices that restrict access, exchange, or use of EHI for permissible purposes."

"examples of informal restrictions include," under #NoBlocking "but are not limited to: ...
• A health system incorrectly claims that the HIPAA Rules or other legal requirements preclude it from exchanging EHI with unaffiliated providers."

Oh please give me that hammer!

#NoBlocking "would be implicated if an actor were to deploy technological measures that limit or restrict the ability to reverse engineer the functional aspects of technology in order to develop means for extracting & using EHI maintained in the technology."

OK, so that last might go too far in my view. Reverse engineering restraints are appropriate to protect IP. Frankly, there should be no need, with all else in #NoBlocking, to need to permit reverse engineering except as a last resort (when no other means is available)

So this example implicating #NoBlocking provisions: "A health IT developer of certified health IT charges customers fees, throttles speeds, or limits the number of records they can export in" one case, but not in another ... is challenging

If I get to test your app in detail, I may want to give you a higher rate limit, because I know your app won't bog other users down as you've taken precautions to prevent that ... that's value add on both sides, and fair so long as the lower rate is still reasonable #NoBlocking

I think @ONC_HealthIT needs to consider how application of rate limiting and 429 errors (see tools.ietf.org/html/rfc6585#s…) or 420 errors (en.wikipedia.org/wiki/List_of_H…) could be related to information blocking, especially if implemented to enhance User experience.

"We view the Cures Act as authorizing ONC and OIG to regulate conduct that may be considered permissible under the antitrust laws" says #NoBlocking
With that, it's time for those under the watchful eyes of @ONC_HealthIT and @OIGatHHS to get a music break:

#NoBlocking "requires that actors who control interoperability elements cooperate with individuals and entities that require those elements for the purpose of developing, disseminating, and enabling technologies and services that can interoperate with the actor’s technology."

And if such actors do cooperate with individuals and entities who require those elements, no reverse engineering of the actor's IP (interoperability elements) should be necessary under #NoBlocking provisions.

#NoBlocking asserts that "access to EHI, and the EHI itself, should not be traded or sold by those actors who are custodians of EHI or who control its access, exchange, or use." and I agree, but IP is (generally) not EHI and deserves its own protections.

As for IP that is also EHI, that's yet another story altogether, and not one I want to think about. But consider this, there's IP (codes) in some systems that are proprietary used in some products, and are arguably EHI once computed, but these are not in USCDI #NoBlocking

It might be considered information blocking to not transfer these codes, but the technology licensed to obtain these may not be under the API Data providers control, nor may their agreement allow their use in exchange w/o a license

#NoBlocking This is not an area of my expertise, since I don't deal with or read licensing of proprietary terminologies, but I suspect @IMOsolutions, @WKDrugInfo, and @FDB_US might have some thoughts on the exchange of licensed terms from proprietary codesets

Getting back to #NoBlocking and enforcement:
"In addition, any remedy sought or action taken by HHS under the information blocking provision would be independent from the antitrust laws and would not prevent FTC or DOJ from taking action with regard to the same actor or conduct"

Which might very well explain the reticence of @ONC_HealthIT to have its own requirements combined with FTC's anti-trust requirements under #NoBlocking

As I look at exceptions, one I think may be missed to some degree: Computing required to support health information exchange is a commons shared by patients, providers and others. #NoBlocking should also weigh the needs of the many vs. the one:

Denial of service is a security protection, certainly, and my concern about the commons might be covered there, but there's already well established principles around rate limiting in general API use that this might need special call outs in #NoBlocking

Promoting security and privacy exceptions seem pretty straightforward, but that's only because right now we are sitting on dry and fairly firm and well-packed sand. @CMSGov has clearly stated that HIPAA changes are being considered, which could be a tide taking away our footing

Even so, I'm happy with these #NoBlocking exceptions as written, b/c the proper place to debate the HIPAA ramifications if any is in that update. I just managed to get some small bit of my commentary in for that recent RFI motorcycleguy.blogspot.com/2019/02/my-com…

I like this: Under #NoBlocking "a primary care provider would be required to exchange ePHI with a specialist who requests it to treat an individual who was a common patient of the provider and the specialist," unless an exception applies (e.g. compliance to law)

What I wonder here, is whether the #NoBlocking regs would pre-empt state law in many cases. Some states may have more restrictive requirements in this space. Any comments on that aspect of #Cures from @HealthIT_Policy or @ONC_HealthIT would help me understand this better.

"unless required by law, actors should not be compelled to share EHI against patients’ wishes or without adequate safeguards out of a concern that restricting the access, exchange, or use of the EHI would constitute information blocking" #NoBlocking

#NoBlocking "would generally permit an actor to give effect to individuals’ expressed privacy preferences, including their desire not to permit access, exchange, or use of their EHI." as an exception

#NoBlocking would not apply "if an actor does not provide access, exchange, or use of EHI because a necessary precondition required by law has not been satisfied."

#NoBlocking "would recognize an actor’s observance of a legal precondition that the actor is required by law to satisfy in at least one state in which it operates" would also answer my previous question, in that #NoBlocking doesn't override state law.

#NoBlocking would allow for exceptions when an organization implements and conforms to policies and procedures in writing, and specifies the criteria to be used, and steps that the actor will take, in order to satisfy a precondition to provide EHI and preconditions aren't met.

Only those to whom HIPAA applies can apply HIPAA exceptions ... that makes perfect sense in #NoBlocking. You shouldn't be allowed to claim an exception based on a rule you aren't subject to

I gotta say, though, I really want a decision tree for all these exceptions and exceptions to exceptions... this is something I cannot keep in my head #NoBlocking needs some infographics

Privacy and Security exceptions of #NoBlocking have somewhat the same overall structure:
1. be directly related to the concern (of security or privacy)
2. be tailored to the specific issue being addressed
3. be implemented in a consistent and non-discriminatory manner
...

OK, now we get into some exceptions that regard money, a quick music break here to cover what you cannot get money for:

"unless we establish an exception, actors may be unable to recover costs that they reasonably incur to develop technologies and provide services that enhance interoperability" ... "costs recoverable under this proposed exception could include a reasonable profit" #NoBlocking

A quick definition might be helpful here for those that haven't heard the term "rent-seeking" before: See en.wikipedia.org/wiki/Rent-seek… or perhaps investopedia.com/terms/r/rentse… (lot of overlap here) #NoBlocking

.@ONC_HealthIT reports "As just one illustration, some EHR developers have begun conditioning access or use of customer EHI on revenue-sharing or royalty agreements that bear no plausible relation to the costs incurred by the EHR developer to grant access to the EHI" #NoBlocking

And another: "We have also heard of discriminatory pricing policies that have the obvious purpose and effect of excluding competitors from the use of interoperability elements." #NoBlocking

While to some, it may sound as if some are running to @ONC_HealthIT as if a child saying "he hit me" ... and @ONC_HealthIT is clearly saying: even he he might hit you (in the pocketbook) first, you should know better and not hit back...
that's "Information Blocking" #NoBlocking

I'd be interested in seeing how @EHRAssociation updates their code of conduct after #NoBlocking becomes final ehra.org/sites/ehra.org… and in the organization's response to this NPRM

#NoBlocking allows for reasonably incurred cost recovery, using reasonable and non-discriminatory (objective and verifiable criteria that are uniformly applied), reasonably allocated among customers, not based on competition, or solely based on user's revenue or profit derived

#NoBlocking "revenue-sharing or profit-sharing arrangements would only be acceptable and covered by the exception if such arrangements are designed to provide an ALTERNATIVE way to recover the costs reasonably incurred for providing services" [emphasis mine]

#NoBlocking explicitly excludes certain costs from this exception regardless of the method for recovering the costs.
1. Non-standard design or implementation choices
2. subjective (e.g., intangible assets depreciation or loss of value) or speculative costs (opportunity costs)

Other fees are those allowed at 45 CFR 164.524(c)(4) [HIPAA Privacy] (see law.cornell.edu/cfr/text/45/16…) #NoBlocking

Prohibited are: costs associated with verification; documentation; searching for and retrieving the PHI; maintaining systems; recouping capital for data access, storage, or infrastructure; or other costs not listed above even if such costs are authorized by state law. #NoBlocking

"where an individual authorizes a consumer-facing app to retrieve EHI on the individual’s behalf, it would be IMPERMISSIBLE for an actor to charge the app or its developer a fee to access or use APIs that enable access to the individual’s EHI." #NoBlocking [emphasis mine]

"This would be true whether the actor is a supplier of the API technology or an individual or entity that has deployed the API technology, such as a health care provider." is pretty clear in #NoBlocking. What's not so clear is if HIE/HIN could substitute for healthcare provider

Under #NoBlocking would it be impermissible for an HIE/HIN to charge an app or its developer a fee to access or use APIs that enable access to the individuals EHI? As I ask that question, I THINK @ONC_HealthIT would say: Yes, that's NOT PERMITTED. Clarification is needed.

Too dang many double negatives: "would not preclude" AND holy **** "which would not be excluded from the costs recoverable under this exception"

I cannot even begin to parse that last one. #NoBlocking

This amazing triple negative exception text appears in #NoBlocking provisions. Anyone care to take a crack at explaining what this means? I cannot parse this without breaking out my boolean logic diagramming template.

Infeasibility exceptions are understandable but I'm pretty certain the industry is going to what brighter, whiter lines here. #NoBlocking

Arguably, that there should be some rationale in this section that addresses requests going beyond what is readily available in standards

#NoBlocking Under licensing: RAND "would apply when a developer in a vertical relationship to the actor—a network in this example—wants to use interoperability elements in order to access the EHI maintained in the actor’s network."
use interoperability elements = license IP

and again RAND would "apply when a rival network in a horizontal relationship to the actor (network) wants to use interoperability elements so that its network can be compatible with the applications that have already been developed for use with the actor’s network." #NoBlocking

But licensing IP just "for access to the technology itself – not for the use of the technology to interoperate with either the actor or its customers ... would not implicate the information blocking provision" #NoBlocking

The prose in #NoBlocking is in several places failing to follow plain language required under EO 13563 obamawhitehouse.archives.gov/the-press-offi… (which replaced 12866). My sense is that definition by exception is the source of the some of the problems here. Cognitive overload.

An exception is already one step into negative thinking, then we have exceptions to exception. But exceptions describe permitted behavior, change the language to the affirmative to avoid a layer of cognitive challenge. #NoBlocking

Here's the challenge: X is allowed, Y is not works when X and Y are distinct and have no overlap. But when X and Y overlap, describing a set by describing what is in it, and what is not, using terms that have some cognitive overlap leave it a tangle.

Context is also important in understanding much of the text. Some sentences just don't make sense out of context (like my example that I couldn't parse). #NoBlocking

BTW: While this is a critique of the @ONC_HealthIT #NoBlocking text, this is also the first attempt at this kind of think, and the first opportunity they've gotten for feedback. I'm generally impressed with the thinking in it, even if I may not agree with it all.

And if I can come up with better text, you KNOW I will suggest it. #NoBlocking

#NoBlocking is essentially about data rights and responsibilities when you get right down to it, and the difficult idea that information cannot be owned. See @fredtrotter's post on this topic: fredtrotter.com/2009/10/27/who… Unhashing this debate would make all of this simpler.

#NoBlocking permits "actors to license interoperability elements on reasonable and non-discriminatory (RAND) terms, provided that certain conditions are met."

#NoBlocking Conditions under the licensing exception include:
1) response to a request and making an offer
2) RAND terms
3) degrading or impeding use
4) compliance with certification

As far as I can see, nothing requires an API Technology Provider or Data Provider to license interoperabily elements order to charge fees. If they want to charge for the IP, they have to behave a certain way (e.g., RAND terms), but they could just refuse to license it to any

I think somewhere, there should be a transparency requirement that enables a technology provider to identify those interoperability elements that they have chosen to offer, and leaves them off the hook for requests for non-listed interoperability elements.

So here's another interesting challenge. My credit score could be data kept by an HCP in a system (an EHR even) that identifies me, and relates to the future payment for provision of healthcare, as could "so called propensity to pay" scores.

By definition, that's EHI

But the provider payed a license to use that data ... it's not really their's to share ... in fact, their license may restrict their reuse of that data. Credit agencies license data like this to credit issuers, but don't allow them to furbish it to non-associates #NoBlocking

Other data derived by proprietary IP might be considered EHI, but again is or could be licensed information.

Anyway, back to licensing exception:
"actors are not required to seek the protection of this (or any other) exception. If an actor does not want to license a particular technology, it may choose to comply with the information blocking provision in another way, ..." #NoBlocking

#NoBlocking clarifies that the licensing conditions "would not preclude an actor and a willing licensee from agreeing to such an arrangement, so long as the arrangement was not required." wrt to prohibited required terms

. @ONC_HealthIT is "considering whether we would should propose, in a future rulemaking, a narrow exception to the information blocking provision for practices that are necessary to comply with the requirements of the Common Agreement." for #NoBlocking which makes sense to me

. @ONC_HealthIT would "welcome comment on any potential new exceptions we should consider for future rulemaking." As a hint, that means, if not already discussed as an exception, it's out of scope for this round of rulemaking, but could be considered in the future. #NoBlocking

#NoBlocking proposes healthit.gov/form/healthit-… as one mechanism for submitting complaints and asks for additional information at p502 (nearly done!)

OK, I'm done. Having reached this point, it's time for a final music break, as my brain hurts: #NoBlocking