This blog focuses on the 170.315(b)(10) “Electronic Health Information (EHI) Export” criterion and action items for EHR developers that kick in 6 months after publication (note that while the Final Rule has been released, it hasn’t officially been published – that date occurs when it appears in the Federal Register). A future blog will cover Information Blocking requirements for developers.
To refresh your memory, 170.315(b)(6) “Data Export” mandates that Certified EHR Technology (CEHRT) must be able to export a batch of CCDs containing data elements from the Common Clinical Dataset (CCDS) without developer assistance. A well-defined and practical requirement, not just for those migrating from one EHR to another but for a host of other uses.
Although 170.315(b)(10) EHI export replaces (b)(6), it is quite different and some elements warrant investigation:
- On page 207, the regulation text states “the patient population EHI export capability of this criterion could require action or support on the part of the health IT developer. We acknowledged in the Proposed Rule (84 FR 7448) that because of anticipated large volume of electronic health information that could be exported under this specific proposed capability, developer action or support could be needed.” But the draft test method: https://www.healthit.gov/sites/default/files/page/2019-03/170_315b_10_Electronic_health_information_export.pdf directly contradicts the reg, stating that a user must be able to execute this capability at any time without developer assistance.
- Another curious aspect is the replacement of a standards-based export (CCDA) by one that is not standards-based. All that is required in the way of standards is “the export files must be electronic and in a computable format and the publicly accessible hyperlink of the export’s format must be included with the exported file(s).” This is reminiscent of the initial 2105 Edition API requirement (g)(7-9), which is now being refined by the FHIR requirement in (g)(10). Of course CCDAs are still required for other CEHRT criteria, just not for bulk export.
- The proposed rule called for EHR vendors to provide the capability to export ALL Electronic Health Information (EHI) without defining EHI. This was clearly unworkable in the real world. The final rule is a bit more realistic but I am still skeptical. In the regulatory text, ONC refers to CFR 160.103 for the scope of data to be exported. CFR 160.103 defines “electronic protected health information” as information that “Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual.”
Later, the Final Rule offers a couple caveats to limit the scope a bit:
- Excluded would be: “Psychotherapy notes as defined in 45 CFR 164.501 or information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding…”
- Also, limited to “EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. This includes all EHI stored by the product’s certified and “non-certified” capabilities.”
- Of note, images are also included: “any images, imaging information, and image elements that fall within this finalized scope of EHI that can be stored at the time of certification in or by the product, of which the Health IT Module is a part will need to be exported under this certification criterion”. Although Radiology/PACs developers haven’t typically been certifying for 2015 CEHRT, this could impact EHR vendors that store these X-Rays and MRIs.
- I was ready to criticize the ONC for (b)(10) but in my opinion the bulk data requirements in (g)(10) will end up being vastly more useful in the real world, so this should make up for the lack of a required standard for (b)(10) – for more information, see last week’s blog.
- ONC has removed 170.315(b)(6) from the Base EHR definition, effective 60 days from publication of the Final Rule and I assume it will no longer be required for vendors certifying as the primary EHR for their clients. Meanwhile, there is a 36 month phase-in for (b)(10). This could be a boon to any EHRs that have not yet certified for 2015 Edition. It also opens the door to a scenario where providers are left without a means to extract CCDA data from the Common Clinical dataset in the event that they need to migrate to a new EHR within the 36-month period.
170.315(b)(10) is not part of the Base EHR definition but it is “a general certification requirement for the ONC Health IT Certification Program” . This criterion appears to be a self-declaration criterion (no proctor testing).
Stay tuned for our next blog that explains specifically:
- API Provisions of Certification
- Maintenance of Certification
As your Strategic Partner, we have many upcoming blogs that will break down Information Blocking and much more about the 2015 Edition Cures Act Final Rule.
