- Hello and welcome to this CLE titled "Navigating the Information Blocking Rule: Compliance Challenges and Risk Mitigation Strategies." I'm Bethany Corbin, Senior Council at Nixon Gwilt Law, where I work extensively with medical devices and healthcare innovation companies seeking to disrupt standard care delivery and care coordination models. And as part of my practice, I help healthcare clients navigate the changing interoperability landscape, and in particular, the relatively recent Information Blocking Rules that resulted in a paradigm shift for the use and disclosure of electronic health information. I'm excited to talk with you today about the background of the Information Blocking Rule and interoperability, and discuss common compliance challenges that healthcare companies have faced in adhering to the rule. This presentation is going to proceed in three segments, so first I'll provide background on interoperability and the Information Blocking Rule. As part of this discussion, I'll explain the electronic health record landscape leading up to the Information Blocking Rule and the catalyst for passage of that Information Blocking Rule. I'll then discuss the Information Blocking Rule's applicability, its requirements, and its exceptions. Second, I'll present common compliance challenges that have arisen for healthcare actors attempting to implement and comply with the Information Blocking Rule. And finally, I'll discuss some risk mitigation strategies that can help combat these compliance challenges. So let's start first by understanding interoperability in healthcare. Information blocking has really been front and center in the minds of healthcare actors since the passage of the Information Blocking Rule by the Department of Health and Human Services, or HHS, Office of the National Coordinator, ONC, in early 2020. the Information Blocking Rule really fundamentally shifted the way in which healthcare actors access, use, and disclose electronic health information, or EHI. However, before we get into the specifics of the Information Blocking Rule, I want to discuss the interoperability landscape in the U.S. before 2022, and that really serves as the catalyst for passage of the Information Blocking Rule in the first place. And by really understanding the environment that preceded the Information Blocking Rule, we can get a much better indication of what the Information Blocking Rule was actually intended to address and whether it did achieve its stated goals. So when we talk about interoperability, what exactly do we mean? At the most basic level, interoperability refers to the ability of computerized systems to easily and readily connect and interact or communicate with each other, even though each computerized system might have been developed by a different manufacturer or might be primarily used in a different industry. This means that the overarching goal of interoperability is really the seamless exchange of information between applications, computer systems, and databases. As you'll note by the definition that I've just provided, interoperability is not limited to healthcare, however, when we're talking about interoperability in the healthcare context, we refine this definition a bit. So in healthcare, interoperability really means the seamless exchange and integration of health data and health records across systems, devices, and applications, regardless of regional or national boundaries, and the goal is to provide portability of health data and to optimize the health of individuals within the general population. So stated more simply, interoperability in healthcare is deeply focused on the free flow of health data to enhance health and wellness outcomes for patients and the larger population. The goal of interoperability is really to give patients control over their health data and have that health data essentially follow the patient from provider to provider in real time. So think of it like a health record that is continuously updated in real time and moving with the patient in a seamless and effortless manner. That's interoperability. The idea of interoperability really started to gain ground in the early 2000s with the movement from paper to electronic health records. Prior to the 1960s, almost all medical records existed in paper form and they were manually organized into filing systems. In the mid 1960s however, the first electronic clinical information system was developed, and that formed the basis for the electronic health record, or EHR, system. With the invention of the EHR, providers had their first real widespread opportunity to digitize health data, yet it wasn't until the early 2000s that EHRs were widely adopted by healthcare organizations. And in fact, in 2004, HHS created the Office of the National Coordinator of Health Information Technology to promote a national health information technology infrastructure, and to encourage providers to transition records from paper to electronic formats. Shortly thereafter, Congress authorized incentive payments to healthcare providers who satisfied the meaningful use criteria, and that included the adoption and use of EHRs. Congress really sought here to encourage widespread adoption of EHRs, and it did so through the Health Information Technology for Economic and Clinical Health Act, or the HITECH Act. Historically, achieving the goals of interoperability has forced the healthcare industry to rely heavily on health information exchanges, or HIEs, and data-sharing technology. HIEs work by electronically moving clinical and medical data among different health information systems, while still maintaining the integrity and the original meaning of that clinical and medical data. Why is this necessary? Well, in today's environment, most patients will have multiple encounters with healthcare professionals. For example, one patient may visit a primary care provider, a urology specialist, a dermatologist, and an urgent care location. Patient data is created, maintained, accessed, used, and stored at each point along this encounter chain, but the problem is that that data doesn't always reside in one centralized location. Rather, each physician or healthcare network may use its own EHR system that does not talk to or communicate with other EHR systems, and this results in the creation of disparate data, which is not collected and synthesized to provide a holistic view of the patient's medical record and health history, and the result is impeded care coordination and less than ideal patient care outcomes. And this is why HIEs are necessary and they have served a vital role in promoting interoperability. An HIE is really a tool that promotes enhanced patient care coordination and improved health outcomes by ensuring data can pass effortlessly between various healthcare systems and EHRs, and this really helps to ensure that all healthcare professionals serving a patient have access to all relevant health history, and this has the benefit of reducing duplicative testing and ensuring that healthcare recommendations among providers are not contradictory. HIEs can also help reduce medical errors, reduce overall healthcare costs, for example, by eliminating that redundant testing, and encourage patients to be involved in their own care. There are three main types or forms of HIEs that you'll wanna be familiar with. The first is known as directed exchange. Directed exchange is the ability to send and receive secure information electronically between healthcare providers, with the goal of supporting coordinated care for the patient. Using directed exchange, providers can easily send patient information, such as lab results and patient referrals, to other healthcare professionals over the internet in an encrypted and secure manner. You may also see directed exchange being used to send things like immunization data to public health organizations, or to report quality measures to the Centers for Medicare and Medicaid Services, or CMS. An example of directed exchange would be something like providers exchanging secure emails that contain health information. The second type of HIE is what's known as the query-based exchange, and this exchange is used by providers to search and find clinical sources on a patient. So query-based exchange is most often used when a provider has to deliver unplanned care to a patient. So for example, an emergency room physician who does not otherwise have access to the patient's health records, can use a query-based exchange to try to access patient information such as medications and health problem lists during the patient encounter. The third type of HIE is the consumer-mediated exchange, and this type of exchange provides patients with access to health information, and allows patients to really manage their health and wellness online. The goal of the consumer-mediated exchange is to place patients in charge of their health data and medical care, allowing them to be active participants in that care and to facilitate care coordination. Through a consumer-mediated exchange, a patient may be able to give other providers their health information, identify and correct wrong health data, supply missing health data, and track and monitor their own health. Now, achieving the goals of interoperability in HIEs have not always been an easy task. In fact, there have been significant barriers to the free flow of healthcare data. Oftentimes, the lack of seamless data flow is a direct consequence of EHR systems that were actually not designed to interact with and shared data with non-affiliated EHR systems. And in this manner, the fundamental design of EHR systems can serve as a barrier to the goals of interoperability. Further, interoperability can also be impeded by intentional practices by EHR or technology vendors and healthcare providers. From the vendor perspective, interoperability limitations may arise when vendors intentionally implement their health information technology in a non-standard way, and when this happens, there is significantly increased complexity and burden of accessing and exchanging EHI between systems. Similarly, a health information technology, or IT, manufacturer could refuse to license or disclose the interoperability elements of its system to allow other EHRs to access data. It's important to note that the goal of many health IT manufacturers and developers in these cases, is actually not to harm patients. Rather, health IT manufacturers and developers are driven by their desire to augment their market power and secure certain economic advantages through their non-standard technology. Unfortunately, the practical reality though, is that patients are harmed in the process because their health data cannot be shared seamlessly between providers to ensure care coordination. A 2021 study from "The Journal of the American Medical Informatics Association" found that EHR vendors are actually more likely than healthcare systems to engage in practices that inhibit information sharing and interoperability. And in particular, the journal surveyed 89 health information exchanges, and 55% of respondents said that EHR vendors were engaging in practices that limit interoperability. This most common vendor practice that restricts interoperability is setting unreasonable prices for providing access to EHR systems. Another common vendor practice that can restrict interoperability is refusing to share EHR information. Now that said, barriers to interoperability do not only exist from the vendor perspective, and in fact, healthcare providers have often refused to share health data, which results in reduced interoperability. Hesitancy among healthcare providers to share health data really stems from a misunderstanding of the Health Insurance Portability and Accountability Act, or HIPAA. Specifically, the HIPAA privacy rule prevents covered entities from disclosing protected health information, unless an exception applies that requires or permits the disclosure. Although HIPAA has an exception that allows for the transfer and exchange of health information for treatment, payment, and healthcare operations, many providers are cautious about the circumstances under which they exchange health data. So this means that while a disclosure of health data to another provider for treatment purposes may be permissible, it's not required, and because it's not required, some healthcare providers may elect not to share the data in order to minimize risk. So given these hurdles to interoperability and the continued drive to digitize patient health records, ONC passed the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule on March 9th, 2020, and that's known as the Information Blocking Rule. This Information Blocking Rule does two things. First, it establishes a secure, standards-based application programming interface, API, requirements to support patient access and control of EHI. Now, we'll not be exploring this portion of the rule in depth in this CLE because we don't have time. And second, the rule prohibits information blocking, which includes defining what information blocking is, creating eight exceptions to the information blocking definition, and setting the stage for future information blocking penalties and rulemaking, and this portion of the Information Blocking Rule is where we are going to focus on for the remainder of our presentation. While ONC announced its Information Blocking Rule in March, 2020, the rule was published in the federal register on May 1st, 2020 alongside a very similar interoperability rule from its sister agency, CMS. Both ONC and CMS are housed within the Department of Health and Human Services, and as a result, these agencies interacted and coordinated the rulemaking efforts. The CMS rule addresses interoperability requirements for health plans and payers. And in particular, the CMS interoperability rule expanded upon the foundation that was established by the ONC Information Blocking Rule by requiring health plans in Medicare Advantage, Medicaid, Children's Health Insurance Program, and other federal exchanges to share claims data electronically with patients via a secure, user-friendly patient access API. And this patient access API in turn, permits patients to obtain and access health data through third-party applications that connect to the API, and it enables integration of health plan data into a patient's EHR. Together, the OMC and CMS rules represent a significant step by the federal government to enhance data sharing practices and give patients control over their health records. While the CMS rule is equally important, further discussion of that rule is also going to be outside the scope of today's presentation. Today's presentation is going to focus only on the ONC Information Blocking Rule. So given that background, this then leads us to the next question, which is what is information blocking? Information blocking refers to practices conducted by healthcare actors that are likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI. Now let's break this definition down further so that we can understand each element. First, the Information Blocking Rule does not apply to everyone in the healthcare industry. Rather, to be subject to the Information Blocking Rule, the person or entity who is engaged in a practice that limits or prohibits access, exchange, or use of EHI, must be a healthcare actor. A healthcare actor means a healthcare provider, a health information technology developer, a health information network, or a health information exchange. Second, the data that is the subject of the access, use, or disclosure limitation must be EHI. EHI is a subset of protected health information under HIPAA, and until October 6th, 2022, EHI is defined to mean only those data elements represented in the United States Core Data for Interoperability, USCDI. Use of the USCDI standard is new for OMC, as the organization previously focused data sharing on the more limited Common Clinical Dataset, CCDS. USCDI is a standardized set of health data classes and data elements for nationwide interoperable health information exchange, and it includes data such as plan of treatment, clinical notes, vital signs, and much more. After October 6th, 2022 however, the definition of EHI expands to encompass all electronic protected health information that is included in a designated record set exclusive of psychotherapy notes or information that is compiled in reasonable anticipation of or for use in a civil, criminal, or administrative proceeding. Next, there has to be what is known as an interference with the access, use, or exchange of EHI by the healthcare actor. What is an interference? Well, interference can take many forms. It may, for instance, be the prevention or material discouragement of access or use of EHI. Alternatively, it could be an action that increases the cost or complexity of a patient accessing their EHI. Similarly, it could be a practice that limits the value of the EHI to the patient that the patient is actually permitted to access. Now, not all interferences with the free flow of health data are going to rise to this level of information blocking. The Information Blocking Rule expressly excludes from the definition of information blocking any practices that are required by state or federal law. So this means that if a state or federal law requires the withholding of certain health information from a patient or otherwise limits the disclosure of that health information to other providers, then the provider's refusal to disclose such data will not be deemed information blocking. Finally, a healthcare actor must possess the requisite knowledge to violate the Information Blocking Rule. In other words, liability for information blocking only attaches if the healthcare actor satisfies the knowledge standard. If an interference is conducted by a healthcare provider, the provider must have known that such practice was unreasonable and likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI. In contrast, if a practice is conducted by a health information technology developer, health information network, or HIE, then the developer, network, or HIE must have known or should have known that the practice was likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI. So the knowledge standard differs depending on who the healthcare actor is. If all of the above elements are met, then the Information Blocking Rule is going to apply to determine whether the misconduct violates that rule. Given this definition of information blocking, you might be wondering what information blocking practices actually look like in real life. So some examples of information blocking could include requiring a patient's written consent before sharing the patient's EHI with other providers, erroneously using the HIPAA privacy rule as a shield to delay or withhold the sharing or disclosure of EHI, charging excessive fees for the exchange of EHI, which may make exchange entirely cost prohibitive, adopting policies that restrict information sharing, and locking patients or providers into a particular EHR or other technology network, and making it so their EHI is not portable. All right, just because a practice satisfies the definition of information blocking does not automatically mean that the practice is going to be illegal or that it constitutes information blocking. There are circumstances in which a practice that impedes the free flow of health data will not constitute information blocking, either because the practice is permitted by state or federal law, or because the actor satisfies an exception to the information blocking prohibition. ONC has created eight exceptions to the general prohibition on information blocking, and these exceptions were designed to recognize that there are oftentimes legitimate and important public policy interests that will require a healthcare actor to interfere sometimes with a patient's access, use, or exchange of EHI. Now there are eight exceptions, and they can be divided broadly into two main categories. The first category of exceptions is exceptions that involve not fulfilling requests to access, exchange, or use EHI. The exceptions that fall within this category are the Preventing Harm Exception, the Privacy Exception, the Security Exception, the Infeasibility Exception, and the Health IT Performance Exception. The second category of exceptions is exceptions that allow healthcare providers to follow certain procedures that would otherwise result in information blocking when fulfilling requests to access, exchange, or use EHI. And this category of exceptions includes the Licensing Exception, Fees Exception, and Content and Manner Exception. And all of these exceptions have numerous elements that have to be satisfied in order to take advantage of the safe harbor effect that these exceptions provide. And while a full analysis of every single exception is going to be beyond the scope of this presentation, I do wanna give you a high-level look at the overarching requirements for these exceptions so you can start to get familiar with them. So let's look first at the Preventing Harm Exception. Pursuant to the Preventing Harm Exception, which is found at 45 CFR section 171.201, a healthcare actor may engage in practices that are reasonable and necessary to prevent harm to a patient or another person, even if such practices delay or restrict access to EHI. The Preventing Harm Exception recognizes that the public interest in protecting patients and other individuals against unreasonable risks of harm supersedes the patient's right to the non-interference with that access, exchange, or use of their EHI. For the Preventing Harm Exception to apply, the actor must hold a reasonable belief that the practice will substantially reduce a risk of harm, and the actor's practice must not be broader than absolutely necessary to reduce the risk of harm, and it also has to satisfy at least one condition from each of the following categories: type of risk, type of harm, and implementation basis. And the actor must also comply with the condition that concerns the patient's right to request review of an individualized determination of risk of harm. The next exception is the Privacy Exception, which can be found at 45 CFR section 171.202, and the Privacy Exception permits a healthcare actor to refuse a request to access, exchange, or use EHI if doing so will protect an individual's privacy. This exception recognizes that an actor should not be required to use or disclose EHI in a way that's prohibited under state or federal privacy laws. An actor that is a covered entity or business associate may also deny an individual's request for access to their EHI in the circumstances that are provided under 45 CFR section 164.524 subsection and of the HIPAA privacy rule. Further, an actor may choose not to access, exchange, or use an individual's EHI if doing so is in line with or fulfills the wishes of the individual whose data is at issue, provided that certain conditions are met. The next exception is the Security Exception, which permits a healthcare actor to refuse a request to access, exchange, or use EHI if doing so will protect the security of EHI. This exception covers legitimate security practices by actors, but it does not require a maximum level of security or otherwise dictate a security approach or framework. To use this exception, the practice must be first, directly related to safeguarding the confidentiality, integrity, and availability of EHI, second, specifically tailored to the security risks at issue, and third, implemented in a consistent and non-discriminatory manner. The practice must either implement a qualifying organizational security policy or implement a qualifying security determination. The next exception is the Infeasibility Exception, and as its name suggests, the Infeasibility Exception allows a healthcare provider or actor to withhold EHI if its release is otherwise infeasible. The purpose of this exception is to recognize and also respect legitimate practical challenges that may arise to impede an actor's ability to comply with requests to access, use, or exchange EHI. So there are going to be times when an actor does not have the requisite technological capabilities or legal rights to enable this type of access, exchange, or use, and this exception is really intended for those circumstances. To use this exception, the actor must demonstrate infeasibility, and infeasibility can be demonstrated through uncontrollable events, such as when an actor cannot fulfill an EHI access, use, or exchange request due to something like a natural or human-made disaster, a public health emergency, war, labor unrest, et cetera. Alternatively, infeasibility could be demonstrated under the circumstances, such as a written record or documentation that explains why complying with the request would be infeasible under the circumstances. Another common instance of infeasibility is segmentation, and that occurs when a healthcare actor cannot fulfill the request for access, exchange, or use of EHI because the actor cannot segment the requested EHI from the rest of the patient's record. When an actor is presented with a request for EHI, that actor must provide a written response to the request within 10 business days of receipt, and should explain why that request is infeasible. The next exception is the Health IT Performance Exception. This exception allows actors to take reasonable and necessary measures to make health IT temporarily unavailable or to lower the performance of the health IT for the benefit of the overall performance of the health IT. This exception recognizes that proper performance of health IT requires necessary maintenance, which may also require that the health IT be taken offline temporarily. To use this exception, the practice must be for a period of time that's no longer the necessary to achieve the maintenance or improvements. In addition, the practice has to be implemented in a consistent and non-discriminatory manner, and meet certain other requirements. If the unavailability of the technology is due to something like a risk of harm or a security risk, then the healthcare actor need only comply with the Preventing Harm or the Security Exception as applicable. The Licensing Exception is the next exception, and it provides the conditions under which a healthcare actor can license interoperability elements to access user exchange EHI. This exception allows healthcare actors to protect the value of their innovations and to charge reasonable royalties to earn returns on investments that they have made to develop and maintain their innovations. And there are certain licensing conditions and license condition negotiation requirements that you would need to satisfy before this exception could apply. The next exception is the Fees Exception. So the Fees Exception defines when it is acceptable for an actor to charge a fee, including fees that result in a reasonable profit margin for access, exchange, or use of EHI. This exception permits actors to charge fees that are related to the development of technologies that promote and enhance interoperability. This exception though, does not apply to protect rent-seeking and opportunistic fees. In order to charge a fee, the actor must ensure that the fee is based on objective and verifiable criteria that are uniformly applied to all similarly-situated persons or entities. The fees must be reasonably related to the actor's cost of providing the type of access, exchange, or use of EHI, and the fees cannot be based on whether the requester is a competitor or potential competitor. The actor is also comply with the conditions of certification. And finally, the Content and Manner Exception limits the content that must be included in a healthcare actor's response to a request to access, exchange, or use EHI, and it offers flexibility in the manner in which a healthcare actor fulfills that request. This exception serves to provide flexibility to actors regarding the required content of that actor's response to a request for EHI, and flexibility in the manner in which the actor can fulfill that request. This exception allows actors to attempt to reach and maintain market-negotiated terms for EHI use, access, and exchange. So let's look first at the content portion of this exception. The content portion concerns the scope of EHI that must be provided. As noted previously, EHI is currently limited to the USCDI standard, but it's going to expand in October, 2022 to encompass all electronic protected health information that's included in a designated record set, with certain exceptions that we've already discussed. Now, let's look at the manner exception. The manner portion of the exception focuses on the way in which an actor fulfills a request to access, exchange, or use EHI. Specifically, an actor may fulfill a request for access, exchange, or use of EHI in an alternative manner when the actor is technically unable to fulfill the request in the manner that was requested, or cannot reach agreeable terms with the requester to fulfill the request. If an actor fulfills a request in an alternative manner, such fulfillment has to comply with the specified order of priority that's set forth in the Information Blocking Rule, and that standard and flow of priority is as follows: first, using technology certified to standards adopted by 45 CFR part 170 that is specified by the requester, second, using content and transport standards specified by the requester and published by the federal government or a standards developing organization that is accredited by the American National Standards Institute, and third, using an alternative machine-readable format agreed upon with the requester. If you use the Content and Manner Exception, you have to fulfill the request without unnecessary delay. All right, so now that we understand the basics around information blocking, let's move to the next portion of the presentation, which focuses on some common compliance challenges that actors face when they attempt to adhere to the Information Blocking Rule. And the compliance date for the Information Blocking Rule was April 5th, 2021, and prior to this date, most healthcare actors focused on revising their policies and procedures to account for the new information blocking requirements, and they focused on updating their EHR systems so that they could ensure the seamless exchange of health data. A lot of healthcare organizations were also focusing their attention on understanding the information blocking requirements and figuring out how the Information Blocking Rule even fit within the framework of existing healthcare laws and regulations. In particular, one of the main compliance challenges that occurred in the lead up to the Information Blocking Rule's implementation date was the interplay between this new Information Blocking Rule and its requirements, and HIPAA. The HIPAA privacy rule, as we know, operates as a permissive disclosure framework for health information in which protected health information cannot be disclosed unless it fits within a required or permissive disclosure exception. The Information Blocking Rule though, turns the HIPAA privacy rule on its head, and specifically, the Information Blocking Rule requires the disclosure of electronic health information, unless an exception applies that limits or prohibits the disclosure. So working through this paradigm shift was really difficult for healthcare providers in the beginning because it required them to fundamentally shift their thinking about healthcare privacy and interoperability. It was also very difficult in the beginning because of the COVID-19 pandemic. A lot of providers and actors in healthcare were focused on responding to the national pandemic and the crisis that was occurring in the United States at that time, and they weren't focused on having to change their entire policies, organizational structure, you know, the way that they respond to health information requests. And for that reason, the implementation date of the Information Blocking Rule got pushed back several times because of the burden that was already placed on healthcare providers. Now that the Information Blocking Rule has been in effect for over a year, the questions that healthcare actors are asking about information blocking are starting to evolve, so I wanna talk about three very common compliance questions and concerns that have arisen from the Information Blocking Rule more than a year after its passage. The first compliance concern I wanna talk about is expansion of EHI. As we know, with the October 6th, 2022 deadline looming for the expansion of EHI, healthcare actors are really searching for clarity about how to best implement this new definition of EHI, and what it actually means for their compliance programs and obligations. On August 18th, 2022, 28 health IT professional associations, provider organizations, and other stakeholders submitted a letter to the HHS secretary warning that compliance would likely fall short and not be achieved if the agency did not address what the group was calling significant knowledge gaps with respect to information blocking implementation and enforcement, and in particular, healthcare actors want to ensure that they have sufficient time to adapt their technology and their compliance programs to meet the new requirements that are going to be imposed with the changing definition of EHI. To the extent that healthcare actors have not already done so, ONC has recommended that they start expanding their technology and policies and procedures to encompass that full scope of EHI in the revised definition that's set to take effect in October. And this recommendation was really designed to give healthcare actors time to test their systems against broader EHI accessibility without facing information blocking claims or penalties for those additional EHI data sources and data entries. So it was almost like a test period between that first USCDI definition for EHI and the more fulsome definition that goes into effect in October. As more data is integrated and exchanged, it means that healthcare actors are necessarily going to need to update their policies and their procedures to reflect the new scope of EHI and address problem areas that come up with exchanging this expanded scope of EHI. So to that end, organizations should not wait until the last minute to update their compliance programs and processes, and if they have, it's something that they need to start focusing on now, as information blocking compliance penalties are on the horizon, and I'll talk more about updating policies and procedures as a risk mitigation tactic in a few moments. The second compliance challenge that's really arisen since passage of the Information Blocking Rule is efficient and clear communication between patients and providers. Patients that are aware of the Information Blocking Rule are starting to ask more questions about their data, and some patients are actually finding mistakes or mismatches between services that the patient obtained and those that were reported in the medical record. Further, there have already been numerous complaints by patients against providers alleging information blocking because of a provider's failure to access or exchange EHI in a timely manner under the Information Blocking Rule. Indeed, some small and rural provider groups are actually still not aware of the Information Blocking Rule, and they have not come into compliance with those initial provisions that were passed, so to avoid claims of information blocking and to ensure that patients and providers are aligned on their rights and obligations, it's important to facilitate clear and effective communication between all parties. To mitigate against this risk, one thing that you'll want to ensure is that the healthcare actor has, again, clear policies and procedures on what to do if they receive a request from a patient to access health information, to modify a health record, or to reconcile services billed with services that the patient remembers receiving. And again, I'll address this risk mitigation tactic of policies and procedures again in a moment. Additionally, healthcare actors should coordinate follow-up care within the organization and inform the compliance officer of any issues that arise. Healthcare actors may also wish to implement tracking mechanisms to identify providers that have high rates of complaints, which could indicate more widespread compliance violations with that provider's billing practices or documentation behavior. Healthcare actors should further ensure that their providers are educated on medical record documentation requirements and should consider conducting random auditing and monitoring to check the integrity and accuracy of medical records and health data. Communication with the patient should additionally involve stated rationale for any changes that are being made to the medical record and timely follow-up on patient requests, particularly if non-compliance with that request could potentially implicate the Information Blocking Rule. All right, the third compliance challenge I wanna discuss is mergers and acquisitions. Given that the Information Blocking Rule has been in effect for over a year, we have now entered a world in which mergers and acquisitions are occurring under this new regulatory framework. If data integration and data transfer are not properly handled during a merger or acquisition, there's a chance that information blocking could arise. ONC has made clear in the Information Blocking Rule that when a healthcare actor acquires EHI from different sources, such as during a provider group acquisition, that actor may need additional time to perform pre-processing of that data and to ensure sufficient matching between data and patients before the data is safe and available for patient use. In some situations, special processing of health data may be required prior to data use, exchange, or access, and when special processing is required, it may inevitably delay integration and availability of patient health data, which could give rise to an information blocking complaint. However, when such additional processing is necessary and is performed in a reasonable and timely manner, ONC has suggested that it will not be deemed an information blocking practice. Thus, it's important during a merger or acquisition to really ensure that all data processing is being handled in a timely and effective manner, and to not leave it as an afterthought for something that you can deal with, you know, down the line, once this merger and acquisition has taken place and you're in the process of kind of moving assets. Another item that healthcare actors are gonna wanna consider during a merger or acquisition is whether or not to include risk-shifting contract language around data exchange and information blocking practices. So an important risk-shifting strategy is using contractual representations and warranties in order to shift that risk. For example, if an entity is acquiring health data as part of an acquisition, it is common for the acquired entity to make legal representations and warranties about its compliance with applicable law. While broad representations and warranties surrounding legal compliance are commonplace, and they're important, the novelty of the Information Blocking Rule arguably lends itself to inclusion of a more specific representation in the contract. For example, the acquiring healthcare actor may include a representation and warranty that the practice being acquired is in full compliance with the Information Blocking Rule and has not knowingly undertaken any information blocking practices since April 5th, 2021. There are other risk-shifting strategies for contracts in the mergers and acquisition space, and use of these contractual vehicles is going to largely depend on the transaction and the party's risk tolerance. In addition, before completing the merger or acquisition, the healthcare actor should review the other entity's EHR system, policies, procedures, and other materials that are related to data access, use, exchange, and disclosure. As I mentioned before, it should not be an afterthought. This review will help determine if the entity is currently in compliance with the Information Blocking Rule, and if not, high risk areas for liability could be exposed that may determine whether or not the parties want to proceed with the merger or acquisitions. All right, given that compliance with the Information Blocking Rule is an ongoing endeavor, especially with the EHI definition changing in the near future, it's important to consider some effective risk mitigation tactics. The first risk mitigation strategy that healthcare actors can take is reviewing and updating their policies and procedures. And you've heard me mention reviewing and updating policies and procedures in a couple of the compliance challenges that I mentioned a few minutes ago, and this is because revised policies and procedures can help guide a company's compliance response, particularly when dealing with a situation that may rise to the level of information blocking. It can also be daunting to review and revise policies and procedures again to cover the expanding definition of EHI, when a lot of healthcare actors just updated and revised their policies and procedures less than a year ago to establish their initial compliance framework for information blocking. So given that policies and procedures are living, breathing documents, it's important to keep them updated to ensure continued compliance with regulatory frameworks. I wanna give some tips for updating policies and procedures that may help with risk mitigation. First, it's important to note that policy and procedure revisions occur on two levels. We have substance and form. A substantive revision or review is going to incorporate the Information Blocking Rule's legal requirements, whereas a form review is going to ensure that the policy or procedure complies with best drafting practices, and to have an effective policy and procedure, you need both types of review. On a substantive level, you want to ensure that the policies and procedures are not imposing requirements on healthcare actors that are going to intentionally or inadvertently result in the impermissible withholding of EHI as that term will be defined in October, 2022. Additionally, the policies and procedures should comply with any formalities that are specified in the Information Blocking Rule, particularly if such policy will also serve as a basis upon which to invoke an information blocking exception. It may be helpful for healthcare actors to incorporate affirmative legal requirements from the Information Blocking Rule into their policies and procedures in order to signify their intent to comply with the Information Blocking Rule. Further, it's advisable that the policies reference the organization's goal of promoting and ensuring timely patient access, use, and exchange of EHI in accordance with the Information Blocking Rule. Definitions of EHI should also be updated in the policies and procedures if necessary to ensure compliance with this new phase of requirements. From a drafting perspective, healthcare actors should ensure that their policies and procedures are adhering to best drafting practices. And I wanna discuss four drafting tips to think about when you're revising policies and procedures. First, policies and procedures should adopt a simple and easy-to-read writing style. The language should be plain English and it should avoid legalese, jargon, and acronyms or other abbreviations that are not going to be easily understood by all of your policy readers and users. To that end, it's important to identify your audience for each policy upfront and write to that audience to ensure comprehension. Second, healthcare actors should draft policies and procedures in active voice. Not only is active voice easier to read and understand, but it also emphasizes the reader's actions and responsibilities, and this emphasis helps to alert the audience or the reader of their obligations, and it places the burden of compliance squarely on the audience's shoulders. Third, policies and procedures should be as short as possible, while covering all applicable requirements. Lengthy policies and procedures are usually not user-friendly, and the organization runs a heightened risk that its audience will not even read them. As a rule of thumb, policies and procedures should not exceed a maximum of 10 pages unless it's absolutely necessary, and in practice, I find that most policies and procedures can be written within one to five pages. To help shorten policies and procedures, organizations should ensure that the policy or procedure is not merely recycling or repeating the legal rule that it's designed to address. Instead, what these documents should do is add value to the reader, such as alerting the reader of the organization's position on the rule or correct procedures to follow when faced with a particular incident. In the context of information blocking, a policy may explicitly describe the actions and steps that an organization wants its audience to take when faced with a request to use, exchange, or disclose EHI. It may also describe the proper protocols to follow if a clinician suspects that EHI is being impermissibility withheld. The goal here is to incorporate substantive guidance and add value and instruction for the reader. Finally, consider adding examples of preferred and incorrect behaviors to the policies and procedures. Examples help to provide real life context or to otherwise simplify the type of behavior that you want to encourage and make it visible to the reader. The second risk mitigation strategy concerns effective training of healthcare actors and employees who are subject to the Information Blocking Rule. It's necessary to offer compliance training to any individual who is impacted by or regulated by the Information Blocking Rule, and this is particularly true given the fact that we have this new definition of EHI coming into effect. Healthcare actors need to be educated on the new compliance requirements and strategies that they're expected to adhere to. The training that's provided should not just aim to educate healthcare actors about information blocking requirements, but instead it should also explain how the Information Blocking Rule is changing and how it's being enforced. What trends, for instance, are dominating the information blocking field? Are certain categories of actors obtaining complaints faster than other categories? What are those complaints? What are they alleging? How can a company guard against these complaints that are being filed? These are the types of questions that compliance officers should be thinking through and be prepared to address in their training programs. And the training should also provide examples of compliant and non-compliant behaviors. For example, if a company is updating its compliance strategy to incorporate the new definition of EHI, explain what is or is not considered information blocking using that expanded definition. All right, so that has been the substance of our presentation for today. I do wanna quickly give you an overview of where the information blocking landscape stands today before we close. So we've had the Information Blocking Rule in effect for more than a year, what does that landscape look like right now? Well, unsurprisingly, information blocking complaints have been trickling in since the rule took effect. As of March, 2022, there were already 300 claims of information blocking. The majority of complaints, approximately 77% or 211 complaints, have been filed against healthcare providers. 46 of the complaints alleged information blocking specifically by health IT developers, and the minority of complaints are against health information networks or exchanges. Additionally, in January, 2022, the Biden administration announced its governance framework for health information exchange, known as the Trusted Exchange Framework and the Common Agreement, TEFCA. And the Biden administration created TEFCA so that it could devise the legal and technical requirements necessary to promote information sharing across entities. The application process will soon open for health information exchanges and networks to become qualified health information networks, and qualified health information networks are groupings of organizations that allow their participants to exchange health information in the U.S. Finally, in terms of penalties, right now, there are no penalties for healthcare providers if they violate the Information Blocking Rule. For health IT developers, exchanges, and networks, OIG published a proposed rule on April 24th, 2020 to create new civil monetary penalties for information blocking, and in that rule, OIG proposed a maximum fine of $1 million per information blocking violation. Again, that rule does not apply to healthcare providers and we're still waiting for the final rule to be decided. So thank you so much for attending today. I hope this was helpful in helping to clarify and solidify the information blocking and interoperability landscape. Thank you so much.