§170.315(a)(11) Smoking status
§ 170.315 (a)(11) Smoking status—
Enable a user to record, change, and access the smoking status of a patient.
None
| 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
|
- Regulation Text
-
Regulation Text
§ 170.315 (a)(11) Smoking status—
Enable a user to record, change, and access the smoking status of a patient.
- Standard(s) Referenced
-
None
- 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-2017
Testing components
Gap Eligible
Self-Declaration: As of September 21, 2017, the testing approach for this criterion is satisfied by self-declaration.
The archived version of the Test Procedure is attached below for reference.
|
System Under Test |
Test Lab Verification |
|---|---|
|
The health IT developer submits their self-declaration to the ONC-ATL. |
The Tester verifies the self-declaration document contains all of the required data elements. |
§ 170.315 (a)(11) Smoking status—
Enable a user to record, change, and access the smoking status of a patient.
None
| 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
|
- Regulation Text
-
Regulation Text
§ 170.315 (a)(11) Smoking status—
Enable a user to record, change, and access the smoking status of a patient.
- Standard(s) Referenced
-
None
- Revision History
-
Version # Description of Change Version Date 1.0 Initial Publication
10-22-20151.1 Added clarification regarding the requirements of the Common Clinical Data Set (CCDS) should the developer intend to certify to other 2015 Edition certification criteria that require the CCDS.
12-18-2015
Certification Companion Guide: Smoking status
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 |
|---|---|
| Included | Yes |
Privacy and Security: This certification criterion was adopted at § 170.315(a)(11). As a result, an ONC-ACB must ensure that a product presented for certification to a § 170.315(a) “paragraph (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) “VDT” and (e)(2) “secure messaging,” which are explicitly stated.
- 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))
- Amendments (§ 170.315(d)(4))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- If choosing Approach 2:
- For each applicable P&S 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 P&S criteria would be deployed and used. Please see the 2015 Edition final rule correction notice at 80 FR 76870 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)(11). As a result, an ONC-ACB must ensure that a product presented for certification to a § 170.315(a) “paragraph (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) “VDT” and (e)(2) “secure messaging,” which are explicitly stated.
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))
- Amendments (§ 170.315(d)(4))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- If choosing Approach 2:
- For each applicable P&S 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 P&S criteria would be deployed and used. Please see the 2015 Edition final rule correction notice at 80 FR 76870 for additional clarification.
Applies to entire criterion
Technical outcome – The health IT permits a user to record, change, and access a patient’s smoking status.
Clarifications:
- There is no standard required for this criterion.
- The 2014 Edition smoking status criterion (§ 170.314(a)(11)) required a standard, whereas the 2015 Edition smoking status criterion (§ 170.315(a)(11)) does not. For the purposes of gap certification, this criterion is considered unchanged.
- In comparison to the 2014 Edition smoking status criterion (§ 170.314(a)(11)), a terminology standard is no longer required for recording and changing the smoking status of a patient. The criterion is now functional only.
- This criterion’s scope is limited to any form of tobacco that is smoked. That would not prohibit a health IT system from capturing other forms of tobacco use that is not smoked (e.g., chewing tobacco), but it is not required for certification. [see also 77 FR 54205]
- Although no specified standard or codes are required for this certification criterion, the Common Clinical Data Set (CCDS) does require exchange of smoking status using specified SNOMED CT® codes. We note this so developers are aware that if they intend to certify to other 2015 Edition certification criteria that require the CCDS that the system’s internal representation of smoking status may need to be mapped to the codes specified for the CCDS. Please refer to the CCDS Guide for more information.
|
Technical outcome – The health IT permits a user to record, change, and access a patient’s smoking status. Clarifications:
|