Last week, the ONC published two final rules. Here we focus on the 21st Century Cures Act Final Rule and its implications for EHR vendors. The big headline for this Final Rule should be “ONC Embraces the FHIR Standard”. 2015 Edition CEHRT and the whole certification process will undergo substantial changes. This blog will focus on the certification requirements and timeline. We’ll address some other aspects: The “information blocking” provisions, the voluntary pediatric certification, and the payer API provisions in future blogs.
Some highlights:
- US Code Data for Interoperability (USCDI) Version 1 replaces the “Common Clinical Data Set”
- Fast Health Interoperability Resources (FHIR) 4.01 now required for API, so 170.315(g)(8) will be replaced by 170.315(g)(10).
- “Electronic Health Information (EHI) export” in 170.315(b)(10) replaces 170.315(b)(6).
- Multi-factor authentication is now required (with some exceptions).
There’s actually some good news for EHR vendors looking to certify or re-certify in that some criteria from 2015 Edition CEHRT have been removed effective 60 days after publication (at effective date):
Although these will be removed, the expectation is that vendors will retain the functionality. Many of them are “topped out” in the sense that everyone already has the functionality, so no need for government intervention. More good news: There are only two new criteria that EHR vendors who have already certified for 2015 Edition must certify – 170.315(b)(10) and 170.315(g)(10) (see next blog, “21st Century Cures Act: EHI Export”).
Several criteria have been updated to accommodate new versions of standards:
- The CCDA-related criteria, 170.315(b)(1), (b)(2), (b)(9), (e)(1), (f)(5) and (g)(6) have been updated per the USCDI/C-CDA companion guide, as has the 170.315(g)(9) “Application Access – All Data” criterion.
- Security-related criteria have been revised to meet new ASTM standards.
- Vendors have 24 months from the issuance of the Final Rule to update their software and distribute to clients.
USCDI Replaces Common Clinical Dataset (CCDS)
Think of USCDI as a superset of the CCDS. According to ONC, it “sets a foundation for broader sharing of electronic health information to support patient care”. USCDI adds three types of data for CCDS:
- Clinical notes: both structured and unstructured.
- Provenance: an audit trail of the data, showing where it came from. It is metadata or information about the data, that shows who created it and when.
- Pediatric Vital Signs
USCDI Version 1 differs from the Proposed Rule USCDI, as follows:
The Final Rule also provides a foresighted provision to allow new versions of standards like FHIR and USCDI to be adopted and incorporated into the CEHRT requirements.
FHIR API
There’s a new API certification criterion that’s been added to the 2015 Edition Base EHR definition:
170.315(g)(10) Standardized API for patient and population services
EHR developers have 24 months from the publication date to “update their technology and make such available to their customers” according to CMS. Later they clarify that the updated certified health IT software must be provided to all customers within this 24-month window. Now we have fair warning! Also, note that there’s a six-month window for any “Certified API Developer” to “publish all terms and conditions for its certified API technology, including any fees, restrictions, limitations, obligations, registration process requirements or other similar requirements.” So for those with non-FHIR APIs certified to 170.315(g)(7) through (9), these publication requirements precede FHIR requirements.
In addition to mandating FHIR r4, this new criterion has some other interesting requirements concerning API capabilities:
- Register apps with an authorization server prior to enabling interaction,
- Use TLS 1.2 or higher and require authentication before patient data is accessed,
- Comply with SMART App Launch Implementation Guide and the OpenID Connect standard,
- Issue and refresh access tokens on a scheduled basis, and
- Revoke an authorized app’s access to patient data when directed by a patient.
Another difference between the old 170.315(g)(8) and the new 170.315(g)(10) is that 170.315(g)(10) requires retrieval of data for a group of patients.
The standard embraced for this is the “HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (Bulk IG), including mandatory support for the “group-export” “Operation Definition” in § 170.215(a)(4).”
“The scope of patient cohorts for “population services” can include various groups defined at the discretion of the user of the API-enabled “read” services for multiple patients, including, for example, a group of patients that meet certain disease criteria or fall under a certain insurance plan.” -ONC
Note that the new FHIR requirement is “read-only” – there is no requirement for an API user to update data in the EHR.
Enhanced Security Criteria
Two new security-related criteria have been introduced, effective 60 days after publication, for new and updated certifications only:
- Encrypt authentication credentials 170.315(d)(12)
- Multi-factor authentication (MFA) 170.315(d)(13)
Neither is required – vendors just need to attest to whether or not they support the capabilities. Encryption is based on the FIPS 140-2 industry standard – health IT developers are permitted to choose any of the approved encryption methods in FIPS 140-2. The 170.315(d)(13) MFA requirement follows usual industry standards, as well. ONC says: “MFA includes using two or more of the following: (i) something people know, such as a password or a personal identification number (PIN); (ii) something people have, such as a phone, badge, card, RSA token or access key; and (iii) something people are, such as fingerprints, retina scan, heartbeat, and other biometric information.“
At DHIT, we welcome your feedback on requirements and are eager to assist with certification. Our expert consulting and bolt-on modules have paved the way for many successful EHR vendor certifications. Please contact Michelle Bond for additional information, mbond@dynamichealthit.com.
