• contact.us@gravelygroup.com

This should be a simple question, but it really is not! An Information Blocking violation consists of the following components:

  • An Actor
  • Engages in a “practice”
  • That the Actor knows or, in some cases, should know
  • Is likely to
  • Interfere with the access, exchange, or use of Electronic Health Information (EHI)[1] and
  • The “practice” is not required by law OR
  • The “practice” does not meet one of the eight exceptions identified by ONC.

Identifying “Practices”

We have discussed in a previous post how an individual or entity can determine if they are an Actor for purposes of the Information Blocking Rule. In order to violate the Information Blocking Rule, the Actor must engage in a “practice.” However, the ONC Information Blocking Rule tells us that a practice can be either something that an Actor does—an act—or something that an Actor should do but fails to do—an omission. In theory, a practice could be just about anything. This is very frustrating for many Actors because it seems overwhelming, and Actors do not know where to start in evaluating their risk. ONC recognizes this and has identified 42 specific practices that implicate information blocking:

  1. Formal restrictions through contract or license terms, EHI access policies, organizational policies and procedures, or other instruments or documents that relate to EHI or health IT
  2. Exercising IP rights or other rights
  3. Health system policy requiring consent to exchange EHI for treatment even though not required by law
  4. EHR developer refuses to share technical information needed to export data
  5. HIN restriction on end-user sharing of EHI with non-HIN members
  6. Health system citing HIPAA as a reason that it cannot share EHI when that it not the case
  7. EHR vendor only provides EHI in PDF format upon termination of an agreement with a customer
  8. An EHR developer sues to prevent a clinical data registry from providing interfaces to physicians who use the developer’s EHR technology and wish to submit EHI to the registry. The EHR developer claims that the registry is infringing the developer’s copyright in its database because the interface incorporates data mapping that references the table headings and rows of the EHR database in which the EHI is stored.
  9. A health IT developer of certified health IT refuses to license interoperability elements that are reasonably necessary for the developer’s customers, their IT contractors, and other health IT developers to develop and deploy software that will work with the certified health IT.
  10. An EHR developer ostensibly allows third-party developers to deploy apps that are interoperable with its EHR system. However, as a condition of doing so, the third-party developers must provide their source code and grant the EHR developer the right to use it for its own purposes—terms that almost no developer would willingly accept.
  11. Disabling or restricting the use of a capability that enables users to share EHI with users of other systems or to provide access to EHI to certain types of persons or for certain purposes that are legally permissible.
  12. An actor configures or otherwise implements technology in ways that limit the types of data elements that can be exported or used from the technology.
  13. Configuring capabilities in a way that removes important context, structure, or meaning from the EHI, or that makes the data less accurate, complete, or usable for important purposes for which it may be needed.
  14. Implementing capabilities in ways that create unnecessary delays or response times, or that otherwise limit the timeliness of EHI accessed or exchanged.
  15. An actor deploys technological measures that limit or restrict the ability to reverse engineer the functional aspects of technology in order to develop means for extracting and using EHI maintained in the technology.
  16. A health system implements locally-hosted EHR technology certified to proposed § 170.315(g)(10) (the health system acts as an API Data Provider as defined by § 170.102). As required by proposed § 170.404(b)(2), the technology developer provides the health system with the capability to automatically publish its production endpoints (i.e., the internet servers that an app must “call” and interact with in order to request and exchange patient data). The health system chooses not to enable this capability, however, and provides the production endpoint information only to apps it specifically approves. This prevents other applications—and patients that use them—from accessing data that should be made readily accessible via standardized APIs.
  17. A hospital directs its EHR developer to configure its technology so that users cannot easily send electronic patient referrals and associated EHI to unaffiliated providers, even when the user knows the Direct address and/or identity (i.e., National Provider Identifier) of the unaffiliated provider.
  18. An EHR developer that prevents (such as by way of imposing exorbitant fees unrelated to the developer’s costs, or by some technological means) a third-party clinical decision support (CDS) app from writing EHI to the records maintained by the EHR developer on behalf of a health care provider (despite the provider authorizing the third-party app developer’s use of EHI) because the EHR developer: (1) offers a competing CDS software to the third-party app; and (2) includes functionality (e.g., APIs) in its health IT that would provide the third party with the technical capability to modify those records as desired by the health care provider.
  19. Although an EHR developer’s patient portal offers the capability for patients to directly transmit or request for direct transmission of their EHI to a third party, the developer’s customers (e.g., health care providers) choose not to enable this capability.
  20. A health care provider has the capability to provide same-day access to EHI in a form and format requested by a patient or a patient’s health care provider but takes several days to respond.
  21. A health IT developer of certified health IT refuses to license an API’s interoperability elements, to grant the rights necessary to commercially distribute applications that use the API’s interoperability elements, or to provide the related services necessary to enable the use of such applications in production environments.
  22. An EHR developer of certified health IT requires third-party applications to be “vetted” for security before use but does not promptly conduct the vetting or conducts the vetting in a discriminatory or exclusionary manner.
  23. A health IT developer of certified health IT refuses to license interoperability elements that other software applications require to efficiently access, exchange, and use EHI maintained in the developer’s technology.
  24. An EHR developer of certified health IT maintains an “app store” through which other developers can have “apps” listed that run natively on the EHR developer’s platform. However, if an app “competes” with the EHR developer’s apps or apps it plans to develop, the developer requires that the app developer grant the developer the right to use the app’s source code.
  25. A health care provider engages a systems integrator to develop an interface engine. However, the provider’s license agreement with its EHR developer prohibits it from disclosing technical documentation that the systems integrator needs to perform the work. The EHR developer states that it will only permit the systems integrator to access the documentation if all of its employees sign a broad non-compete agreement that would effectively bar them from working for any other health IT companies.
  26. An EHR developer of certified health IT maintains an “app store” through which other developers can have “apps” listed that run natively on the EHR developer’s platform. The EHR developer charges app developers a substantial fee for this service unless an app developer agrees not to deploy the app in any other EHR developers’ app stores.
  27. A hospital is working with several health IT developers to develop an application that will enable ambulatory providers who use different EHR systems to access and update patient data in the hospital’s EHR system from within their ambulatory EHR workflows. The inpatient EHR developer, being a health IT developer of certified health IT, pressures the hospital to abandon this project, stating that if it does not it will no longer receive the latest updates and features for its inpatient EHR system.
  28. A health IT developer of certified health IT discourages customers from procuring data integration capabilities from a third-party developer, claiming that it will be providing such capabilities free of charge in the next release of its product. In reality, the capabilities it is developing are more limited in scope and are still 12-18 months from being production ready.
  29. A health system insists that local physicians adopt its EHR platform, which provides limited connectivity with competing hospitals and facilities. The health system threatens to revoke admitting privileges for physicians that do not comply.
  30. An HIN charges additional fees, requires more stringent testing or certification requirements, or imposes additional terms for participants that are competitors, are potential competitors, or may use EHI obtained via the HIN in a way that facilitates competition with the HIN.
  31. A health care provider imposes one set of fees and terms to establish interfaces or data sharing arrangements with several registries and exchanges but offers another costlier or significantly onerous set of terms to establish substantially similar interfaces and arrangements with an HIE or HIN that is used primarily by health plans that purchase health care services from the provider at negotiated reduced rates.
  32. A health IT developer of certified health IT charges customers fees, throttles speeds, or limits the number of records they can export when exchanging EHI with a regional HIE that supports exchange among users of competing health IT products but does not impose like fees or limitations when its customers exchange EHI with enterprise HIEs that primarily serve users of the developer’s own technology.
  33. As a condition of disclosing interoperability elements to third-party developers, an EHR developer requires third-party developers to enter into business associate agreements with all of the EHR developer’s covered entity customers, even if the work being done is not for the benefit of the covered entities.
  34. A health IT developer of certified health IT takes significantly longer to provide or update interfaces that facilitate the exchange of EHI with users of competing technologies or services
  35. Certain practices that artificially increase the cost and expense associated with accessing, exchanging, and using EHI will implicate the information blocking provision. An actor may seek to extract profits or capture revenue streams that would be unobtainable without control of a technology or other interoperability elements that are necessary to enable or facilitate access, exchange, or use of EHI.
  36. An EHR developer of certified health IT charges customers a fee to provide interfaces, connections, data export, data conversion or migration, or other interoperability services, where the amount of the fee exceeds the actual costs that the developer reasonably incurred to provide the services to the particular customer(s).
  37. An EHR developer of certified health IT charges a fee to perform an export using the EHI export capability proposed in § 170.315(b)(10) for the purposes of switching health IT systems or to provide patients access to EHI.
  38. An EHR developer of certified health IT charges more to export or use EHI in certain situations or for certain purposes, such as when a customer is transitioning to a competing technology or attempting to export data for use with a HIE, third-party application, or other technology or service that competes with the revenue opportunities associated with the EHR developer’s own suite of products and services.
  39. An EHR developer of certified health IT interposes itself between a customer and a third party developer, insisting that the developer pay a licensing fee, royalty, or other payment in exchange for permission to access the EHR system or related documentation, where the fee is not reasonably necessary to cover any additional costs the EHR developer incurs from the third-party developer’s activities.
  40. An analytics company provides services to the customers of an EHR developer of certified health IT, including de-identifying customer EHI and combining it with other data to identify areas for quality improvement. The EHR developer insists on a revenue sharing arrangement whereby it would receive a percentage of the revenue generated from these activities in return for facilitating access to its customers’ EHI, which turns out to be disadvantageous to customers. The revenue the EHR developer would receive exceeds its reasonable costs of facilitating the access to EHI.
  41. An EHR developer of certified health IT implements the C-CDA for receiving transitions of care summaries but only sends transitions of care summaries in a proprietary or outmoded format.
  42. A health IT developer of certified health IT adheres to the “required” portions of a widely adopted industry standard but chooses to implement proprietary approaches for “optional” parts of the standard when other interoperable means are readily available.

These 42 practices are pretty extensive, but ONC makes it very clear that these are only examples. They are a good place to start as you consider any practices that your organization is engaged in that could implicate information blocking. But remember, even if you determine that your organization is not engaging in any of these 42 practices, you must still consider anything else that your organization is doing that interferes with the access, exchange, or use of EHI. You may identify a lot more practices, or none at all, but the important point is that you go through the exercise of identifying practices—things that your organization does or fails to do—that interfere with access, exchange, or use of EHI.

Intent
Just because an Actor engages in one or more “practice” does not mean that the Actor is violating the Information Blocking Rule. In order to violate the Information Blocking Rule, an Actor must have intent. But, what does that mean? In order to violate the Information Blocking rule, an Actor must engage in a practice that it knows or should have known is likely to interfere with the access, exchange, or use of EHI. For healthcare provider Actors, there must be actual knowledge that the practice is unreasonable and likely to interfere with access, exchange, or use of EHI. However, ONC has not defined “unreasonable,” so it remains to be seen how ONC and the OIG will interpret this term in the context of a practice by a healthcare provider Actor. HIN or health IT developer Actors can violate the Information Blocking Rule if they actually knew, or if they should have known, that their practice would likely interfere with the access, exchange, or use of EHI. This different knowledge standard means that HIN and/or certified health IT developer Actors are at greater risk to violate the Information Blocking Rule because a complainant could allege that such an Actor “should have known” that its practice(s) would likely interfere with access, exchange, or use of EHI. This does increase the risk for HINs and certified health IT developers, since they can inadvertently commit an information blocking violation.

Practices Required by Law or Meeting an Exception
Does this mean if an Actor engages in a practice that it knows, or should know, is likely to interfere with the access, exchange, or use of EHI that it automatically commits an information blocking violation? No, an Actor has two ways of avoiding a violation: first, if the practice is required by law; or, second, if the practice falls into one of the eight exceptions identified by ONC. Let’s briefly unpack these.

A practice is required by law if there is specific legal authority that requires the Actor to not fulfill a request for EHI. This legal authority could be state or federal law, tribal law, or any regulation or ordinance that has the force and effect of law. The burden is on the Actor to prove that its practice is required by law, which means that any Actor planning to assert this should have clear documentation of the legal requirement on which it is relying. Even if an Actor’s practice is not required by law, the Actor may still not have engaged in an information blocking violation if its failure to fulfill a request for EHI fits within one of the eight exceptions identified by ONC in the Final Rule. We discuss these exceptions beginning in our next post.

Download a copy of this post

[1] For healthcare providers, the standard includes knowing that the practice is unreasonable and likely to interfere with access, exchange, or use of EHI.

©2023. Gravely Group. All Rights Reserved.

Disclaimer