Lessons learned in 2022.
In the lead-up to the (g)(10) deadline we found that many EHRs had delayed their compliance preparation due to competing priorities and strained internal resources.
Due in part to limited resources and a lack of understanding of the full scope and complexity of (g)(10) many teams dashed to the finish line. Through this process, the Drummond team identified a few common challenges:
- Longer development timelines due to a lack of understanding of the effort surrounding identification and mapping of data elements for (g)(10). Experience with these data management issues should aid in preparation for the (b)(10) designated record set (DRS) requirements–especially with the larger scope of data elements covered by (b)(10) extending beyond USCDI.
- Many (g)(10) developers relied on 3rd party developers to help them meet compliance deadlines last year. For organizations making (b)(10) a priority, we recommend an early start on your resource and development planning so you have greater control over what is and is not outsourced and can make informed choices before deadline pressure ramps up.
- Testing time frames were compressed for many companies who started their (g)(10) preparation late—resulting in potential increased reputational risk associated with rapid development, to address any functionality gaps within a quickly shrinking pre-deadline window.
Unlike (g)(10), nearly all certified developers will be required to comply with (b)(10). If your solution stores EHI, start planning now.
Collaboration is essential.
When you analyze compliance rules early, you get a better understanding of what is required, can prioritize accordingly, and have more control of the resulting product changes and outcomes.
Last year, (g)(10) required independent testing, and ONC provided a testing tool. But for (b)(10) there’s no such requirement or support, and this lack of independent testing can have pitfalls across a quite large DRS data scope. Without this requirement, some companies will be exposed to greater risk if they do not prioritize or include time for robust QA testing (mapped to compliance requirements), plus the risk of not meeting customer expectations for this important export capability.
While (g)(10) compliance could leverage Implementation Guides with incorporated standards, (b)(10) isn’t as prescriptive in how to meet the requirements; its breadth presents challenges as it requires all data in the medical record to be exportable.
- To get started, you should assess your current solution’s functionality to be sure it fully addresses (b)(10) EHI requirements. High-level, important considerations include:
Scope identification for required data (EHI) under the control of your EHR - User interface and workflow changes to existing export processes
- Single-patient and patient population export capabilities
- Technology standards choices and best practices affecting customer satisfaction and other strategic considerations
- Third-party solution options (build vs. buy) such as database aggregators that can extract the data from the EHR and then publish it to the EHI file
- Future regulatory guidance that could require standards for some of this data, such as FHIR—as it becomes more widely adopted.
The (b)(10) requirements may result in the need for significant process and workflow changes—requiring organization-wide change management. To learn more about § 170.315(b)(10) Electronic Health Information export requirements visit https://www.healthit.gov/test-method/electronic-health-information-export#ccg
Compliance Is a Moving Target.
2023 Ready, set, aim.
EHRs will need to collaborate with their customers to ensure their solution works with their customers’ unique environments and approach to EHI provisioning. And, given the requirements outlined below, collaboration with your customers has never been more important.
- Anyone who stores PHI and is certified must address all their PHI whether it is tied to certified functionality or not. Simply put, any PHI an EHR has ownership over (with limited exceptions) must be addressed regardless of the source.
- EHR developers are now responsible for defining their designated record set.
- EHRs often have the largest technology footprint within a provider organization, supported by many 3rd party apps, and therefore help to drive organizational best practices around compliance. As a result, EHRs are often the source of truth, and their customers expect them to provide insights on how compliance-driven software changes like (b)(10) will impact their processes.
- Should 3rd party software developers be needed to address (b)(10) compliance, EHRs will need sufficient time to vet the 3rd party solutions, ensure they address the complete data scope across all customer use cases, map all required data elements, and integrate them into existing or new workflows.
And of course, many organizations will need to collaborate with subject matter experts, like the Drummond Advisory team, who can guide your developers through the evaluation, identification and classification of all potential EHI categories and elements. This expertise will help you determine what is and is not considered EHI as it relates to your and your customers’ unique environments.
Top 4 things to get your process started.
Compliance is an ongoing business requirement. Now is always a good time to reassess and refine your compliance processes.
After helping many product development teams in 2022 through the completion of their (g)(10) compliance and certification efforts, we recommend the following to help you get started with your (b)(10) planning process:
- Determine what products need to be certified and review those products against the requirements.
- Be sure your organization’s interpretation of terms like Information Blocking, PHI, ePHI, DRS, EHI, USCDI/ONDEC, SDOH, and LHR are the same as ONC’s. This article provides useful information about what health information ONC’s information blocking regulations cover https://www.healthit.gov/buzz-blog/information-blocking/say-hi-to-ehi
- Identify inclusions and exclusions to your DRS, fully document them, and be ready to publicly communicate them to your customers and users.
- Identify what standards your solution will follow.
Don’t assume (b)(10) will be an easy effort. Now is the time to get started. Engage additional support soon where needed, so you’re not stuck pulling all-nighters this December, at increased reputational risk, or subject to enforcement action.
DISCLAIMER
The services offered by Drummond Advisory Services are separate and distinct from the Drummond Group Test Lab and Certification Body. The purpose of Drummond Advisory Services is to provide expert support and guidance for the planning, analysis, and execution of certification activities; it does not negate the steps or required actions of the certification process. Use of Drummond Advisory Services does not guarantee successful ONC Health IT testing or certification.