§170.315(a)(13) Patient-specific education resources
§ 170.315 (a)(13) Patient-specific education resources—
- Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:
- The standard and implementation specifications specified in §170.204(b)(3).
- The standard and implementation specifications specified in §170.204(b)(4).
- Optional. Request that patient-specific education resources be identified in accordance with the standard in §170.207(g)(2).
Paragraph (a)(13)(i)
§ 170.204(b)(3) Health Level 7 (HL7®) Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1
OR
§ 170.204(b)(4) HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4
Paragraph (a)(13)(ii)
§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure |
01-08-2016
|
| 1.1 |
As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only. |
09-21-2017
|
| 1.2 |
Changed langauge from self-declaration to attestation |
08-25-2021
|
- Regulation Text
-
Regulation Text
§ 170.315 (a)(13) Patient-specific education resources—
- Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:
- The standard and implementation specifications specified in §170.204(b)(3).
- The standard and implementation specifications specified in §170.204(b)(4).
- Optional. Request that patient-specific education resources be identified in accordance with the standard in §170.207(g)(2).
- Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:
- Standard(s) Referenced
-
Paragraph (a)(13)(i)
§ 170.204(b)(3) Health Level 7 (HL7®) Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1OR
§ 170.204(b)(4) HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4Paragraph (a)(13)(ii)
§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009
- Revision History
-
Version # Description of Change Version Date 1.0 Final Test Procedure
01-08-20161.1 As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only.
09-21-20171.2 Changed langauge from self-declaration to attestation
08-25-2021
Testing components
Attestation: As of September 21, 2017, the testing approach for this criterion is satisfied by attestation.
The archived version of the Test Procedure is attached below for reference.
|
System Under Test |
ONC-ACB Verification |
|---|---|
|
The health IT developer will attest directly to the ONC-ACB to conformance with the §170.315(a)(13) Patient-specific education resources requirements. |
The ONC-ACB verifies the health IT developer attests conformance to the §170.315(a)(13) Patient-specific education resources requirements. |
§ 170.315 (a)(13) Patient-specific education resources—
- Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:
- The standard and implementation specifications specified in §170.204(b)(3).
- The standard and implementation specifications specified in §170.204(b)(4).
- Optional. Request that patient-specific education resources be identified in accordance with the standard in §170.207(g)(2).
Paragraph (a)(13)(i)
§ 170.204(b)(3) Health Level 7 (HL7®) Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1
OR
§ 170.204(b)(4) HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4
Paragraph (a)(13)(ii)
§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure |
01-08-2016
|
| 1.1 |
As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only. |
09-21-2017
|
| 1.2 |
Changed langauge from self-declaration to attestation |
08-25-2021
|
- Regulation Text
-
Regulation Text
§ 170.315 (a)(13) Patient-specific education resources—
- Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:
- The standard and implementation specifications specified in §170.204(b)(3).
- The standard and implementation specifications specified in §170.204(b)(4).
- Optional. Request that patient-specific education resources be identified in accordance with the standard in §170.207(g)(2).
- Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:
- Standard(s) Referenced
-
Paragraph (a)(13)(i)
§ 170.204(b)(3) Health Level 7 (HL7®) Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1OR
§ 170.204(b)(4) HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2
HL7® Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4Paragraph (a)(13)(ii)
§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009
- Revision History
-
Version # Description of Change Version Date 1.0 Initial Publication
10-22-20151.1 Revised to reflect this criterion is in scope for the CEHRT definition.
12-07-20151.2 Revised to include clarification for Infobutton in the optional provision for certification.
03-24-20161.3 Revised as a result of further analysis of the applicability of the 2015 Edition “amendments” certification criterion (§ 170.315(d)(4)) to health IT capabilities that would not necessarily have any patient data for which a request for an amendment would be relevant.
04-24-20171.4 Removal of Amendments (§ 170.315(d)(4)) under Approach 1 in the Privacy and Security section of the table.
05-08-20171.5 Revised to include clarification that the criterion is focused on supporting a health care professional or his or her office staff; or a software program or service that would interact directly with the certified health IT (See “applies to entire criterion” section).
05-26-20171.6 Further clarified the capabilities that must be demonstrated for health IT to be certified to this criterion (See “applies to entire criterion” section).
08-29-20171.7 Added clarification for time-limited certification to this criterion per the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule.
06-15-20201.8 Corrected information in the Privacy & Security section.
08-03-2020
Certification Companion Guide: Patient-specific education resources
This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product development. The CCG is not a substitute for the 2015 Edition final regulation. It extracts key portions of the rule’s preamble and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the 2015 Edition final rule or other included regulatory reference. The CCG is for public use and should not be sold or redistributed.
| Base EHR Definition | In Scope for CEHRT Definition |
|---|---|
| Not Included | Yes |
Privacy and Security: This certification criterion was adopted at § 170.315(a)(13). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.
- The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
- As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transfer to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- Health IT presented for certification to this criterion would not have to demonstrate the capabilities required by the 2015 Edition “Amendments” certification criterion (§ 170.315(d)(4)), unless the health IT is presented for certification to another criterion that requires certification to the 2015 Edition “Amendments” criterion under the privacy and security certification framework.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for approach 1, the health IT developer may certify for the criterion using system documentation which provides a clear description of how the external services necessary to meet the privacy and security criteria would be deployed and used. Please see the ONC Cures Act Final Rule at 85 FR 25710 for additional clarification.
Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.
- When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy and Security: This certification criterion was adopted at § 170.315(a)(13). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.
- The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
- As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transfer to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- Health IT presented for certification to this criterion would not have to demonstrate the capabilities required by the 2015 Edition “Amendments” certification criterion (§ 170.315(d)(4)), unless the health IT is presented for certification to another criterion that requires certification to the 2015 Edition “Amendments” criterion under the privacy and security certification framework.
Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.
- When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for approach 1, the health IT developer may certify for the criterion using system documentation which provides a clear description of how the external services necessary to meet the privacy and security criteria would be deployed and used. Please see the ONC Cures Act Final Rule at 85 FR 25710 for additional clarification.
Applies to entire criterion
Clarifications:
- Compared to the 2014 Edition, a health IT developer no longer must include another means for identifying diagnostic or therapeutic reference information for capabilities other than the Infobutton standard. [see also 80 FR 62625]
- Three specific conditions need to be satisfied for this criterion:
- The health IT must be able to “electronically identify” education resources;
- The education resources must be “patient specific”;
- The education resources must be based on data included in the patient’s problem list and medication list. [see also Health IT Certification Program Overview]
- A Health IT Module must be able to electronically identify for a user patient-specific education resources based on data included in the patient’s problem list and medication list. [see also 80 FR 16823 and 62624; see also 80 FR 16813-16814 for the capabilities included in a certification criterion compared to the 2014 Edition; see also 77 FR 54216-54217] User is defined as a health care professional or his or her office staff; or a software program or service that would interact directly with the certified health IT. [see also 80 FR 62611 and 77 FR 54168] A “user” is not a patient for the purposes of this criterion. [see also 77 FR 54168] Further, as discussed in the 2014 Edition final rule, the 2014 Edition § 170.314(a)(15) Patient-specific education resources criterion was designed to support the correlated objective and measure under the EHR Incentive Programs, which requires clinicians to use clinically relevant information from CEHRT to identify patient-specific education resources and provide them to the patient. [see also 77 FR 54216 and 54217]. The 2015 Edition § 170.315(a)(13) Patient-specific education resources criterion was similarly designed and serves the same purpose. [80 FR 16814, 62615, 62876, 62878, 62880, 62883, 62885, and 62887] This means that health IT may be certified to this criterion if it can demonstrate that it can support a user identifying, either manually or through automation, clinically relevant patient-specific education resources based on a patient’s problem list and medication list.
- ONC-ACBs will be permitted to issue certificates for this criterion up until January 1, 2022, to align with the requirements of the CMS Medicaid Promoting Interoperability Program. [see also 84 FR 42592] ONC has included a provision in § 170.550(m)(1) to only allow ONC-ACBs to issue certificates for this criterion until January 1, 2022. While ONC continues to recognize the importance of patient and provider interaction to promote positive health outcomes, ONC also believes that this criterion is narrowly focused on a specific functionality not connected to interoperability and removing this criterion will help to reduce regulatory burdens and costs for health IT developers and healthcare providers. [see also 80 FR 25661]
|
Clarifications:
|
Paragraph (a)(13)(i)
Technical outcome – A user can identify educational resources about a patient’s problem or medication in accordance with the HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2 standard and either Implementation Guide (IG) specified in:
- HL7® Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1; or
- HL7® Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.
Clarifications:
- Developers can choose to either implement the Service-Oriented Architecture IG or the Context-Aware Knowledge Retrieval IG to meet certification requirements.
|
Technical outcome – A user can identify educational resources about a patient’s problem or medication in accordance with the HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2 standard and either Implementation Guide (IG) specified in:
Clarifications:
|
Paragraph (a)(13)(ii) Optional
Technical outcome – A user can request that patient-specific education resources be identified based on the patient’s preferred language identified with the codes in the RFC 5646 standard.
Clarifications:
- This provision is optional for certification.
- Infobutton only supports a value set of ISO 639-1 for preferred language and, therefore, testing and certification of preferred language for this certification criterion would not go beyond the value set of ISO 639-1. [see also 80 FR 62624]
|
Technical outcome – A user can request that patient-specific education resources be identified based on the patient’s preferred language identified with the codes in the RFC 5646 standard. Clarifications:
|