Kelly McLendon (kmclendon@complianceprosolutions.com) is Sr. VP Compliance and Regulatory Affairs, CompliancePro Solutions, Exton, PA.
United States healthcare professionals and patients stand upon the cusp of unprecedented, burdensome regulatory changes that will affect automation and how we manage access to patient information while maintaining privacy and security. The 21st Century Cures Act (Cures Act) information-blocking and interoperability regulations are complex, unprecedented, and intertwined with the HIPAA rules.[1] However, diligence in studying the new rules, the government’s online guidance, and educational materials such as this article will provide clarity for healthcare providers on how to implement and what automation technology may be used to relieve some of the burdens.
Regulations spur change
The Cures Act from Office of the National Coordinator for Health Information Technology (ONC);[2] Centers for Medicare & Medicaid Services (CMS) final rule;[3] the expected HIPAA final rule;[4] the Coronavirus Aid, Relief, and Economic Security Act;[5] and 42 C.F.R. Part 2 (substance abuse) rules will significantly affect how we manage electronic patient health information. We have a fair amount of guidance and new tools developed, like the Trusted Exchange Framework and Common Agreement,[6] a sample health information exchange trust agreement issued by governmental regulators. However, we have almost no professional practice to learn from, and vendor stakeholders are only now getting their updates and certifications implemented. Therefore, best practice development will follow and will probably take a few years to mature.
Rarely have standards and protocols been published by the government mandating the use of specific healthcare automation approaches to promote access to and exchange of patient information. The 21st Century Cures Act refers to persons and companies subject to those rules as “actors,” reflecting a wider scope of parties that can or must access and exchange patient health information. Such access and exchange will become much more commonplace among not only HIPAA entities (e.g., providers and payers), but also non-HIPAA entities such as personal health, mobile health (e.g., smartphone based), and related digital apps, along with innumerable other third parties and their applications that have a stake in healthcare processes involving patients, providers, and payers.
Be aware that these rules cover more than just access by patients to their information. They will address all use cases where actors that exchange patient information will be able to use the rules to manage their requests for most uses for patient information, even if the patient is not directly involved in the transaction. Not allowing appropriate electronic health information (EHI) access, use, or exchange could invoke the new information-blocking rules from the ONC. Today, these rules only have appropriate disincentives for enforcement, but will soon invoke with direct penalties.
Patient’s PHI is also EHI
In addition to HIPAA’s definition of protected health information (PHI),[7] under the Cures Act, EHI[8] is defined as electronic protected health information contained within a patient’s designated record set that may reside within or outside a HIPAA entity. It can be confusing when two different agencies use two different terms for the same basic concept, one of which is derived from the other, but with incomplete synchronization. The Cures Act uses the term “electronic protected health information” only in reference to the definition of EHI, making it unclear what constitutes a designated record set outside of the HIPAA entity.
While industry groups have been working to define the relationships of the HIPAA designated record sets[9] as used by the Cures Act as part of the EHI definition, what makes up a designated record set outside of a HIPAA entity is unclear. Hopefully, more guidance will be forthcoming from the ONC, but also with the expected HIPAA final rule.
Incomplete clarification of what constitutes a designated record set under either the Cures Act or HIPAA rules hampers automation of the components needed to allow large portions of the current processes to be treated with automation. The primary target (all of which are actors) of many of the Cures Act rules are electronic health record (EHR) vendors, which must be certified to perform certain automations, including HL7® Fast Healthcare Interoperability Resources (FHIR®) application programming interfaces (APIs)[10] and EHI exports.[11] CMS also invokes these rules for payers, which do not have certified systems and must create such automations within their own systems.
Healthcare providers’ EHR vendors are charged with providing Cures Act–compliant APIs and exports of EHI— requirements that, if failed, could render a vendor’s EHR not certified, which few providers can afford from revenue, compliance, or risk perspectives. Therefore, the providers should already be well down the path toward implementing whatever software tools addressing the Cures Act compliance their EHR vendors are able to provide. There may be some costs to healthcare providers involved in using these new Cures Act components within an EHR, but they are included in the Cures Act rules about what costs and licensing may be charged. In general, certified EHR vendors are not allowed to put up unreasonable barriers in the way of their customers using the Cures Act tools they provide as a part of their certified EHR products.
Conversely, payers do not leverage federally certified systems to manage their patient records. Instead, they are using their own systems, mostly custom built and different from the other payers. Under the CMS interoperability and patient access rule of the Cures Act, the payers also will have to provide for the FHIR API and EHI export functionalities from within their systems.[12] There are many parties besides patients that may wish to easily access, with proper authentication, the patient’s claims and revenue cycle documentation. Therefore, these new functionalities are being created and will be implemented by each payer.