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.

Privacy and Security: This certification criterion was adopted at § 170.315(f)(5). As a result, an ONC-ACB must ensure that a product presented for certification to a § 170.315(f) “paragraph (f)” 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 (f) 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.

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 for which a certificate would be requested.

Privacy and Security: This certification criterion was adopted at § 170.315(f)(5). As a result, an ONC-ACB must ensure that a product presented for certification to a § 170.315(f) “paragraph (f)” 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 (f) 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 for which a certificate would be requested.

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

Clarifications:

For the public health certification criteria in § 170.315(f), health IT will only need to be certified to those criteria that are required to meet the measures the provider intends to report on to meet Objective 8: Public Health and Clinical Data Registry Reporting.

A specific content exchange standard for electronic case reporting (eCR) is not required to meet this criterion. [80 FR 62667]

This criterion may be met through one of the following two ways:

Documentation that sufficiently describes how the Health IT Module meets the functional requirements of the criterion.

Documentation of participation in an initial eCR implementation as part of the Digital Bridge initiative (http://www.digitalbridge.us) and the ability to meet paragraph (i) of this criterion.

The optional use of an ONC-approved test tool for case reporting using standards such as C-CDA, the Structured Data Capture (IHE SDC) Implementation Guide, or the Fast Health Interoperability Resources (FHIR) Structured Data Capture Implementation Guide may be available in the future. While not required to meet this criterion, testing through an ONC-approved test tool for case reporting would meet the requirements of this criterion.

Applies to entire criterion

Clarifications:

For the public health certification criteria in § 170.315(f), health IT will only need to be certified to those criteria that are required to meet the measures the provider intends to report on to meet Objective 8: Public Health and Clinical Data Registry Reporting.

A specific content exchange standard for electronic case reporting (eCR) is not required to meet this criterion. [80 FR 62667]

This criterion may be met through one of the following two ways:

Documentation that sufficiently describes how the Health IT Module meets the functional requirements of the criterion.

Documentation of participation in an initial eCR implementation as part of the Digital Bridge initiative (http://www.digitalbridge.us) and the ability to meet paragraph (i) of this criterion.

The optional use of an ONC-approved test tool for case reporting using standards such as C-CDA, the Structured Data Capture (IHE SDC) Implementation Guide, or the Fast Health Interoperability Resources (FHIR) Structured Data Capture Implementation Guide may be available in the future. While not required to meet this criterion, testing through an ONC-approved test tool for case reporting would meet the requirements of this criterion.

Paragraph (f)(5)(i)

Technical outcome – A Health IT Module is able to consume and maintain a table of trigger codes to determine which encounters should initiate an initial case report being sent to a public health agency.

Clarifications:

An example table of trigger codes is in "Trigger Code Table Examples" under the Reference Documents section on the Test Procedures tab.

Paragraph (f)(5)(i)

Technical outcome – A Health IT Module is able to consume and maintain a table of trigger codes to determine which encounters should initiate an initial case report being sent to a public health agency.

Clarifications:

An example table of trigger codes is in "Trigger Code Table Examples" under the Reference Documents section on the Test Procedures tab.

Paragraph (f)(5)(ii)

Technical outcome – A Health IT Module can match information recorded in a patient visit or encounter to a trigger code in the trigger code table.

Clarifications:

No additional clarifications available.

Paragraph (f)(5)(ii)

Technical outcome – A Health IT Module can match information recorded in a patient visit or encounter to a trigger code in the trigger code table.

Clarifications:

No additional clarifications available.

Paragraph (f)(5)(iii)

Technical outcome – When a trigger is matched in accordance with provision (f)(5)(ii), the Health IT Module electronically creates an initial case report with only the following subset of CCDS data elements:

Patient Name

Sex

Date of Birth

Race and Ethnicity

Preferred language

Problems

Medications

Laboratory Tests

Laboratory Values(s)/Result(s)

Vital Signs

Procedures

Care Team Member(s)

Immunizations

Assessment and Plan of Treatment

Clarifications

We provide the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards [80 FR 62612-13]:

A Health IT Module can present for testing and certification to more recent versions of the following vocabulary standards than the versions adopted in the 2015 Edition final rule [80 FR 62612]:

SNOMED CT®

LOINC®

RxNorm

CVX

NDC

CDC Race Ethnicity Code Set

All data elements included in the CCDS are required to be available by the Health IT Module; however, the test procedure includes only a subset of elements that are required to be included in the case report by public health to support case reporting at this time.

The requirement for an identifier representing the row and version of the trigger table that triggered the case report in (f)(5)(iii)(B) can be met by providing an identifier that will uniquely identify the original file from which the “matched trigger” described above originated (the version of the trigger table) as well as uniquely identify the individual trigger (row) itself.

Paragraph (f)(5)(iii)

Technical outcome – When a trigger is matched in accordance with provision (f)(5)(ii), the Health IT Module electronically creates an initial case report with only the following subset of CCDS data elements:

Patient Name

Sex

Date of Birth

Race and Ethnicity

Preferred language

Problems

Medications

Laboratory Tests

Laboratory Values(s)/Result(s)

Vital Signs

Procedures

Care Team Member(s)

Immunizations

Assessment and Plan of Treatment

Clarifications

We provide the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards [80 FR 62612-13]:

A Health IT Module can present for testing and certification to more recent versions of the following vocabulary standards than the versions adopted in the 2015 Edition final rule [80 FR 62612]:

SNOMED CT®

LOINC®

RxNorm

CVX

NDC

CDC Race Ethnicity Code Set

All data elements included in the CCDS are required to be available by the Health IT Module; however, the test procedure includes only a subset of elements that are required to be included in the case report by public health to support case reporting at this time.

The requirement for an identifier representing the row and version of the trigger table that triggered the case report in (f)(5)(iii)(B) can be met by providing an identifier that will uniquely identify the original file from which the “matched trigger” described above originated (the version of the trigger table) as well as uniquely identify the individual trigger (row) itself.