In general, EHR technology developers can take the three approaches outlined in the table below to meet the transitions of care certification criteria and their included transport standard(s). EHR technology certified according to any one of these three approaches could then be used by eligible providers to meet the CEHRT definition.

As additional context, it is important to keep in mind the “scope of a certification criterion” in the 2014 Edition EHR certification criteria (see 77 FR 54168). In the final rule, we describe that in order for a certification criterion to be met, all specific capabilities expressed under the second regulation text paragraph (e.g., everything under 170.314(b)(1)) would need to be demonstrated for certification. In other words, if EHR technology was presented for certification and could only perform the specific “create a CCDA” capability expressed in 170.314(b)(2)(i), that EHR technology would not meet this certification criterion.

With respect to transport standards, both certification criteria at 170.314(b)(1) and (b)(2) follow the same framework. At a minimum, EHR technology presented for certification must be able to electronically receive and transmit (in the respective certification criteria) transitions of care/referral summaries according to the Applicability Statement for Secure Health Transport. EHR technology developers are also able to seek certification to two optional transport standards:

• The Applicability Statement for Secure Health Transport specification and the XDR and XDM for Direct Messaging specification; and
• The Simple Object Access Protocol (SOAP)-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 standard and the XDR and XDM for Direct Messaging specification.

Approach	Description
	The EHR technology presented for certification can perform all of the specific capabilities expressed by the certification criterion, including the required capabilities for content and transport standard (and any optional transport standards) (e.g., for 170.314(b)(1), receipt according to transport standards, display of CCD/C32, CCR, and CCDA, and incorporation of CCDA sections). To the left, the images are meant to illustrate that the EHR technology presented for certification could be from an EHR technology developer that likely includes other clinical capabilities (top image) or from an EHR technology developer (e.g., HIE/HISP) that focuses on transition of care/transmission related capabilities (bottom image).
	The EHR technology presented for certification can perform most of the capabilities expressed by the certification criterion (e.g., CCDA creation for 170.314(b)(2)), but also relies on a health information exchange (HIE) organization, health information service provider (HISP), or other 3rd party’s technology to perform the required transport standard capability (and any optional transport standards). Under this approach and to meet the certification criterion: The EHR technology must be presented for certification together with the technology supplied by the other entity to perform the transport capability (this other technology would be treated as “relied upon” software under ONC’s certification rules (see FAQ 16)). The certification issued would represent the unique pairing of the EHR technology and the other entity’s transport technology.

Finally, we note that these certification approaches could also be pursued in combination so long as the full scope of the certification criterion is met. For example, in order for an EHR technology developer to get its EHR technology certified to meet the required transport standard capability it could pursue the third approach and also seek certification for its EHR technology’s native capability to perform to the second optional transport requirement (i.e., the SOAP-based RTM + XDR/XDM), which would enable its customers to have additional transport capabilities as part of their CEHRT.