Printer Friendly, PDF & Email Printer Friendly, PDF & Email

§170.315(b)(1) Transitions of care

Updated on 03-11-2024
Regulation Text
Regulation Text

§ 170.315 (b)(1) Transition of care

  1. Send and receive via edge protocol—
    1. Send transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in § 170.202(a); and
    2. Receive transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) from a service that has implemented the standard specified in § 170.202(a)(2).
    3. XDM processing. Receive and make available the contents of a XDM package formatted in accordance with the standard adopted in § 170.205(p)(1) when the technology is also being certified using an SMTP-based edge protocol.
  2. Validate and display —
    1. Validate C-CDA conformance – system performance. Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standards specified in § 170.205(a)(3), (4), and (5) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:
      1. Parse each of the document types.
      2. Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(3), (4), and (5).
      3. Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(3), (4), and (5).
      4. Correctly interpret empty sections and null combinations.
      5. Record errors encountered and allow a user through at least one of the following ways to:
        1. Be notified of the errors produced.
        2. Review the errors produced.
    2. Display. Display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in § 170.205(a)(3), (4), and (5).
    3. Display section views. Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in § 170.205(a)(3), (4), and (5) in a manner that enables the user to:
      1. Directly display only the data within a particular section;
      2. Set a preference for the display order of specific sections; and
      3. Set the initial quantity of sections to be displayed.
  3. Create. Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in § 170.205(a)(3), (4), and (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:
    1.  
      1. The data classes expressed in the standard in § 170.213 and in accordance with § 170.205(a)(4), (a)(5), and paragraphs (b)(1)(iii)(A)(3)(i) through (iii) of this section, for the time period up to and including December 31, 2025, or
      2. The data classes expressed in the standards in § 170.213 and in accordance with § 170.205(a)(4), (6), and paragraphs (b)(1)(iii)(A)(3)(i) through (iii) of this section, and 
      3. The following data classes:
        1. Assessment and plan of treatment. In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).
        2. Goals. In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
        3. Health concerns. In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
        4. Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).
    2. Encounter diagnoses. Formatted according to at least one of the following standards:
      1. The standard specified in § 170.207(i).
      2. At a minimum, the version of the standard specified in § 170.207(a)(1).
    3. Cognitive status.
    4. Functional status.
    5. Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.
    6. Inpatient setting only. Discharge instructions.
    7. Patient matching data. First name, last name, previous name, middle name (including middle initial), suffix, date of birth, current address, phone number, and sex. The following constraints apply:
      1. Date of birth constraint.
        1. The year, month and day of birth must be present for a date of birth. The technology must include a null value when the date of birth is unknown.
        2. Optional. When the hour, minute, and second are associated with a date of birth the technology must demonstrate that the correct time zone offset is included.
      2. Phone number constraint. Represent phone number (home, business, cell) in accordance with the standards adopted in § 170.207(q)(1). All phone numbers must be included when multiple phone numbers are present.
      3. Sex constraint. Represent sex in accordance with the standard adopted in § 170.207(n)(1) up to and including December 31, 2025; or with the standard adopted in § 170.207(n)(2).
Standard(s) Referenced

Paragraphs (b)(1)(i)(A) and (B)

§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2 August 2015

§ 170.202(d) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014

Paragraph (b)(1)(i)(C)

§ 170.205(p)(1) IHE IT Infrastructure Technical Framework Volume 2b (ITI TF- 2b)

Paragraph (b)(1)(ii)

§ 170.205(a)(3) Health Level 7 (HL7®) Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use July 2012

§ 170.205(a)(4)  HL7® Implementation Guide for CDA Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1, August 2015, June 2019 (with Errata)

§ 170.205(a)(5) HL7® CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2, October 2019, IBR approved for § 170.205(a)(5). (Adoption of this standard expires on January 1, 2026)

§ 170.205(a)(6) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 - US Realm (This standard is required by December 31, 2025)

Paragraphs (b)(1)(iii)(A)-(F)

§ 170.213(a) United States Core Data for Interoperability (USCDI) July 2020 Errata, Version 1 (v1) (Adoption of this standard expires on January 1, 2026)

§ 170.213(b) United States Core Data for Interoperability (USCDI), October 2022 Errata, Version 3 (v3) (This standard is required by December 31, 2025)

§ 170.205(a)(3) HL7® Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use July 2012

§ 170.205(a)(4)  HL7® Implementation Guide for CDA Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1 with Errata, August 2015, June 2019 (with Errata)

§ 170.205(a)(5) HL7® CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2, October 2019, IBR approved for § 170.205(a)(5). (Adoption of this standard expires on January 1, 2026)

§ 170.205(a)(6) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 - US Realm (This standard is required by December 31, 2025)

§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT® ) U.S. Edition, September 2019 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)

§ 170.207(i) Encounter diagnoses: The code set specified at 45 CFR 162.1002(c)(2) for the indicated conditions ICD-10-CM as maintained and distributed by the Department of Health and Human Services (HHS), for the following conditions:

  1. Diseases.
  2. Injuries.
  3. Impairments.
  4. Other health problems and their manifestations.
  5. Causes of injury, disease, impairment, or other health problems.

Paragraph (b)(1)(iii)(G)

§ 170.205(a)(4) HL7® Implementation Guide for CDA® Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1, August 2015, June 2019 (with Errata)

§ 170.205(a)(5) HL7® CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2, October 2019, IBR approved for § 170.205(a)(5). (Adoption of this standard expires on January 1, 2026)

§ 170.205(a)(6) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 - US Realm (This standard is required by December 31, 2025)

§ 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows:

  1. Male. M
  2. Female. F
  3. Unknown. nullFlavor UNK (Adoption of this standard expires on January 1, 2026)

§ 170.207(n)(2) Sex must be coded in accordance with, at a minimum, the version of SNOMED CT® U.S. Edition codes specified in § 170.207(a)(1). (This standard is required by December 31, 2025)

§ 170.207(q)(1) International Telecommunication Union E.123: Notation for national and international telephone numbers, e-mail addresses and web addresses and International Telecommunication Union E.164: The international public telecommunication numbering plan

Standards Version Advancement Process (SVAP) Version(s) Approved 

§ 170.202(a)(2) Applicability Statement for Secure Health Transport Version 1.3, May 2021 (Direct)

For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.

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 standards and minimum standard code sets outlined in paragraphs (b)(1)(ii) and (b)(1)(iii)(A)-(F). Developers must add functionality certified to the standards referenced in paragraphs (b)(1)(iii)(A)-(F).

Certification Dependencies

Conditions and Maintenance of Certification Requirements

Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.

Design and Performance Requirements: 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, when different QMS are used, each QMS needs to be separately 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.
  • Consolidated CDA creation performance (§ 170.315(g)(6)) does not need to be explicitly tested with this criterion unless it is the only criterion within the scope of the requested certification that includes C-CDA creation capabilities. Note that the application of § 170.315(g)(6) depends on the C-CDA templates explicitly required by the C-CDA-referenced criterion or criteria included within the scope of the certificate sought. Please refer to the C-CDA creation performance CCG for more details.
Privacy & Security Requirements

Privacy and Security: This certification criterion was adopted at § 170.315(b)(1). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(b) 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 tested 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.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Testing
Testing Tool

 

Edge Testing Tool (ETT): Message Validators and Edge Testing

Testing must be conducted for one of the Sending Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion.
Testing must also be conducted for one of the alternative connection requirements within each of the Sending Alternatives.
Note: The “Secure Network” alternative only needs to be verified once for the Testing Procedure. (Where applicable the TLS required should be unchecked in the ETT Profile).

Testing must be conducted for one of the Receiving Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion: IHE XDR, SMTP, IMAP, or POP3.

 

Test Tool Documentation

Test Tool Supplemental Guide

 

 

Criterion Subparagraph Test Data
(b)(1)(ii)(A)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Outpatient setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

Test Data (Payload):

Inpatient setting 170.315_b1_toc_inp_*_r11_sample*.xml
170.315_b1_toc_inp_*_r21_sample*.xml

Outpatient setting 170.315_b1_toc_amb_*_r11_sample*.xml
170.315_b1_toc_amb_*_r21_sample*.xml

Negative Tests: NT_*_r11*.xml
NT_*_r21*.xml

(b)(1)(ii)(B)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Ambulatory setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

(b)(1)(ii)(C)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Ambulatory setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

(b)(1)(iii)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Ambulatory setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

Revision History
Version # Description of Change Version Date
1.0

Initial publication

03-11-2024

This Test Procedure illustrates the test steps required to certify a Health IT Module to this criterion. Please consult the most recent ONC Final Rule on the Certification Regulations page for a detailed description of the certification criterion with which these testing steps are associated. ONC also encourages developers to consult the Certification Companion Guide in tandem with the test procedure as it provides clarifications that may be useful for product development and testing.

Note: The test step order does not necessarily prescribe the order in which the tests should take place.

Testing components

Documentation Icon Visual Inspection Icon Test Tool Icon ONC Supplied Test Data Icon SVAP Icon

The testing depends on which Edge Protocol the Health IT Module chooses for certification.

Testing must be conducted for one of the Sending Alternatives outlined below to satisfy the requirements for this criterion. Testing must also be conducted for one of the alternative connection requirements within each of the Sending Alternatives.

Note: The “Secure Network” alternative only needs to be verified once for the Testing Procedure. (Where applicable the TLS required should be unchecked in the Edge Testing Tool (ETT) Profile).

System Under Test
ONC-ACB Verification
Required by December 31, 2025

A health IT developer of a Health IT Module currently certified to the § 170.315(b)(1) Transitions of Care will attest directly to the ONC-ACB to conformance with the updated § 170.315(b)(1) requirements outlined in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule. 

Required by December 31, 2025

The ONC-ACB verifies the health IT developer of a Health IT Module certified to § 170.315(b)(1) Transitions of Care attests conformance to § 170.315(b)(1) criterion update requirements.   


System Under Test Test Lab Verification

System Under Test Connection – Using TLS and SASL

  1. Using the ETT “XDR Cases” with “System as Sender” and the Cures checkbox checked, the user establishes a Mutual TLS session for the Health IT Module to authenticate to the ETT (XDR Test 6).
  2. The user authenticates the Health IT Module to the ETT using an incorrect Mutual TLS session (XDR Test 7).

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.

Send Payload

  1. The user configures the ETT’s endpoints within the Health IT Module by providing the Health IT Module’s Direct “From” address to generate endpoints. The Health IT Module sends the payloads created at section (b)(1)(iii) of the SUT as applicable through the user selection of the criteria “170.315_b1_ToC_Amb” or “170.315_b1_ToC_Inp” based upon the health IT setting and the file name as a Continuity of Care Document (CCD), Referral Note, or (inpatient setting only) a Discharge Summary using the following types of messages:
    • Limited Metadata (XDR Test 1); and
    • Full Metadata (XDR Test 2).
      Note: The user is required to send at least one payload using Limited Metadata and at least one payload using Full Metadata.

Message Tracking

  1. The user sends health information to the ETT and receives both a positive (success) Delivery Status Notification (XDR MT Test 20a) and a negative (failure) Delivery Status Notification (XDR MT Test 20b).

Delivery Notification

  1. The user sends an XDR message to Endpoint 14 using the Edge Testing Tool with a valid Direct Address Block and Delivery Notifications header (XDR MT Test 49).

System Under Test Connection – Using TLS and SASL

  1. Using the ETT, the tester verifies the Health IT Module establishes a mutual TLS session prior to transmitting any data (XDR Test 6).
  2. Using the ETT, the tester verifies that the Health IT Module disconnects when the ETT provides an invalid certificate and incorrect Mutual TLS configuration (XDR 7).

System Under Test Connection – Secure Network If Not Using TLS

  1. The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).

Send Payload

  1. Using the ETT Logs, the tester verifies the Health IT Module can send the following using § 170.202(d) (The verification of the payload is performed in section (b)(1)(iii)):
  • XDR Message using limited Metadata (XDR Test 1); and
  • XDR Message using full Metadata (XDR Test 2).

Message Tracking

  1. Using the ETT and inspection of Health IT Module logs, the tester verifies the Health IT Module successfully handles the Delivery Status Notification response, including messages indicating a success (XDR MT Test 20a) and a failure (XDR MT Test 20b).

Delivery Notification

  1. Using the ETT, the tester verifies the Health IT Module is able to generate the Direct Address Block header including the Disposition Notifications header (XDR MT Test 49). The tester verifies the disposition header in the ETT Logs.

System Under Test Test Lab Verification

System Under Test Connection – TLS and SASL

  1. Using the ETT “SMTP Tests,” “System as Sender,” and the Cures checkbox checked, the user initiates a TLS session for the Health IT Module with the ETT (SMTP Test 8).
  2. The user authenticates the Health IT Module with the ETT using PLAIN SASL as an SMTP server from the username supplied by the ETT email account being authenticated to the ETT SMTP email address (SMTP Test 14).
  3. The Health IT Module provides documentation of the Health IT Module’s ability to reject the connection for a TLS session initiated with a HISP due to an invalid certificate.

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.

Send Payload

  1. The user sends a document to the ETT (SMTP Test 18). The payloads created at section (b)(1)(iii) shall be sent as applicable by the user selection of the criteria “170.315_b1_ToC_Amb” or “170.315_b1_ToC_Inp” based upon the health IT setting and the file name as a CCD, Referral Note, or (inpatient setting only) a Discharge Summary.

Delivery Notification

  1. The user sends an SMTP mail message to the ETT with a valid Disposition-Notifications-Options Header per section 1.3 of the § 170.202(e)(1) ONC Implementation Guide for Delivery Notification in Direct v1.0 (SMTP MT Test 46).

System Under Test Connection – TLS and SASL

  1. Using the ETT, the tester verifies the Health IT Module initiates a TLS session (SMTP Test 8).
  2. Using the ETT, the tester verifies the Health IT Module can authenticate using PLAIN SASL authentication (SMTP Test 14).
  3. The tester verifies evidence of the Health IT Module’s capability to initiate a TLS session but reject the connection with a HISP due to an invalid certificate.

System Under Test Connection – Secure Network If Not Using TLS

  1. The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).

Send Payload

  1. The tester verifies the Health IT Module can send a message (SMTP Test 18). The verification of the payload is performed in section (b)(1)(iii).

Delivery Notification

  1. Using the ETT, the tester verifies the Health IT Module successfully performs delivery notification handling per the § 170.202(e)(1) (SMTP MT Test 46).

Testing must be conducted for one of the Receiving Alternatives outlined below to satisfy the requirements for this criterion: IHE XDR, SMTP, IMAP, or POP3. Testing must also be conducted for one of the alternative connection requirements within each of the Sending Alternatives.
Note: The “Secure Network” alternative only needs to be verified once for the Testing Procedure. (Where applicable the TLS required should be unchecked in the ETT Profile).

System Under Test Test Lab Verification

System Under Test Connection – Using TLS and SASL

  1. Using the ETT “XDR Tests” for “System as Receiver” and the Cures checkbox checked, the user establishes authentication from the ETT to the Health IT Module using Mutual TLS correctly (XDR Test 8).
  2. Using the ETT, the user establishes authentication from the ETT to the Health IT Module using bad certificates (incorrect Mutual TLS configuration (XDR Test 9)).

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.

Receive Payload

  1. For each required payload specified in (b)(1)(ii), the user selects the appropriate criteria “170.315_b1_ToC_Amb,” “170.315_b1_ToC_Inp,” or “NegativeTesting_USCDI” and then selects the file name to be received by the Health IT Module as a properly formatted XDR message with limited metadata from the ETT (XDR Test 3).
  2. The Health IT Module receives a properly formatted XDR message with full metadata from the ETT (XDR Test 5).
    Note: The user is required to receive a single payload using both limited and full metadata.

Incorrect XDR Message Receive

  1. The Health IT Module returns errors when a malformed message is received from the ETT with an invalid SOAP header (XDR Test 4a).
  2. The Health IT Module returns errors when the following malformed messages are received from the ETT, the case with invalid SOAP body details (XDR Test 4b) including:
    • Missing metadata elements;
    • Missing associations between ebRIM constructs;
    • Missing Direct Address block.

System Under Test Connection – Using TLS and SASL

  1. Using the ETT, the tester verifies the Health IT Module is capable of accepting and validating a Mutual TLS session when authenticating to the ETT. Using visual inspection of the logs, the tester verifies the Health IT Module does not accept connections due to incorrect Mutual TLS configuration (XDR Test 8).
  2. Using visual inspection of the logs, the tester verifies the Health IT Module does not accept connections due to an invalid certificate published by the ETT (XDR Test 9).

System Under Test Connection – Secure Network If Not Using TLS

  1. The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).

Receive Payload

  1. Using visual inspection of the logs, the tester verifies the Health IT Module is capable of receiving and processing a valid XDR message with limited metadata. The verification of the payload is performed in section (b)(1)(ii) (XDR Test 3).
  2. Using visual inspection of the logs, the tester verifies the Health IT Module is capable of receiving and processing a valid XDR message with full metadata (XDR Test 5).

Incorrect XDR Message Receive

  1. Using logs, the tester verifies that the Health IT Module recognizes that the messages sent from the ETT are malformed messages (XDR Test 4a).
  2. Using logs, the tester verifies that the Health IT Module rejects the malformed messages (XDR Test 4b).

System Under Test Test Lab Verification

System Under Test Connection – Using TLS and SASL

  1. Using the ETT “SMTP Tests” for “System as Receiver” and the Cures checkbox checked, the user initiates a valid TLS session for the Health IT Module with the ETT sent from the email address the username supplied by the Health IT Module email account being authenticated to the Health IT Module SMTP email address (SMTP Test 9).
  2. The user authenticates the ETT with the Health IT Module using PLAIN SASL as an SMTP server from the username supplied by the Health IT Module email account being authenticated to the Health IT Module SMTP email address (SMTP Test 16).
  3. The Health IT Module provides documentation of the ability to establish a STARTTLS connection and reject the connection upon receiving an invalid certificate from a HISP.

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a "secure network" as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.

Receive Payload

  1. For each of the applicable ambulatory and/or inpatient setting transition of care/referral summary payloads (Continuity of Care Document (CCD), Referral Note, and Discharge Summary) and the Negative Consolidated-Clinical Document Architecture (C-CDA) tests, the user selects the payload type and receives a document from the ETT using valid SMTP commands from the username supplied by the Health IT Module email account being authenticated and establishes a connection with the ETT (SMTP Test 20).

Receive Multiple Attachments

  1. The user receives multiple attachments (with appropriate MIME type) by running each of the following ETT Test Cases:
    • Text and C-CDA (SMTP Test 25(a));
    • PDF and C-CDA (SMTP Test 25(b));
    • Text and XDM Package (SMTP Test 25(c));
    • C-CDA and Text (SMTP Test 25(d));
    • C-CDA and PDF (SMTP Test 25(e));
    • XDM and Text (SMTP Test 25(f)).

Style Sheet/Header (Negative Testing)

  1. The user receives a bad attachment by running each of the following ETT Test Cases:
    • A bad C-CDA with a broken reference to the style sheet (SMTP Test 26(a));
    • A good C-CDA with a bad style sheet (SMTP Test 26(b)).
  2. The user receives an XDM package with a bad XHTML (SMTP Test 27).

MIME Type

  1. The user receives an XDM package with a MIME type of ‘application/octet-stream’ (SMTP layer) (SMTP Test 28).
  2. The user receives an XDM package containing a C-CDA with a MIME type of ‘application/xml’ (XDM layer) (SMTP Test 29).

System Under Test Connection – Using TLS and SASL

  1. Using the ETT, the tester verifies a secure session was established with the Health IT Module based upon TLS initiation using correct syntax (SMTP Test 9).
  2. Using the ETT with a predetermined username and password, the tester verifies a secure session was established with the Health IT Module with PLAIN SASL authentication (SMTP Test 16).
  3. The tester verifies evidence of the capability of the Health IT Module to establish a STARTTLS connection and reject the connection upon receiving an invalid certificate from the server.

System Under Test Connection – Secure Network If Not Using TLS

  1. The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).

Receive Payload

  1. Using the ETT, the tester verifies the Health IT Module can receive an SMTP Message using § 170.202(d), and the Validation Report indicates the successful sequence of commands for SMTP protocols for each of the required payloads (SMTP Test 20).

Receive Multiple Attachments

  1. Using the ETT logs for Tests 25 a-f, the tester uses visual inspection to verify that the Health IT Module can successfully receive the multiple attachment types received by the SUT in step 6 and that the Validation Report indicates the successful sequence of commands for SMTP protocols for each of the following attachment types:
    • Text and C-CDA (SMTP Test 25(a));
    • PDF and C-CDA (SMTP Test 25(b));
    • Text and XDM Package (SMTP Test 25(c));
    • C-CDA and Text (SMTP Test 25(d));
    • C-CDA and PDF (SMTP Test 25(e));
    • XDM and Text (SMTP Test 25(f)).

Style Sheet/Header (Negative Testing)

  1. Using the ETT logs and the Health IT Module identified functions, the tester verifies that the Health IT Module accepts the attachment and is able to handle the style sheet anomalies as received by the System Under Test in step 7, and that the Validation Report acknowledges an issue for each invalid C-CDA:
    • A C-CDA with a broken reference to a style sheet (SMTP Test 26(a)); and
    • A C-CDA with a good reference but an invalid style sheet (SMTP Test 26(b)).
  2. Using the ETT logs and the Health IT Module identified functions, the tester verifies that the Health IT Module accepts the XDM package with the bad XHTML (SMTP Test 27).

MIME Type

  1. Using the ETT logs and the Health IT Module identified functions, the tester uses visual inspection to verify that the Health IT Module can successfully receive an XDM package with a MIME type of ‘application/octet-stream’ as received by the System Under Test in step 9 (SMTP Test 28).
  2. Using the ETT logs and the Health IT Module identified functions, the tester uses visual inspection to verify that the Health IT Module can successfully receive an XDM package with a MIME type of ‘application/xml’ as received by the SUT in step 10, and accepts the C-CDA within the XDM package (SMTP Test 29).

System Under Test Test Lab Verification

System Under Test Connection – Using TLS and SASL

  1. Using the ETT “IMAP Tests” for “System as Receiver” and the Cures checkbox checked, the user initiates an IMAP session with STARTTLS and PLAIN SSL authentication with the ETT (IMAP Test 19).
  2. The Health IT Module provides documentation of the ability to connect using a valid cipher suite in accordance with RFC 3501 and the subsequently updated standards: RFC 2246, NIST Special Publication 800-52 Revision 1, RFC 7465, and is in accordance with § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1 and the security standards specified in the § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2. (IMAP Test 20),

or

  • (Approved SVAP Version)
    • Direct Project: ONC Applicability Statement for Secure Health Transport, v1.3. 

      3. The Health IT Module provides documentation of the ability to establish a STARTTLS connection and reject the connection upon receiving an invalid certificate from a HISP.

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.

IMAP Receive

  1. The user demonstrates the Health IT Module can retrieve the email attachment from the specified ETT email server (IMAP Test 24).
  2. The user demonstrates the Health IT Module can use either the uppercase, lowercase, or mixed case mailbox names and access data (IMAP Test 21).
  3. The Health IT Module is able to receive status and size updates from the IMAP4 server (IMAP Test 25).
  4. The user demonstrates the Health IT Module’s capability to accept XDM packages sent using appropriate MIME types (IMAP Test 27).
  5. The user demonstrates the Health IT Module’s capability to receive multiple attachments from the ETT (IMAP Test 28).
  6. The user demonstrates the Health IT Module’s capability to receive the following bad attachments from the ETT:
    • C-CDA document including a broken reference to a style sheet (IMAP Test 29a); and
    • C-CDA document including a good reference to an invalid style sheet (IMAP Test 29b).
  7. The user demonstrates the Health IT Module’s capability to receive an XDM package with a bad XHTML from the ETT (IMAP Test 30).
  8. The user demonstrates the Health IT Module’s capability to receive different attachments (IMAP Test 31).

System Under Test Connection – Using TLS and SASL

  1. Using the ETT, the tester verifies the Health IT Module is able to successfully initiate an IMAP4 session with the ETT (IMAP Test 19).
  2. The tester verifies evidence of the capability to connect only using a valid cipher suite (only when offered by the HISP) (IMAP Test 20).
  3. The tester verifies evidence of the capability of the Health IT Module to reject a STARTTLS connection upon receiving an invalid certificate from the server.

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d).

IMAP Receive

  1. The tester verifies the Health IT Module is able to retrieve the email attachment from the specified ETT email server (IMAP Test 24).
  2. The tester verifies the Health IT Module is able to use either the uppercase, lowercase, or mixed case mailbox names and access data (IMAP Test 21).
  3. The tester verifies the Health IT Module is able receive status and size updates from the IMAP4 server (IMAP Test 25).
  4. Using the ETT and Health IT Module logs, the tester verifies the Health IT Module accepts the XDM with the specified MIME type (IMAP Test 27).
  5. The tester verifies the Health IT Module accepts attachments (text, PDF, and C-CDA Documents) sent from the ETT (IMAP Test 28).
  6. The tester verifies the Health IT Module accepts the following C-CDA documents sent from the ETT:
    • C-CDA document with a broken reference to a style sheet (IMAP Test 29a); and
    • C-CDA document with a good reference to the style sheet but an invalid style sheet (IMAP Test 29b).
  7. The tester verifies the Health IT Module accepts an XDM package sent from the ETT with bad XHTML (IMAP Test 30).
  8. The tester verifies the Health IT Module accepts different attachment types sent from the ETT (IMAP Test 31).

System Under Test Test Lab Verification

System Under Test Connection – TLS and SASL

  1. Using the ETT “POP3 Tests” for “System as Receiver” and the Cures checkbox checked, the user initiates POP3 sessions with the ETT (POP Test 19).
  2. The Health IT Module provides documentation of the ability to connect using a valid cipher suite in accordance with RFC 3501 and the subsequently updated standards: RFC 2246, NIST Special Publication 800-52 Revision 1, RFC 7465, and is in accordance with § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1 and the security standards specified in the § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2. (POP Test 20),

or

  • (Approved SVAP Version)
    • Direct Project: ONC Applicability Statement for Secure Health Transport, v1.3. 

     3. The Health IT Module provides documentation of the ability to establish a STARTTLS connection and reject the connection upon receiving an invalid certificate from a HISP.

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols v1.1.

POP3 Receive

  1. The user demonstrates the Health IT Module’s ability to retrieve an email attachment from the specified ETT email server (POP Test 24).
  2. The user demonstrates the Health IT Module’s ability to accept XDM packages sent using appropriate MIME types (POP Test 27).
  3. The user demonstrates the Health IT Module’s capability to receive multiple attachments from the ETT (POP Test 28).
  4. The user demonstrates the Health IT Module’s capability to receive the following bad attachments from the ETT:
    • C-CDA document including a broken reference to a style sheet (POP Test 29a); and
    • C-CDA document including a good reference to an invalid style sheet (POP Test 29b).
  5. The user demonstrates the Health IT Module’s capability to receive an XDM package with a bad XHTML from the ETT (POP Test 30).
  6. The user demonstrates the Health IT Module’s capability to receive different attachments (POP Test 31).

System Under Test Connection – TLS and SASL

  1. Using the ETT, the tester verifies the Health IT Module is able to successfully initiate POP3 sessions with the ETT (POP Test 19).
  2. The tester verifies evidence of the capability to connect only using a valid cipher suite (only when offered by the HISP) (POP Test 20).
  3. The tester verifies evidence of the capability of the Health IT Module to reject a STARTTLS connection upon receiving an invalid certificate from the server.

System Under Test Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the System Under Test by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d).

POP3 Receive

  1. The tester verifies the Health IT Module is able to retrieve an email attachment from the specified ETT email server (POP Test 24).
  2. Using the ETT and Health IT Module logs, the tester verifies the Health IT Module accepts the XDM with the specified MIME type (POP Test 27).
  3. The tester verifies the Health IT Module accepts attachments (Text, PDF and C-CDA documents) sent from the ETT (POP Test 28).
  4. The tester verifies the Health IT Module accepts the following C-CDA documents sent from the ETT:
    • C-CDA document with a broken reference to a style sheet (POP Test 29a); and
    • C-CDA document with a good reference to the style sheet but an invalid style sheet (POP Test 29b).
  5. The tester verifies the Health IT Module accepts an XDM package sent from the ETT with bad XHTML (POP Test 30).
  6. The tester verifies the Health IT Module accepts different attachment types sent from the ETT (POP Test 31).

System Under Test Test Lab Verification

Receive XDM Payload

  1. Using the ETT “SMTP Tests” for “System as Receiver” and the Cures checkbox checked, the user selects each of the XDM payload attachment types (limited and full metadata) within the ETT and receives an XDM document from the ETT using valid SMTP commands from the username supplied by the Health IT Module email account being authenticated (SMTP Test 20).

Validate XDM Package

  1. The user downloads the XDM payload from the System Under Test, navigates to the ETT Message Validator, XDM Validator, and uploads the XDM payload to the XDM Validator to perform validation of the XDM package.

Receive XDM Payload

  1. The tester verifies both a limited and full metadata XDM payload can be successfully received by the Health IT Module from the ETT.

Validate XDM Package

  1. Using the ETT XDM Validator with Toolkit, the tester verifies the XDM payload received by the Health IT Module successfully passes XDM validation.

System Under Test Test Lab Verification
Expires on January 1, 2026

Receive Payload

  1. Based upon the health IT setting(s) to be certified, the Health IT Module receives transition of care/referral summary payloads via the Edge Protocol as specified in section (b)(1)(i)(B) for each ambulatory and/or inpatient transition of care (xml) document. All of the transitions of care documents for a given health IT setting must be received (both C-CDA Release 1.1 and C-CDA Release 2.1 formats).

Parse and Process

  1. The Health IT Module parses each of the following ambulatory and/or inpatient setting applicable C-CDA document types formatted as a CCD in accordance with the standards specified in § 170.205(a)(3) HL7® Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 or a C-CDA according to § 170.205(a)(4) HL7® Implementation Guide for CDA® Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1 with Errata, August 2015, June 2019 (with Errata) and § 170.205(a)(5) HL7® CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2, October 2019 with one of following document-templates:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.
  2. The Health IT Module processes the valid document-templates and the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(3), and § 170.205(a)(4) and § 170.205(a)(5).
  3. Each of these documents includes, at a minimum, as applicable, the following:
    • All of the data elements as specified in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205(a)(5);
    • Encounter diagnoses;
    • Cognitive status;
    • Functional status;
    • Ambulatory setting only, the following data elements: reason for referral, and referring or transitioning provider's name and office contact information; and
    • Inpatient setting only: the discharge instructions.
  4. The Health IT Module further processes the document for valid document-templates with empty sections and null combinations in accordance with document-templates from the standards adopted in § 170.205(a)(3), or § 170.205(a)(4) and § 170.205(a)(5), and interprets them correctly.

Negative Testing

  1. The Health IT Module receives a series of invalid C-CDA document types via the Edge Protocol (b)(1)(i)(B) for C-CDA R2 Release 1.1 and C-CDA R2 Release 2.1 documents, and correctly parses the invalid documents which contain errors in the “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(3) or § 170.205(a)(4) and § 170.205(a)(5) and reports the errors.

Error Reporting

  1. A user is notified or can review the recorded errors encountered during the parsing and processing of C-CDA documents.
Required by December 31, 2025

Receive Payload

  1. Based upon the health IT setting(s) to be certified, the Health IT Module receives transition of care/referral summary payloads via the Edge Protocol as specified in section (b)(1)(i)(B) for each ambulatory and/or inpatient transition of care (xml) document. All of the transitions of care documents for a given health IT setting must be received (both C-CDA Release 1.1 and C-CDA Release 2.1 with Cures Update formats).

Parse and Process

  1. The Health IT Module parses each of the following ambulatory and/or inpatient setting applicable C-CDA document types formatted as a CCD in accordance with the standards specified in § 170.205(a)(3) HL7® Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 or a C-CDA according to § 170.205(a)(4) HL7® Implementation Guide for CDA® Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1 with Errata, August 2015, June 2019 (with Errata) and § 170.205(a)(6) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 - US Realm with one of following document-templates:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.
  2. The Health IT Module processes the valid document-templates and the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(3), and § 170.205(a)(4) and § 170.205(a)(6).
  3. Each of these documents includes, at a minimum, as applicable, the following:
    • All of the data elements as specified in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205(a)(6);
    • Encounter diagnoses;
    • Cognitive status;
    • Functional status;
    • Ambulatory setting only, the following data elements: reason for referral, and referring or transitioning provider's name and office contact information; and
    • Inpatient setting only: the discharge instructions.
  4. The Health IT Module further processes the document for valid document-templates with empty sections and null combinations in accordance with document-templates from the standards adopted in § 170.205(a)(3), or § 170.205(a)(4) and § 170.205(a)(6), and interprets them correctly.

Negative Testing

  1. The Health IT Module receives a series of invalid C-CDA document types via the Edge Protocol (b)(1)(i)(B) for C-CDA R2 Release 1.1 and C-CDA R2 Release 2.1 documents, and correctly parses the invalid documents which contain errors in the “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(3) or § 170.205(a)(4) and § 170.205(a)(6) and reports the errors.

Error Reporting

  1. A user is notified or can review the recorded errors encountered during the parsing and processing of C-CDA documents.
Expires on January 1, 2026

Receive Payload

  1. Using the ETT: Message Validators - USCDI v1 R2.1 Validator, the tester downloads the appropriate ONC-supplied transition of care instruction documents by selecting the “170.315_b1_ToC_Amb,” “170.315_b1_ToC_Inp,” or “NegativeTesting_USCDI” criteria and the file name.

Parse and Process

  1. For each payload received in step 1 of the System Under Test, the tester uses the downloaded ONC-Supplied transition of care instruction document downloaded in step 1 and visual inspection to verify that the Health IT Module can successfully receive, parse, and process the applicable types of transition of care/referral summaries formatted as a CCD or a C-CDA with no specific document template according to the standard adopted in § 170.205(a)(3) or as a C-CDA according to the standard adopted in § 170.205(a)(4) and § 170.205(a)(5) with the following document –templates as applicable:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.
  2. The tester verifies that summaries received, parsed, and processed in step 2 of the System Under Test contain the data elements required in the corresponding section-templates and entry-templates according to the standard adopted in § 170.205(a)(3) or as a C-CDA according to the standard adopted in § 170.205(a)(4) and § 170.205(a)(5).
  3. The tester verifies that summaries received, parsed, and processed in step 2 of the System Under Test also contain the following data elements as applicable:
    • All of the data elements as specified in the in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205(a)(5);
    • Encounter diagnoses;
    • Cognitive status;
    • Functional status;
    • Ambulatory setting only, the following data elements: reason for referral, and referring or transitioning provider's name, and office contact information; and
    • Inpatient setting only: the discharge instructions.
  4. The tester verifies that valid empty sections and null combinations are used in the C-CDA documents processed in step 2 of the System Under Test with corresponding section-templates and entry-templates are successfully interpreted in accordance with the standards adopted in § 170.205(a)(3),or § 170.205(a)(4) and § 170.205(a)(5),  for each of the following document types:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.

Negative Testing

  1. Negative Test: For each invalid payload received in step 6, of the System Under Test, the tester uses visual inspection to verify the Health IT Module can identify errors in the C-CDA documents not specified in accordance with the standards adopted in § 170.205(a)(3), and § 170.205(a)(4) and § 170.205(a)(5) including:
    • “document –templates”;
    • “section-templates”;
    • “entry-templates”;
    • invalid vocabulary standards;
    • invalid codes.

Error Reporting

  1. Using visual inspection, the tester verifies that errors encountered during the parsing and processing of the C-CDA documents are recorded and that users are either notified of errors encountered OR a mechanism is provided for users to review all of the recorded errors encountered.
Required by December 31, 2025

Receive Payload

  1. Using the ETT: Message Validators - USCDI v3 R2.1 Validator, the tester downloads the appropriate ONC-supplied transition of care instruction documents by selecting the “170.315_b1_ToC_Amb,” “170.315_b1_ToC_Inp,” or “NegativeTesting_USCDI” criteria and the file name.

Parse and Process

  1. For each payload received in step 1 of the System Under Test, the tester uses the downloaded ONC-Supplied transition of care instruction document downloaded in step 1 and visual inspection to verify that the Health IT Module can successfully receive, parse, and process the applicable types of transition of care/referral summaries formatted as a CCD or a C-CDA with no specific document template according to the standard adopted in § 170.205(a)(3) or as a C-CDA according to the standard adopted in § 170.205(a)(4) and § 170.205(a)(6) with the following document –templates as applicable:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.
  2. The tester verifies that summaries received, parsed, and processed in step 2 of the System Under Test contain the data elements required in the corresponding section-templates and entry-templates according to the standard adopted in § 170.205(a)(3) or as a C-CDA according to the standard adopted in § 170.205(a)(4) and § 170.205(a)(6).
  3. The tester verifies that summaries received, parsed, and processed in step 2 of the System Under Test also contain the following data elements as applicable:
    • All of the data elements as specified in the in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205(a)(6);
    • Encounter diagnoses;
    • Cognitive status;
    • Functional status;
    • Ambulatory setting only, the following data elements: reason for referral, and referring or transitioning provider's name, and office contact information; and
    • Inpatient setting only: the discharge instructions.
  4. The tester verifies that valid empty sections and null combinations are used in the C-CDA documents processed in step 2 of the System Under Test with corresponding section-templates and entry-templates are successfully interpreted in accordance with the standards adopted in § 170.205(a)(3),or § 170.205(a)(4) and § 170.205(a)(6),  for each of the following document types:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.

Negative Testing

  1. Negative Test: For each invalid payload received in step 6, of the System Under Test, the tester uses visual inspection to verify the Health IT Module can identify errors in the C-CDA documents not specified in accordance with the standards adopted in § 170.205(a)(3), and § 170.205(a)(4) and § 170.205(a)(6) including:
    • “document –templates”;
    • “section-templates”;
    • “entry-templates”;
    • invalid vocabulary standards;
    • invalid codes.

Error Reporting

  1. Using visual inspection, the tester verifies that errors encountered during the parsing and processing of the C-CDA documents are recorded and that users are either notified of errors encountered OR a mechanism is provided for users to review all of the recorded errors encountered.

System Under Test Test Lab Verification
Expires on January 1, 2026

The user is able to view the processed C-CDA documents in section (b)(1)(ii)(A), in human readable format, including the data which is formatted in accordance to the standards specified in § 170.205(a)(3) or § 170.205(a)(4) and § 170.205(a)(5), and includes, at a minimum, the following content in English (i.e., non-coded) representation if they associate with a vocabulary/code set, as applicable, for the following:

  • All of the data elements as specified in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205 (a)(5);
  • The “Assessment and plan of treatment, in accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4). At a minimum the Assessment and Plan of Treatment data includes the narrative text;
  • Encounter diagnoses;
  • Cognitive status;
  • Functional status;
  • Ambulatory setting only: the following data elements: reason for referral, and referring or transitioning provider's name and office contact information;
  • Inpatient setting only: the discharge instructions.
  • The Goals, in accordance with the “Goals Section” of the standard specified in § 170.205(a)(4). At a minimum the Goals data includes narrative text; and
  • The Health concerns specified in accordance with the standard specified at § 170.205(a)(4). At a minimum the Health concerns data includes narrative text.
Required by December 31, 2025

The user is able to view the processed C-CDA documents in section (b)(1)(ii)(A), in human readable format, including the data which is formatted in accordance to the standards specified in § 170.205(a)(3) or § 170.205(a)(4) and § 170.205(a)(6), and includes, at a minimum, the following content in English (i.e., non-coded) representation if they associate with a vocabulary/code set, as applicable, for the following:

  • All of the data elements as specified in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205 (a)(6);
  • The “Assessment and plan of treatment, in accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4). At a minimum the Assessment and Plan of Treatment data includes the narrative text;
  • Encounter diagnoses;
  • Cognitive status;
  • Functional status;
  • Ambulatory setting only: the following data elements: reason for referral, and referring or transitioning provider's name and office contact information;
  • Inpatient setting only: the discharge instructions.
  • The Goals, in accordance with the “Goals Section” of the standard specified in § 170.205(a)(4). At a minimum the Goals data includes narrative text; and
  • The Health concerns specified in accordance with the standard specified at § 170.205(a)(4). At a minimum the Health concerns data includes narrative text.
Expires on January 1, 2026

Using transition of care/referral summary information retrieved in section (b)(1)(ii)(A) step 1 of the System Under Test, the tester verifies that for each transition of care/referral summaries received in section (b)(1)(ii)(A)(1), section (b)(1)(ii)(A)(3), and section (b)(1)(ii)(A)(4), the transition of care/referral summaries are displayed accurately and are complete. Furthermore, the tester verifies that the data is formatted in accordance with the standards specified in § 170.205(a)(3), § 170.205(a)(4) and § 170.205(a)(5), using visual inspection and includes at a minimum the applicable English (i.e., non-coded) representation if they associate with a vocabulary/code set content for the following data elements):

  • All of the data elements as specified in the in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205(a)(5);
  • Encounter diagnoses;
  • Cognitive status;
  • Functional status;
  • Ambulatory setting only: reason for referral, referring or transitioning provider’s name and office contact information;
  • Inpatient setting only: the discharge instructions;
  • The Goals are specified in accordance with the standard specified in § 170.205(a)(4) as narrative text; and
  • The Health concerns are specified in accordance with the standard specified in § 170.205(a)(4) as narrative text.
Required by December 31, 2025

Using transition of care/referral summary information retrieved in section (b)(1)(ii)(A) step 1 of the System Under Test, the tester verifies that for each transition of care/referral summaries received in section (b)(1)(ii)(A)(1), section (b)(1)(ii)(A)(3), and section (b)(1)(ii)(A)(4), the transition of care/referral summaries are displayed accurately and are complete. Furthermore, the tester verifies that the data is formatted in accordance with the standards specified in § 170.205(a)(3), § 170.205(a)(4) and § 170.205(a)(6), using visual inspection and includes at a minimum the applicable English (i.e., non-coded) representation if they associate with a vocabulary/code set content for the following data elements):

  • All of the data elements as specified in the in the standard at § 170.213 with the data classes expressed in accordance with the implementation guides at § 170.205(a)(4) and § 170.205(a)(6);
  • Encounter diagnoses;
  • Cognitive status;
  • Functional status;
  • Ambulatory setting only: reason for referral, referring or transitioning provider’s name and office contact information;
  • Inpatient setting only: the discharge instructions;
  • The Goals are specified in accordance with the standard specified in § 170.205(a)(4) as narrative text; and
  • The Health concerns are specified in accordance with the standard specified in § 170.205(a)(4) as narrative text.

System Under Test Test Lab Verification
Expires on January 1, 2026

Display Section Views

  1. Using the transition of care/referral summaries received and processed in section (b)(1)(ii)(A), the user displays each individual section (and the accompanying document header information) of the received transition of care/referral summaries displayed in section (b)(1)(ii)(B) formatted according to the standards specified in § 170.205(a)(3) or § 170.205(a)(4) and § 170.205(a)(5).
  2. Using the transition of care/referral summaries received and processed in section (b)(1)(ii)(A), the user displays additional sections (and the accompanying document header information) of the received transition of care/referral summaries displayed in section (b)(1)(ii)(B), formatted according to the standards specified in § 170.205(a)(3), and § 170.205(a)(4) and § 170.205(a)(5).
  3. Using the transition of care/referral summaries received and processed in section (b)(1)(ii)(A), the user can display data from a particular section.

Section Order

  1. The user uses the Health IT Module to set the preference for the display order of specific sections for each of the supported document types.
  2. The user uses the Health IT Module to demonstrate that the sections displayed for the transition of care/referral summaries received and processed in section (b)(1)(ii)(A) are ordered correctly based upon the section order preference set in step 4.

Quantity of Sections

  1. The user uses the Health IT Module to set the initial quantity of sections to be displayed.
  2. The user uses the Health IT Module to demonstrate that the initial number of transition of care/referral summary sections displayed corresponds to the quantity of sections set in step 6.
Required by December 31, 2025

Display Section Views

  1. Using the transition of care/referral summaries received and processed in section (b)(1)(ii)(A), the user displays each individual section (and the accompanying document header information) of the received transition of care/referral summaries displayed in section (b)(1)(ii)(B) formatted according to the standards specified in § 170.205(a)(3) or § 170.205(a)(4) and § 170.205(a)(6).
  2. Using the transition of care/referral summaries received and processed in section (b)(1)(ii)(A), the user displays additional sections (and the accompanying document header information) of the received transition of care/referral summaries displayed in section (b)(1)(ii)(B), formatted according to the standards specified in § 170.205(a)(3), and § 170.205(a)(4) and § 170.205(a)(6).
  3. Using the transition of care/referral summaries received and processed in section (b)(1)(ii)(A), the user can display data from a particular section.

Section Order

  1. The user uses the Health IT Module to set the preference for the display order of specific sections for each of the supported document types.
  2. The user uses the Health IT Module to demonstrate that the sections displayed for the transition of care/referral summaries received and processed in section (b)(1)(ii)(A) are ordered correctly based upon the section order preference set in step 4.

Quantity of Sections

  1. The user uses the Health IT Module to set the initial quantity of sections to be displayed.
  2. The user uses the Health IT Module to demonstrate that the initial number of transition of care/referral summary sections displayed corresponds to the quantity of sections set in step 6.
Expires on January 1, 2026

Display Section Views

  1. Using visual inspection, the tester verifies the transition of care/referral summaries received and processed in section (b)(1)(ii)(A) can accurately and without omission display the data from an individual section and its accompanying document header information.
  2. Using visual inspection, the tester verifies that for the transition of care/referral summaries displayed in step 1 of the System Under Test, the user can select data from an additional individual section or sections to be displayed, along with its accompanying document header information, and that the data is accurate and without omission.
  3. Using visual inspection, the tester verifies data first displayed in step 1, of the System Under Test is for one particular section of the document for each document type.

Section Order

  1. Using visual inspection, the tester verifies the user has the ability to set the order in which the transition of care/referral summary sections are displayed for each of the supported document types.
  2. Using visual inspection, the tester verifies the sections displayed for the transition of care/referral summaries received and processed in section (b)(1)(ii)(A) are ordered correctly based upon the section order set in the previous step (step 4 of the Test Lab Verification). The sections are displayed in the preferred order.

Quantity of Sections

  1. Using visual inspection, the tester verifies the user has the ability to set the initial quantity of sections for a transition of care/referral summary to be displayed.
  2. Using visual inspection, the tester verifies the number of transition of care/referral summary sections initially displayed in step 1, of the System Under Test corresponds to the quantity of sections to be displayed in step 6, of the System Under Test.
Required by December 31, 2025

Display Section Views

  1. Using visual inspection, the tester verifies the transition of care/referral summaries received and processed in section (b)(1)(ii)(A) can accurately and without omission display the data from an individual section and its accompanying document header information.
  2. Using visual inspection, the tester verifies that for the transition of care/referral summaries displayed in step 1 of the System Under Test, the user can select data from an additional individual section or sections to be displayed, along with its accompanying document header information, and that the data is accurate and without omission.
  3. Using visual inspection, the tester verifies data first displayed in step 1, of the System Under Test is for one particular section of the document for each document type.

Section Order

  1. Using visual inspection, the tester verifies the user has the ability to set the order in which the transition of care/referral summary sections are displayed for each of the supported document types.
  2. Using visual inspection, the tester verifies the sections displayed for the transition of care/referral summaries received and processed in section (b)(1)(ii)(A) are ordered correctly based upon the section order set in the previous step (step 4 of the Test Lab Verification). The sections are displayed in the preferred order.

Quantity of Sections

  1. Using visual inspection, the tester verifies the user has the ability to set the initial quantity of sections for a transition of care/referral summary to be displayed.
  2. Using visual inspection, the tester verifies the number of transition of care/referral summary sections initially displayed in step 1, of the System Under Test corresponds to the quantity of sections to be displayed in step 6, of the System Under Test.

System Under Test Test Lab Verification
Expires on January 1, 2026

Data Entry

  1. Based upon the health IT setting, the health IT developer uses the ETT: Message Validators - USCDI v1 R2.1, to download the appropriate ONC-supplied transition of care instruction documents by selecting the "170.315_b1_ToC_Amb" or "170.315_b1_ToC_Inp" criteria, selecting the file name, and executes the download. The user enters the transition of care information downloaded in order to create a patient record with the necessary information.

Create

  1. Using the Health IT Module, the user sends a transition of care document using one of the transport mechanisms specified in section (b)(1)(i)(A) as a C-CDA document, which contains a transition of care/referral summaries, formatted according to the standard adopted in § 170.205(a)(4) and § 170.205(a)(5) in the following formats as applicable:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.
  2. At a minimum, the C-CDA document created in step 2, includes the data elements as expressed in § 170.213 the standard and the following content in accordance with the specified standards at § 170.205(a)(4) and § 170.205(a)(5) as applicable:
    • Assessment and plan of treatment as specified in section (b)(1)(iii)(A)(3)(i);
    • Encounter diagnoses;
    • Goals as specified in section (b)(1)(iii)(A)(3)(ii);
    • Cognitive status;
    • Health concerns as specified in section (b)(1)(iii)(A)(iii);
    • Functional status as specified in section (b)(1)(iii)(D);
    • Ambulatory setting only, the following data elements: as specified in section (b)(1)(iii)(E):
      • The reason for referral; and
      • Referring or transitioning provider’s name and office contact information;
    • Inpatient setting only: the discharge instructions as specified in section (b)(1)(iii)(F); and
    • Patient match data as specified in section (b)(1)(iii)(G).
  3. Based upon the supported health IT setting(s), the user repeats steps 1-3, for each of the ambulatory and/or inpatient transition of care instruction documents found in the ETT: Message Validators. A transition of care document must be sent for every transition of care instruction document for a given health IT setting.
Required by December 31, 2025

Data Entry

  1. Based upon the health IT setting, the health IT developer uses the ETT: Message Validators - USCDI v3 R2.1, to download the appropriate ONC-supplied transition of care instruction documents by selecting the "170.315_b1_ToC_Amb" or "170.315_b1_ToC_Inp" criteria, selecting the file name, and executes the download. The user enters the transition of care information downloaded in order to create a patient record with the necessary information.

Create

  1. Using the Health IT Module, the user sends a transition of care document using one of the transport mechanisms specified in section (b)(1)(i)(A) as a C-CDA document, which contains a transition of care/referral summaries, formatted according to the standard adopted in § 170.205(a)(4) and § 170.205(a)(6) in the following formats as applicable:
    • Continuity of Care;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.
  2. At a minimum, the C-CDA document created in step 2, includes the data elements as expressed in § 170.213 the standard and the following content in accordance with the specified standards at § 170.205(a)(4) and § 170.205(a)(6) as applicable:
    • Assessment and plan of treatment as specified in section (b)(1)(iii)(A)(3)(i);
    • Encounter diagnoses;
    • Goals as specified in section (b)(1)(iii)(A)(3)(ii);
    • Cognitive status;
    • Health concerns as specified in section (b)(1)(iii)(A)(iii);
    • Functional status as specified in section (b)(1)(iii)(D);
    • Ambulatory setting only, the following data elements: as specified in section (b)(1)(iii)(E):
      • The reason for referral; and
      • Referring or transitioning provider’s name and office contact information;
    • Inpatient setting only: the discharge instructions as specified in section (b)(1)(iii)(F); and
    • Patient match data as specified in section (b)(1)(iii)(G).
  3. Based upon the supported health IT setting(s), the user repeats steps 1-3, for each of the ambulatory and/or inpatient transition of care instruction documents found in the ETT: Message Validators. A transition of care document must be sent for every transition of care instruction document for a given health IT setting.
Expires on January 1, 2026

Data Entry

  1. For each transition of care payload sent by the System Under Test, the tester uses the transition of care/referral summary information document downloaded in step 1, of the System Under Test and visual inspection to verify that the transition of care/referral summary record information entered into the Health IT Module is accurate and without omission.

Create

  1. For each transition of care payload sent by the System Under Test via Edge Protocol as specified in section (b)(1)(i)(A), the tester verifies the content of the transition of care/referral summary using the Message Content Report within the ETT. The tester verifies that for each applicable payload no errors exist in the Message Content Report indicating the Health IT Module can successfully create a payload which conforms to the transition of care/referral summary in accordance with the standard specified at § 170.205(a)(4) and § 170.205(a)(5),  and that the document sent is either a CCD document, a Referral Note, or (inpatient setting only) a Discharge Summary.
  2. Using the Message Content Report from the ETT and the transition of care/referral summary instruction documents used to create the payload, the tester uses visual inspection to verify the additional checks for equivalent text for the content of all section level narrative text. The content of each narrative text data element must match the content specified in the transition of care/referral summary instruction document.
  3. Using the Validation Report from the ETT, the tester verifies for each supported health IT setting the following type of transition of care/summary care records have been created by the System Under Test:
    • CCD;
    • C-CDA R2 R2.1 Referral Note Document; and
    • Inpatient setting only: C-CDA R2 R2.1 Discharge Summary.
Required by December 31, 2025

Data Entry

  1. For each transition of care payload sent by the System Under Test, the tester uses the transition of care/referral summary information document downloaded in step 1, of the System Under Test and visual inspection to verify that the transition of care/referral summary record information entered into the Health IT Module is accurate and without omission.

Create

  1. For each transition of care payload sent by the System Under Test via Edge Protocol as specified in section (b)(1)(i)(A), the tester verifies the content of the transition of care/referral summary using the Message Content Report within the ETT. The tester verifies that for each applicable payload no errors exist in the Message Content Report indicating the Health IT Module can successfully create a payload which conforms to the transition of care/referral summary in accordance with the standard specified at § 170.205(a)(4) and § 170.205(a)(6),  and that the document sent is either a CCD document, a Referral Note, or (inpatient setting only) a Discharge Summary.
  2. Using the Message Content Report from the ETT and the transition of care/referral summary instruction documents used to create the payload, the tester uses visual inspection to verify the additional checks for equivalent text for the content of all section level narrative text. The content of each narrative text data element must match the content specified in the transition of care/referral summary instruction document.
  3. Using the Validation Report from the ETT, the tester verifies for each supported health IT setting the following type of transition of care/summary care records have been created by the System Under Test:
    • CCD;
    • C-CDA R2 R2.1 Referral Note Document; and
    • Inpatient setting only: C-CDA R2 R2.1 Discharge Summary.

System Under Test Test Lab Verification
Expires on January 1, 2026

The Data Set Requirements

  1. At a minimum, the transition of care/referral summaries contain the data elements specified in the standard in § 170.213 and are expressed in accordance with the implementation specifications at § 170.205(a)(4) and § 170.205(a)(5).

Assessment and Plan of Treatment

  1. The content of the transition of care/referral summaries created in section (b)(1)(iii) contains either the Assessment and Plan Section (V2), or both the Assessment and Plan of Treatment Sections (V2), specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(5). At a minimum the Assessment and Plan of Treatment data includes the narrative text.

Note that the system does not have to represent the assessment and plan of treatment using the C-CDA’s syntax. The system must consistently and independently represent the assessment and plan of treatment as discrete data that are clearly distinguishable.

Goals

  1. The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Goals specified in accordance with the standard specified at § 170.205(a)(4) and § 170.205(a)(5). At a minimum the Goals data includes narrative text.

Note that the system does not have to represent the Goals using the C-CDA’s syntax. The system must consistently and independently represent the Goals as discrete data that are clearly distinguishable.

Health Concerns

  1. The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Health concerns specified in accordance with the standard specified at § 170.205(a)(4) and § 170.205(a)(5). At a minimum the Health concerns data includes narrative text.

Note that the system does not have to represent the Health Concerns using the C-CDA’s syntax. The system must consistently and independently represent the Health Concerns as discrete data that are clearly distinguishable.

Required by December 31, 2025

The Data Set Requirements

  1. At a minimum, the transition of care/referral summaries contain the data elements specified in the standard in § 170.213 and are expressed in accordance with the implementation specifications at § 170.205(a)(4) and § 170.205(a)(6).

Assessment and Plan of Treatment

  1. The content of the transition of care/referral summaries created in section (b)(1)(iii) contains either the Assessment and Plan Section (V2), or both the Assessment and Plan of Treatment Sections (V2), specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(6). At a minimum the Assessment and Plan of Treatment data includes the narrative text.

Note that the system does not have to represent the assessment and plan of treatment using the C-CDA’s syntax. The system must consistently and independently represent the assessment and plan of treatment as discrete data that are clearly distinguishable.

Goals

  1. The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Goals specified in accordance with the standard specified at § 170.205(a)(4) and § 170.205(a)(6). At a minimum the Goals data includes narrative text.

Note that the system does not have to represent the Goals using the C-CDA’s syntax. The system must consistently and independently represent the Goals as discrete data that are clearly distinguishable.

Health Concerns

  1. The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Health concerns specified in accordance with the standard specified at § 170.205(a)(4) and § 170.205(a)(6). At a minimum the Health concerns data includes narrative text.

Note that the system does not have to represent the Health Concerns using the C-CDA’s syntax. The system must consistently and independently represent the Health Concerns as discrete data that are clearly distinguishable.

Expires on January 1, 2026

The Data Set Requirements

  1. The verification that the Data Element Set content is in accordance with the standards specified in § 170.213 Reference Document for a document specified in accordance with § 170.205(a)(4) and § 170.205(a)(5) is performed as part of the verification done in section (b)(1)(iii) steps 2-3 of the Test Lab Verification.

Assessment and Plan of Treatment

  1. The tester verifies that the Assessment and Plan or both the Assessment and Plan of Treatment are specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(5) as narrative text.

Note that the system does not have to represent the assessment and plan of treatment using the C-CDA’s syntax. The system must consistently and independently represent the assessment and plan of treatment as discrete data that are clearly distinguishable.

Goals

  1. The tester verifies that the Goals are specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(5) as narrative text.

Note that the system does not have to represent the Goals using the C-CDA’s syntax. The system must consistently and independently represent the Goals as discrete data that are clearly distinguishable.

Health Concerns

  1. The tester verifies the Health Concerns are specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(5) as narrative text.

Note that the system does not have to represent the Health Concerns using the C-CDA’s syntax. The system must consistently and independently represent the Health Concerns as discrete data that are clearly distinguishable.

Required by December 31, 2025

The Data Set Requirements

  1. The verification that the Data Element Set content is in accordance with the standards specified in § 170.213 Reference Document for a document specified in accordance with § 170.205(a)(4) and § 170.205(a)(6) is performed as part of the verification done in section (b)(1)(iii) steps 2-3 of the Test Lab Verification.

Assessment and Plan of Treatment

  1. The tester verifies that the Assessment and Plan or both the Assessment and Plan of Treatment are specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(6) as narrative text.

Note that the system does not have to represent the assessment and plan of treatment using the C-CDA’s syntax. The system must consistently and independently represent the assessment and plan of treatment as discrete data that are clearly distinguishable.

Goals

  1. The tester verifies that the Goals are specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(6) as narrative text.

Note that the system does not have to represent the Goals using the C-CDA’s syntax. The system must consistently and independently represent the Goals as discrete data that are clearly distinguishable.

Health Concerns

  1. The tester verifies the Health Concerns are specified in accordance with the standard specified in § 170.205(a)(4) and § 170.205(a)(6) as narrative text.

Note that the system does not have to represent the Health Concerns using the C-CDA’s syntax. The system must consistently and independently represent the Health Concerns as discrete data that are clearly distinguishable.


System Under Test Test Lab Verification
Expires on January 1, 2026

Encounter Diagnoses

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Encounter diagnoses using at least one standard, either:

  • the standard specified at § 170.207(i) ICD-10-CM for the following conditions:
    • Diseases;
    • Injuries;
    • Impairments;
    • Other health problems and their manifestations;
    • Causes of injury, disease, impairment, or other health problems.
  • or at a minimum the version of the standard specified at § 170.207(a)(4) SNOMED CT®.
Required by December 31, 2025

Encounter Diagnoses

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Encounter diagnoses using at least one standard, either:

  • the standard specified at § 170.207(i) ICD-10-CM for the following conditions:
    • Diseases;
    • Injuries;
    • Impairments;
    • Other health problems and their manifestations;
    • Causes of injury, disease, impairment, or other health problems.
  • or at a minimum the version of the standard specified at § 170.207(a)(1) SNOMED CT®.
Expires on January 1, 2026

Encounter Diagnoses

The verification that the Encounter diagnoses content is specified in accordance with the constrained standard specified at § 170.207(i) or at a minimum the version of the standard specified at § 170.207(a)(4) is performed as part of the verification done in section (b)(1)(iii) steps 2-3, of the Test Lab Verification.

Required by December 31, 2025

Encounter Diagnoses

The verification that the Encounter diagnoses content is specified in accordance with the constrained standard specified at § 170.207(i) or at a minimum the version of the standard specified at § 170.207(a)(1) is performed as part of the verification done in section (b)(1)(iii) steps 2-3, of the Test Lab Verification.


System Under Test Test Lab Verification

Cognitive Status

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Cognitive status when present. Cognitive Status is included in the Mental Status section and represented in both machine readable and human readable format.

Cognitive Status

The verification of the Cognitive status content of the transition of care/referral summaries is performed as part of the verification done in section (b)(1)(iii).


System Under Test Test Lab Verification

Functional Status

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the Functional Status when present. Functional Status is included in the Functional Status section. 

Functional Status

The verification of the Functional Status content of the transition of care/referral summaries is performed as part of the verification done in section (b)(1)(iii).


System Under Test Test Lab Verification

Ambulatory Setting Only

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the reason for referral, referring or transitioning provider’s name, and office contact information.

Ambulatory Setting Only

The verification of the data element requirements for the ambulatory setting within a transition of care/referral summaries is performed as part of the verification done in section (b)(1)(iii). This includes verifying that the transition of care/referral summaries record includes the referring or transitioning provider’s name and office contact information. Additional verification is done in section (b)(1)(ii) step 3, of the Test Lab Verification to verify the unstructured text data element Reason for Referral.


System Under Test Test Lab Verification

Inpatient Setting Only

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the discharge instructions.

Inpatient Setting Only

The verification of the required discharge instructions content for the inpatient setting within a transition of care/referral summaries is performed as part of the verification done in section (b)(1)(iii) step 3, of the Test Lab Verification.


System Under Test Test Lab Verification
Expires on January 1, 2026

Patient Matching Data

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the following patient matching data:

  • Full name including first name, last name, previous name, middle name (including middle initial), and suffix;
  • Date of birth including the year, month, and day when known and null when unknown;
  • Current address;
  • Phone number(s) which are constrained in accordance with the standard specified at § 170.207(q)(1) ITU-T E.123 and ITU-T E.164, and if multiple phone numbers are present within the Health IT Module they are reflected in the transition of care/referral summaries; and
  • Birth sex which is constrained in accordance with the standard specified at § 170.207(n)(1) Birth sex coded in accordance with HL7® Version 3, Value Sets for AdministrativeGender and NullFlavor attributed as follows:
    1. Male. M
    2. Female. F
    3. Unknown. nullFlavor UNK
Required by December 31, 2025

Patient Matching Data

The content of the transition of care/referral summaries created in section (b)(1)(iii) contains the following patient matching data:

  • Full name including first name, last name, previous name, middle name (including middle initial), and suffix;
  • Date of birth including the year, month, and day when known and null when unknown;
  • Current address;
  • Phone number(s) which are constrained in accordance with the standard specified at § 170.207(q)(1) ITU-T E.123 and ITU-T E.164, and if multiple phone numbers are present within the Health IT Module they are reflected in the transition of care/referral summaries; and
  • Represent sex in accordance with the standard adopted in § 170.207(n)(2) Sex must be coded in accordance with, at a minimum, the version of SNOMED CT ® U.S. Edition codes specified in § 170.207(a)(1).
Expires on January 1, 2026

Patient Matching Data

The verification of the patient matching data within the transition of care/referral summaries created in section (b)(1)(iii) includes the following checks:

  • Presence of the patient’s first name, last name, previous name, middle name (including middle initial), suffix;
  • Date of birth;
  • Current address;
  • All phone number(s) present in the Health IT Module and sex, as applicable. Furthermore, the phone number(s) are constrained in accordance with the standard specified at § 170.207(q)(1) and;
  • The birth sex is in accordance with the standard adopted in § 170.207(n)(1).
Required by December 31, 2025

Patient Matching Data

The verification of the patient matching data within the transition of care/referral summaries created in section (b)(1)(iii) includes the following checks:

  • Presence of the patient’s first name, last name, previous name, middle name (including middle initial), suffix;
  • Date of birth;
  • Current address;
  • All phone number(s) present in the Health IT Module and sex, as applicable. Furthermore, the phone number(s) are constrained in accordance with the standard specified at § 170.207(q)(1) and;
  • Sex which is in accordance with the standard specified at § 170.207(n)(2).

System Under Test Test Lab Verification

Birth with Time

If the time of birth (hours, minutes, and seconds) is included the correct time zone offset is used.

Birth with Time

If the Health IT Module supports the time of birth, the tester verifies that the Health IT Module can demonstrate the correct time zone offset as part of the time of birth.


Updated on 03-11-2024
Regulation Text
Regulation Text

§ 170.315 (b)(1) Transition of care

  1. Send and receive via edge protocol—
    1. Send transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in § 170.202(a); and
    2. Receive transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) from a service that has implemented the standard specified in § 170.202(a)(2).
    3. XDM processing. Receive and make available the contents of a XDM package formatted in accordance with the standard adopted in § 170.205(p)(1) when the technology is also being certified using an SMTP-based edge protocol.
  2. Validate and display —
    1. Validate C-CDA conformance – system performance. Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standards specified in § 170.205(a)(3), (4), and (5) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:
      1. Parse each of the document types.
      2. Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(3), (4), and (5).
      3. Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(3), (4), and (5).
      4. Correctly interpret empty sections and null combinations.
      5. Record errors encountered and allow a user through at least one of the following ways to:
        1. Be notified of the errors produced.
        2. Review the errors produced.
    2. Display. Display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in § 170.205(a)(3), (4), and (5).
    3. Display section views. Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in § 170.205(a)(3), (4), and (5) in a manner that enables the user to:
      1. Directly display only the data within a particular section;
      2. Set a preference for the display order of specific sections; and
      3. Set the initial quantity of sections to be displayed.
  3. Create. Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in § 170.205(a)(3), (4), and (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:
    1.  
      1. The data classes expressed in the standard in § 170.213 and in accordance with § 170.205(a)(4), (a)(5), and paragraphs (b)(1)(iii)(A)(3)(i) through (iii) of this section, for the time period up to and including December 31, 2025, or
      2. The data classes expressed in the standards in § 170.213 and in accordance with § 170.205(a)(4), (6), and paragraphs (b)(1)(iii)(A)(3)(i) through (iii) of this section, and 
      3. The following data classes:
        1. Assessment and plan of treatment. In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).
        2. Goals. In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
        3. Health concerns. In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
        4. Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).
    2. Encounter diagnoses. Formatted according to at least one of the following standards:
      1. The standard specified in § 170.207(i).
      2. At a minimum, the version of the standard specified in § 170.207(a)(1).
    3. Cognitive status.
    4. Functional status.
    5. Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.
    6. Inpatient setting only. Discharge instructions.
    7. Patient matching data. First name, last name, previous name, middle name (including middle initial), suffix, date of birth, current address, phone number, and sex. The following constraints apply:
      1. Date of birth constraint.
        1. The year, month and day of birth must be present for a date of birth. The technology must include a null value when the date of birth is unknown.
        2. Optional. When the hour, minute, and second are associated with a date of birth the technology must demonstrate that the correct time zone offset is included.
      2. Phone number constraint. Represent phone number (home, business, cell) in accordance with the standards adopted in § 170.207(q)(1). All phone numbers must be included when multiple phone numbers are present.
      3. Sex constraint. Represent sex in accordance with the standard adopted in § 170.207(n)(1) up to and including December 31, 2025; or with the standard adopted in § 170.207(n)(2).
Standard(s) Referenced

Paragraphs (b)(1)(i)(A) and (B)

§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2 August 2015

§ 170.202(d) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014

Paragraph (b)(1)(i)(C)

§ 170.205(p)(1) IHE IT Infrastructure Technical Framework Volume 2b (ITI TF- 2b)

Paragraph (b)(1)(ii)

§ 170.205(a)(3) Health Level 7 (HL7®) Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use July 2012

§ 170.205(a)(4)  HL7® Implementation Guide for CDA Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1, August 2015, June 2019 (with Errata)

§ 170.205(a)(5) HL7® CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2, October 2019, IBR approved for § 170.205(a)(5). (Adoption of this standard expires on January 1, 2026)

§ 170.205(a)(6) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 - US Realm (This standard is required by December 31, 2025)

Paragraphs (b)(1)(iii)(A)-(F)

§ 170.213(a) United States Core Data for Interoperability (USCDI) July 2020 Errata, Version 1 (v1) (Adoption of this standard expires on January 1, 2026)

§ 170.213(b) United States Core Data for Interoperability (USCDI), October 2022 Errata, Version 3 (v3) (This standard is required by December 31, 2025)

§ 170.205(a)(3) HL7® Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use July 2012

§ 170.205(a)(4)  HL7® Implementation Guide for CDA Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1 with Errata, August 2015, June 2019 (with Errata)

§ 170.205(a)(5) HL7® CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2, October 2019, IBR approved for § 170.205(a)(5). (Adoption of this standard expires on January 1, 2026)

§ 170.205(a)(6) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 - US Realm (This standard is required by December 31, 2025)

§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT® ) U.S. Edition, September 2019 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)

§ 170.207(i) Encounter diagnoses: The code set specified at 45 CFR 162.1002(c)(2) for the indicated conditions ICD-10-CM as maintained and distributed by the Department of Health and Human Services (HHS), for the following conditions:

  1. Diseases.
  2. Injuries.
  3. Impairments.
  4. Other health problems and their manifestations.
  5. Causes of injury, disease, impairment, or other health problems.

Paragraph (b)(1)(iii)(G)

§ 170.205(a)(4) HL7® Implementation Guide for CDA® Release 2 Consolidation CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1 C-CDA 2.1, August 2015, June 2019 (with Errata)

§ 170.205(a)(5) HL7® CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2, October 2019, IBR approved for § 170.205(a)(5). (Adoption of this standard expires on January 1, 2026)

§ 170.205(a)(6) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 - US Realm (This standard is required by December 31, 2025)

§ 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows:

  1. Male. M
  2. Female. F
  3. Unknown. nullFlavor UNK (Adoption of this standard expires on January 1, 2026)

§ 170.207(n)(2) Sex must be coded in accordance with, at a minimum, the version of SNOMED CT® U.S. Edition codes specified in § 170.207(a)(1). (This standard is required by December 31, 2025)

§ 170.207(q)(1) International Telecommunication Union E.123: Notation for national and international telephone numbers, e-mail addresses and web addresses and International Telecommunication Union E.164: The international public telecommunication numbering plan

Standards Version Advancement Process (SVAP) Version(s) Approved 

§ 170.202(a)(2) Applicability Statement for Secure Health Transport Version 1.3, May 2021 (Direct)

For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.

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 standards and minimum standard code sets outlined in paragraphs (b)(1)(ii) and (b)(1)(iii)(A)-(F). Developers must add functionality certified to the standards referenced in paragraphs (b)(1)(iii)(A)-(F).

Certification Dependencies

Conditions and Maintenance of Certification Requirements

Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.

Design and Performance Requirements: 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, when different QMS are used, each QMS needs to be separately 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.
  • Consolidated CDA creation performance (§ 170.315(g)(6)) does not need to be explicitly tested with this criterion unless it is the only criterion within the scope of the requested certification that includes C-CDA creation capabilities. Note that the application of § 170.315(g)(6) depends on the C-CDA templates explicitly required by the C-CDA-referenced criterion or criteria included within the scope of the certificate sought. Please refer to the C-CDA creation performance CCG for more details.
Privacy & Security Requirements

Privacy and Security: This certification criterion was adopted at § 170.315(b)(1). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(b) 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 tested 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.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Revision History
Version # Description of Change Version Date
1.0

Initial publication

03-11-2024
Testing
Testing Tool

 

Edge Testing Tool (ETT): Message Validators and Edge Testing

Testing must be conducted for one of the Sending Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion.
Testing must also be conducted for one of the alternative connection requirements within each of the Sending Alternatives.
Note: The “Secure Network” alternative only needs to be verified once for the Testing Procedure. (Where applicable the TLS required should be unchecked in the ETT Profile).

Testing must be conducted for one of the Receiving Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion: IHE XDR, SMTP, IMAP, or POP3.

 

Test Tool Documentation

Test Tool Supplemental Guide

 

 

Criterion Subparagraph Test Data
(b)(1)(ii)(A)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Outpatient setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

Test Data (Payload):

Inpatient setting 170.315_b1_toc_inp_*_r11_sample*.xml
170.315_b1_toc_inp_*_r21_sample*.xml

Outpatient setting 170.315_b1_toc_amb_*_r11_sample*.xml
170.315_b1_toc_amb_*_r21_sample*.xml

Negative Tests: NT_*_r11*.xml
NT_*_r21*.xml

(b)(1)(ii)(B)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Ambulatory setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

(b)(1)(ii)(C)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Ambulatory setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

(b)(1)(iii)

Inpatient setting 170.315_b1_toc_inp_sample*.pdf (All Samples)

Ambulatory setting 170.315_b1_toc_amb_sample*.pdf (All Samples)

Certification Companion Guide: Transitions of care

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 Program Regulations page for links to all 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.

 

Certification Requirements
Technical Explanations and Clarifications

Clarifications:

  • The scope of this criterion is limited to the Consolidated CDA (C-CDA) Continuity of Care Document (CCD), Referral Note, and (inpatient setting only) Discharge Summary document templates. [see also 80 FR 62633]
  • In combination with the C-CDA R2.1 standard, developers certifying to the USCDI must follow the guidance and templates provided in the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 until December 31, 2025, deadline; or HL7® CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 4.1, for implementation of the C-CDA Release 2.1 standard. For example, details on how to structure and exchange Clinical Notes are included in the C-CDA Companion Guide.
  • In order to mitigate potential interoperability errors and inconsistent implementation of the HL7® Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, Draft Standard for Trial Use, Release 2.1, ONC assesses, approves, and incorporates corrections (Errata) as part of required testing and certification to this criterion. [see ONC Health IT Certification Program Overview] Certified health IT adoption and compliance with the following corrections are necessary because they implement updates to vocabularies, update rules for cardinality and conformance statements, and promote proper exchange of C-CDA documents. There is a 90-day delay from the time the CCG has been updated with the ONC-approved corrections to when compliance with the corrections will be required to pass testing (i.e., ETT Message Validators). Similarly, there will be an 18-month delay before a finding of a correction’s absence in certified health IT during surveillance would constitute a non-conformity under the Certification Program.

Technical outcome – The health IT can send and receive transition of care (ToC)/referral summaries using one of the four edge protocols in the ONC Implementation Guide for Direct Edge Protocols.

Clarifications:

  • For the purpose of sending ToC/referral summaries, a Health IT Module must demonstrate compliance with either the IHE XDR protocol or SMTP protocol. [see also 80 FR 62680]
  • For the purpose of receiving ToC/referral summaries, a Health IT Module must demonstrate compliance with one of the following standards: IHE XDR, SMTP, POP3 and IMAP4. [see also 80 FR 62680]
  • Certification to this criterion requires the exchange to take place using either TLS/SASL or a “secure network”. A “secure network” is generally recognized as one where all the nodes (endpoints) are known, uniquely identified, access controlled, with strong end-to-end encryption. For example, a virtual private network (VPN) or a network physically isolated from any other with specialized equipment using endpoint encryption.
  • The protocols listed in the Implementation Guide, section 1.3.1 explicitly list conformance to RFC 3501. The RFC, when originally published, mandated using the TLS_RSA_WITH_RC4_128_MD5 cipher suite within the TLS 1.0 bundle. RFC 3501 has had subsequent updates making the listed cipher suite obsolete and rescinded within the TLS 1.0 bundle. Current industry practice is to implement cipher suites that are compliant with TLS 1.1 (shall), TLS 1.2 (should), and TLS 1.0 (may).

Technical outcome – If the Health IT Module is certified to an SMTP-based edge protocol, the health IT must be able to receive and make available the contents of an XDM package that was created in accordance with the IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b).

Clarifications:

  • POP3 and IMAP4 are “SMTP-based” edge protocols for the purposes of receiving ToC/referral summaries. Thus, use of either will require a Health IT Module to demonstrate the requirements specified by this specific capability in the certification criterion. [see also 80 FR 62635]
  • Health IT Modules should adhere to metadata requirements from the IHE Data Access Framework Document Metadata Based Access IG as included in the ONC XDR and XDM for Direct Messaging Specification. [see also 80 FR 62635]
  • Health IT Modules are expected to support all commonly used Multi-Purpose Internet Mail Extension (MIME) types when receiving C-CDA and XDM packages. These MIME types will be specified in the test procedure. [see also 80 FR 62635]

Technical outcome – The health IT can detect valid and invalid ToC/referral summaries upon receipt of C-CDA documents formatted to C-CDA Release 1.1 and 2.1.

Clarifications:

  • ONC requires Health IT Modules to be able to receive and validate C-CDAs formatted to both C-CDA Release 1.1 and 2.1. While Release 2.1 largely ensures compatibility between C-CDA Release 1.1 and 2.0, it does not guarantee compatibility without further development effort. [see also 80 FR 62634]
  • Developers have the discretion to exercise C-CDA validation in production, but certification will only require that the Health IT Module be able to detect valid and invalid ToC/referral summaries during testing. ONC strongly recommends developers consider how the Health IT Module will handle validation failures in production during the development of the technology, but it is not required for certification.
  • Testing for the receipt of C-CDA Release 1.1 documents will offer two options – to test either a non-specified C-CDA document or a CCD. Note that Health IT Modules will be tested for receipt of all three document templates (i.e., CCD, Referral Note, and (inpatient setting only) Discharge Summary) for C-CDA Release 2.1.
  • Error notification should be made available to authorized users of the receiving organization who can deal with the errors as appropriate and the error may be resolved by a support analyst or end user. [see also 80 FR 62634]
  • There is no requirement that users be interrupted to be notified of errors, only that the user can access and review the errors. [see also 80 FR 62634]
  • Receiving systems are not expected to translate codes from a source that has not formatted the data according to the applicable vocabulary standard required by the C-CDA Releases 1.1 and 2.1. [see also 77 FR 54220] However, receiving systems would be expected to identify data not formatted according to the applicable vocabulary standard as an error.

Technical outcome – The health IT can display, for both C-CDA Releases 1.1 and 2.1, a human-readable C-CDA to a user.

Clarifications:

  • No additional clarifications.

Technical outcome – The health IT allows a user to choose to display only the data within a particular C-CDA section, set a preference for the section display order, and set the initial number of sections to be displayed. This applies to both C-CDA Releases 1.1 and 2.1.

Clarifications:

  • The use of the C-CDA CDA XSL style sheet will not be sufficient to meet the requirements of this provision. [see also 80 FR 62634]

Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes the USCDI, Encounter diagnoses according to either ICD-10-CM or SNOMED CT® codes, Cognitive status, and Functional status.

  • Ambulatory setting only – The user is able to create a C-CDA Release 2.1 that also includes the reason for referral, and the referring or transitioning provider’s name and office contact information.
  • Inpatient setting only – The user is able to create a C-CDA Release 2.1 Discharge Summary Document that also includes the discharge instructions.

Clarifications:

  • In order to facilitate the translation of SNOMED CT® codes to ICD-10-CM in administrative systems, developers are encouraged to reference the publicly available mapping that the National Library of Medicine provides. [see also 77 FR 54220]
  • ONC provides the following object identifiers (OIDs) to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards:
    • ICD-10-CM OID: 2.16.840.1.113883.6.90
    • SNOMED CT® OID: 2.16.840.1.113883.6.96 [see also 80 FR 62612]
  • Health IT Modules can present for certification to a more recent version of SNOMED CT®, U.S. Edition than specified by the USCDI per ONC’s policy that permits certification to a more recent version of certain vocabulary standards. [see also 80 FR 62620]
  • The C-CDA Cognitive Status Observation template was deprecated in Release 2.1 and replaced with the Mental Status Observation template. Developers should use the Mental Status Observation template for cognitive status and be aware that the C-CDA Validator will issue an error if the deprecated Cognitive Status Observation template is used instead.

Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes certain data to assist with patient matching. Unless otherwise specified, the developer should follow the guidance in C-CDA Release 2.1 for formatting the data.

Clarifications:

  • These requirements concern only the ability to create a ToC/referral summary document that contains the data elements in accordance with the specified standards/constraints. The health IT is not required to demonstrate how it performs patient matching with these data for certification. [see also 80 FR 62637]
  • C-CDA Release 2.1 allows suffix to be included as an additional qualifier to the last name field. [see also 80 FR 62636]
  • ONC recommends receiving systems follow the guidance in CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 for normalizing last name before sending ToC/referral summary documents. [see also 80 FR 62636]
  • “Previous name” is intended to capture situations where a patient may use an alias (e.g., maiden name, family name, legally changed last name). [see also 80 FR 62636]
  • The C-CDA validation tool will test adherence to the use of the HL7® postal format for address. [see also 80 FR 62637]