§170.315(a)(12) Family health history
§ 170.315 (a)(12) Family health history—
Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in § 170.207(a)(1).
Applies to entire criterion
§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026.)
§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release (This standard is required by December 31, 2025.)
The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.
Deadline: December 31, 2025
Action to be taken: Developers certified to this criterion must update their use of SNOMED CT® standards outlined in the criterion.
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.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
This certification criterion was adopted at § 170.315(a)(12). 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 transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.
For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.
- 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))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 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 using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
03-11-2024
|
- Regulation Text
-
Regulation Text
§ 170.315 (a)(12) Family health history—
Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in § 170.207(a)(1).
- Standard(s) Referenced
-
Applies to entire criterion
§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026.)
§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release (This standard is required by December 31, 2025.)
- Required Update Deadlines
-
The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.
Deadline: December 31, 2025
Action to be taken: Developers certified to this criterion must update their use of SNOMED CT® standards outlined in the criterion.
- Certification Dependencies
-
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.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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 & Security Requirements
-
This certification criterion was adopted at § 170.315(a)(12). 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 transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.
For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.
- 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))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 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 using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
03-11-2024
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)(12) Family health history requirements. | The ONC-ACB verifies the health IT developer attests conformance to the § 170.315(a)(12) Family health history requirements. |
§ 170.315 (a)(12) Family health history—
Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in § 170.207(a)(1).
Applies to entire criterion
§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026.)
§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release (This standard is required by December 31, 2025.)
The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.
Deadline: December 31, 2025
Action to be taken: Developers certified to this criterion must update their use of SNOMED CT® standards outlined in the criterion.
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.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
This certification criterion was adopted at § 170.315(a)(12). 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 transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.
For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.
- 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))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 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 using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
03-11-2024
|
- Regulation Text
-
Regulation Text
§ 170.315 (a)(12) Family health history—
Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in § 170.207(a)(1).
- Standard(s) Referenced
-
Applies to entire criterion
§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026.)
§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release (This standard is required by December 31, 2025.)
- Required Update Deadlines
-
The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.
Deadline: December 31, 2025
Action to be taken: Developers certified to this criterion must update their use of SNOMED CT® standards outlined in the criterion.
- Certification Dependencies
-
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.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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 & Security Requirements
-
This certification criterion was adopted at § 170.315(a)(12). 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 transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.
For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.
- 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))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 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 using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
03-11-2024
Certification Companion Guide: Family health history
This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ONC final rules. It extracts key portions of ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Regulations page for links to all ONC final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.
The below table outlines whether this criterion has additional Maintenance of Certification dependencies, update requirements and/or eligibility for standards updates via SVAP. Review the Certification Dependencies and Required Update Deadline drop-downs above if this table indicates “yes” for any field.
| Base EHR Definition | Real World Testing | Insights Condition | SVAP | Requires Updates |
|---|---|---|---|---|
| Not Included | No | No | No | Yes |
Applies to entire criterion
Technical outcome – The health IT permits users to record, change, and access a patient’s family health history according to the SNOMED CT®, U.S. Edition, March 2022 Release.
Clarifications:
- Health IT Modules can present for certification to a more recent version of SNOMED CT®, U.S. Edition than the standard outlined in regulation per ONC’s policy that permits certification to a more recent version of certain vocabulary standards. [see also 80 FR 62612, 89 FR 1224]
- ONC provides the following object identifier (OID) to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
- The SNOMED CT® OID: 2.16.840.1.113883.6.96. [see also 80 FR 62612]
- Health IT developers have the discretion to code associated family health history questions in the manner they choose (e.g., including but not limited to LOINC®). [see also 80 FR 62624]
- At a minimum, the health IT must enable a user to record, change, and access information about a patient’s first degree relative within the said patient’s record. However, health IT does not need be able to access the records of the patient’s first degree relatives for certification. [see also 77 FR 54174]
- ONC's intent with “familial concepts and expressions” is to focus on the first degree relative’s diagnosis. For testing and certification, at a minimum, a system must be able to demonstrate that it can record, change, and access this diagnosis and the familial relationship in a codified manner using SNOMED CT®. The developer has the flexibility to determine how the system will represent the codified familial relationship, pre- or post-coordinated.
|
Technical outcome – The health IT permits users to record, change, and access a patient’s family health history according to the SNOMED CT®, U.S. Edition, March 2022 Release. Clarifications:
|