|
|
|
|
Due to the economic environment the AHIMA Advocacy Summit was cancelled for in-person and was made virtual. We look forward to providing you a series of updates from the Advocacy Summit.
We start with the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule. This was presented by Elise Sweeney Anthony, Executive Director of Policy and Elisabeth Myers, Deputy Director, Office of Policy from Office of the National Coordinator, and focused on 45 C.F.R. Parts 170 and 171.
The decision was made to update the 2015 Edition Certification Criteria, allowing the healthcare industry more fluidity in order to not require an update to a new product or undergo a major product revision which supports interoperability vs. full overhaul of systems.
The presentation focused on three main areas:
- Updates to the 2015 Edition Certification Criteria;
- Conditions and Maintenance of Certification Requirements;
- Information Blocking Provisions.
Three criteria as part of the Final Rule:
- Time-Limited and Removed Criteria – specifically designed to allow for participants in the Medicaid EHR incentive program to not have changes to systems while program still in place.
- Revised Criteria – new set standard for total data class to move from setting to setting with the patient to support healthcare.
- New Criteria – builds on prior, existing criteria. The Certification Expansion warranted new criteria.
|
|
2015 Edition Certification Updates
|
|
Revised: United States Core Data for Interoperability Standard (USCDI) - Replaces Common Clinical Data Set (CCDS). Includes new required data classes and elements. This information needs to move with patient from setting to setting.
- Provenance – understand where data is coming from and what history of that data is
- Clinical notes – includes 8 different sets of clinical notes that have been identified as a starting point to making sure this type of data can move from setting to setting
- Pediatric Vital Signs – specifically oriented to ensure patient safety for pediatric patients and things like growth charts can be calculated from setting to setting including settings that might not be pediatric specific
- Demographic Data – address, email, phone number – essential elements of data for patient matching. Help to support patient safety and patient matching across the setting.
Revised: Security Tags – Allows for a more granular approach to security tagging data. These were updated to be voluntary criteria to support security tagging at document, section and entry levels.
New: Electronic Health Information (EHI) Export Criterion – Adopted focused definition of EHI to ePHI to extent EHI would be included in designated record set. This is not open ended where developers would be accountable to things outside their control for future implementation of the product but specifically related to the time of certification what can be stored by that product.
General requirements include:
- Certified Health IT Module must include export capabilities for:
- single patient EHI export to support patient access;
- patient population EHI export to support transitions between health IT systems.
- Export file(s) created must:
- be electronic and in a computable format;
- publicly accessible hyperlink of the export’s format must be included with exported files. The hyperlink that is accessed by someone who might be building to that specification and can access and consume the data on the receiving end.
New: Application Programming Interface (API) Criterion – API was established as a new certification criterion requiring health IT developers to support a standardized API for single patient and population services. This certification is limited to API-enabled “road” services using HL7 Fast Healthcare Interoperability Resources (FHIR) Release 4. FHIR relates to the Privacy and Security of the data and will allow for greater innovation of third-party applications.
New: Privacy & Security Transparency Attestations – Two new Privacy and Security certification criteria that requires transparence attestations part of the updated 2015 Edition certification framework. In both cases the criteria are a yes/no attestation health IT developers answer certifying a product would (1) determine whether they encrypt authentication credentials or not and (2) whether they do multi-factor authentication or not.
|
|
Conditions and Maintenance of Certification Requirements
|
|
As part of the 21st Century Cures Act there is a requirement for HHS to establish Conditions and Maintenance of Certification requirements for the ONC Health IT Certification Program. This is specific to Health IT developers participating in the certification program and they relate specifically to the product for health IT modules that are certified under the program. These are a set of conditions needing to be maintained in order to participate in the certification. There are seven (7) certification conditions requirements which are:
- Information Blocking
- Assurances
- Communications
- Application Programming Interfaces (APIs)
- Real World Testing
- Attestations
- EHR Reporting Criteria Submission (at future time)
|
|
Information Blocking Provisions
|
|
Information blocking was defined during the presentation as “A practice by a health care provider, health IT developer, health information exchange, or health information network that, except as required by law or specified by the Secretary as a reasonable and necessary activity, is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.” These persons are categorized as “Actors”. Some examples of Information Blocking include practice is likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI; an actor is regulated by the information blocking provision; involves EHI.
Electronic Health Information (EHI) is defined as “Focused scope of EHI to mean electronic protected health information (ePHI) to the extent that the ePHI is included in a designated record set as these terms are defined for HIPAA.” This applies to an actor that may or may not be a covered entity.
Eight (8) exceptions to Information Blocking that are divided into two (2) buckets.
1. Exceptions that involve not fulfilling
requests to access, exchange, or use
EHI
a. Preventing Harm
b. Privacy
c. Security
d. Infeasibility
e. Health IT Performance
2. Exceptions that involve procedures for
fulfilling requests to access, exchange,
or use of EHI
a. Content and Manner
b. Fees
c. Licensing
With the Privacy Exception and in order to meet this exception an actor must have a privacy protected practice that meet at least 1 of the 4 sub-exceptions:
- Pre-condition not satisfied – This can relate to state/federal laws that requires, for example, a patient signed authorization and before covered actor sends information makes sure have signed auth. If auth was received, this exception might not apply.
- Health IT developers not covered by HIPAA are treated in a similar manner to developers who are covered by HIPAA.
- Denial of individual request for EHI consistent with 45 C.F.R. 164-524.
- Individual request to not share information – an actor may choose not to share or exchange information based on the request of the individual provided certain conditions are met, which is defined in the sub-exception of the Final Rule.
|
|
|
The above information was presented as a high-level overview, and review of the Cures Act Certification Final Rule is highly encouraged. Additional resources can be found on www.healthit.gov/curesrule. On this site you have the ability to view the Final Rule, fact sheets, previously recorded webinars and upcoming webinar schedule.
|
|
|
|
|
|
|
|
|
|
