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

§170.315(b)(1) Transitions of care

Version 2.3 Updated on 04-06-2018
Revision History
Version # Description of Change Version Date
1.0

Final Test Procedure

01-29-2016
1.1

Paragraph (b)(1)(i)(A) removed the reference to the actual number of messages (3) sent.

Removed email addresses throughout test procedure.

Paragraph (b)(1)(i)(A) updated language within note related to payload testing.

Removed reference to IMAP and POP test 22.

03-21-2016
1.2

Removed references to "processed MDNs".

04-12-2016
1.3

Divided XDR Message Tracking and Delivery Notification valid and invalid recipient testing into 2 steps. Paragraph (b)(1)(i)(B)(Alternative) Removed SMTP Test 12 – non-testable scenario.

Paragraph (b)(1)(iii) updated language and references to the Message Content Report in the Test Lab Verification items 2 and 3. Removed references to Endpoints that are not enumerated in the Edge Testing Tool.

06-15-2016
1.4

Deprecated the Transport Testing Tool.

Changed IMAP and POP3 from "Optional" receive protocols to "Alternative" receive protocols.

07-29-2016
1.5

Updated XDR Test 5 to reflect the payload content of the receipt of a single XDR message with full Metadata (per ETT Tool update).

Modified XDR MT Tests 20a and 20b to reflect the verification the processing of the Delivery Status Notification (DSN) (per ETT Tool update).

Divided XDR MT Test 50 into XDR MT Test 50a and XDR MT Test 50b, one for valid and one for invalid recipients (per ETT Tool update).

09-01-2016
1.6

(b)(1)(i)(A)(Alternative) Message Tracking and Delivery Notification SUT steps 8 through 11 workflow navigation were improved.

(b)(1)(i)(C) – XDM Processing (Received via Edge Protocol) SUT step 2 workflow navigation was improved.

11-07-2016
1.7

Removed note regarding send payload from page 4.

Added IMAP tests 29a & 29b, POP tests 29a & 29b to be consistent with SMTP Tests 26a & 26b.

01-27-2017
1.8

Removed SMTP MT Test 45 as redundant.

03-06-2017
1.9

Reformatted the transport test steps for readability. The System Under Test aligns closer to the to the Test Lab Verification columns.

  • Several numbering and narrative formatting changes.
  • Test numbering included on both the SUT and TLV sides.

Addition of alternative SUT Connection – Systems may not be connected using TLS and SASL or a “secure network”. Additional updates were made to indicate which tests were required only for the TLS and SASL alternative throughout the test procedure (see updated test case decoupling below). As part of this update, the ordering of the test steps were altered to make them consistent throughout the test procedure.

Updates to Test Procedure were made to reflect decoupling of the TSL and SASL from the send/receive test cases corresponding to the changes made in the Edge Testing Tool (ETT). This includes the following changes:

  • SMTP Test (1-8, 14) included TLS, SASL, and SMTP Send. The new test cases are SMTP Test 8 STARTTLS, SMTP Test 14 SASL, and SMTP Test 18 SMTP Send.
  • SMTP Test (9, 16, 20) included TLS, SASL and SMTP Receive. The new test cases are SMTP Test 9 STARTTLS, SMTP Test 16 SASL, and SMTP Test 20 SMTP Receive.
  • IMAP Test (19, 20, 24) included TLS, SASL and IMAP Receive. The new test cases are IMAP Test 19 STARTTLS, IMAP Test 20 SASL, and IMAP Test 20 IMAP Receive (new test step).
  • POP Test (19, 20, 24) included TLS, SASL and IMAP Receive. The new test cases are POP Test 19 STARTTLS, POP Test 20 SASL, and IMAP Test 20 POP Receive (new test step).

Removed the following test cases to reduce the burden of Edge Testing: XDR MT Test 19, XDR MT Test 48, XDR MT Test 50a and 50b, SMTP MT Test 17, SMTP MT Test 18, SMTP Test 47 and Test 47a, SMTP Test 10, SMTP Test 11, SMTP Test 13.

Removed Negative connection test steps SMTP Test 22, documentation of negative authentication due to an invalid DIGEST-MD5 value.

Updated the link to the Edge Testing Tool (ETT).

04-24-2017
2.0

Fixed some minor typos, including the link between SUT and TLV step 7 for (b)(1)(i)(B) (Alternative) – Receive Using Edge Protocol for SMTP.

Corrected link to 170.205(a)(3) HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1.

Removed the use of an explicit cipher suite (TLS_RSA_WITH_RC4_128_MD5, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) to account for updates in the Standards. Added the references to RFC 2246, NIST Special Publication 800-52 Rev 1 and RFC 7465.

Corrected the expected behavior for SMTP Test 26(a) and 26(b)-CCDA documents with style sheet issues.

07-07-2017
2.1

Clarification of the types of XDM package attachments that must be verified in paragraph (b)(1)(i)(C) – XDM Processing (Received via Edge Protocol).

Wording clarification in paragraph (b)(1)(i)(B) – Receive Using Edge Protocol for SMTP Step 3 (establish and not initiate). Our regulation is only concerned that a TLS connection can be established. It can be a 1-way TLS or a 2-way.

10-27-2017
2.2

Added an “or” on step 4 under the SUT of paragraph (b)(1)(i)(B) – Receive Using Edge Protocol for IHE XDR profile for Limited Metadata Document Sources.

For paragraph (b)(1)(i)(B) – Receive Using Edge Protocol for SMTP, updated step number from 10 to 6 within step 6 under the TLV; updated step number from 13 to 9 within step 9 under the TLV; updated step number from 14 to 10 within step 10 under the TLV.

Updated “C-CA documents” to “C-CDA documents” on step 7 under the TLV of paragraph (b)(1)(i)(B) – Receive Using Edge Protocol for POP3.

Added an “or” on step 1 under the TLV of paragraph (b)(1)(ii)(A).

Clarified reference step number is from the SUT on the step under the TLV of paragraph (b)(1)(ii)(B).

For paragraph (b)(1)(ii)(C), added language to specify that sections for each supported document type needs to be set on step 4 under the SUT; updated step number from 5 to 4 within step 5 under the TLV; updated step number from 7 to 6 within step number 7 under the SUT; clarified referenced step numbers are from the SUT for steps 2, 3, 5, and 7 under the TLV; updated step number from 5 to 4 within step 5 under the TLV; updated step number from 7 to 6 within step 7 under the TLV.

For paragraph (b)(1)(iii), added an “or” on step 1 under the SUT; updated step number from 1-4 to 1-3 within step number 4 under the SUT.

Clarified referenced step numbers are from the TLV under the TLV for paragraphs (b)(1)(iii)(A), (b)(1)(iii)(B), (b)(1)(iii)(E), and (b)(1)(iii)(F).

Updated step number from 2-3 to 3 under the TLV of paragraph (b)(1)(iii)(F).

Updated the subparagraph number from (iii)(G)(1)(i) (Optional) to (iii)(G)(1)(ii) (Optional) to match the regulation text.

02-22-2018
2.3

Addition of Conditional status to paragraph (b)(1)(i)(C) XDM processing test step as it is only relevant for Health IT Modules using SMTP protocols.

04-06-2018
Regulation Text
Regulation Text

§170.315 (b)(1) Transitions 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) and § 170.205(a)(4) 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) and § 170.205(a)(4).
      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) and § 170.205(a)(4).
      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) and § 170.205(a)(4).
    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) and § 170.205(a)(4) 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)(4) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:.
    1. The Common Clinical Data Set.
    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)(4).
    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, 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).
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) 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: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1, August 2015

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

§ 170.207(a)(4) International Health Terminology Standards Development Organization (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT® ) U.S. Edition, September 2015 Release

§ 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 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.

Please refer to the Data Elements and Vocabularies applicable to the Common Clinical Data Set (CCDS) as outlined in the Common Clinical Data Set Reference Document

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

§ 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1, August 2015

§ 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

§ 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

 

Additional Resources

§ 170.207(a)(3) International Health Terminology Standards Development Organization (IHTSDO)  Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) International Release July 31, 2012 and US Extension to SNOMED CT® March 2012

Please consult the Final Rule entitled: 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications for a detailed description of the certification criterion with which these testing steps are associated. We also encourage developers to consult the Certification Companion Guide in tandem with the test procedure as they provide clarifications that may be useful for product development and testing.

Note: The order in which the test steps are listed reflects the sequence of the certification criterion and does not necessarily prescribe the order in which the test should take place.
 

Testing components

No GAP Icon Documentation Icon Visual Inspection Icon Test Tool Icon ONC Supplied Test Data 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 ETT Profile).

 

Paragraph (b)(1)(i)(A) (Alternative) – Send Using Edge Protocol for IHE XDR profile for Limited Metadata Document Sources

System Under Test Test Lab Verification

SUT Connection – Using TLS and SASL

  1. Using the Edge Testing Tool “XDR Cases” with “System as Sender” 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).

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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) 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).

SUT 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).

SUT 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.

Paragraph (b)(1)(i)(A) (Alternative) – Send Using Edge Protocol for SMTP

System Under Test Test Lab Verification

SUT Connection – TLS and SASL

  1. Using the Edge Testing Tool “SMTP Tests”, “System as Sender” 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 user name 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.

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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 (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 Continuity of Care Document (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 ONC Implementation Guide for Delivery Notification in Direct v1.0 (SMTP MT Test 46).

SUT 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.

SUT 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 ONC Implementation Guide for Delivery Notification in Direct v1.0 (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).

 

Paragraph (b)(1)(i)(B) (Alternative) – Receive Using Edge Protocol for IHE XDR profile for Limited Metadata Document Sources

System Under Test Test Lab Verification

SUT Connection – Using TLS and SASL

  1. Using the Edge Testing Tool “XDR Tests” for “System as Receiver”, 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)).

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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_CCDS” 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.

SUT 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).

SUT 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).

Paragraph (b)(1)(i)(B) (Alternative) – Receive Using Edge Protocol for SMTP

System Under Test Test Lab Verification

SUT Connection – Using TLS and SASL

  1. Using the Edge Testing Tool “SMTP Tests” for “System as Receiver”, the user initiates a valid TLS session for the Health IT Module with the ETT sent from email address the user name 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 user name 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.

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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 C-CDA tests, the user selects the payload type and receives a document from the ETT using valid SMTP commands from the user name 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).

SUT 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 the connection and reject the connection upon receiving an invalid certificate from the server.

SUT 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 SUT 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 SUT 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).

Paragraph (b)(1)(i)(B) (Alternative) – Receive Using Edge Protocol for IMAP

System Under Test Test Lab Verification

SUT Connection – Using TLS and SASL

  1. Using the Edge Testing Tool “IMAP Tests” for “System as Receiver”, 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).
  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.

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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).

SUT 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.

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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).

Paragraph (b)(1)(i)(B) (Alternative) – Receive Using Edge Protocol for POP3

System Under Test Test Lab Verification

SUT Connection – TLS and SASL

  1. Using the Edge Testing Tool “POP3 Tests” for “System as Receiver”, 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).
  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.

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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).

SUT 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.

SUT Connection – Secure Network If Not Using TLS

  1. The user demonstrates the ability to provide a secure connection to the SUT 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).

Paragraph (b)(1)(i)(C) (Conditional) – XDM Processing (Received via Edge Protocol)

System Under Test Test Lab Verification

Receive XDM Payload

  1. Using the ETT “SMTP Tests” for “System as Receiver”, 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 user name 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 SUT, 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.

Paragraph (b)(1)(ii)(A)

System Under Test Test Lab Verification

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 (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 R2 Release 1.1 and C-CDA R2 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 Continuity of Care Document (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 § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1 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) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 and § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1.
  3. Each of these documents includes, at a minimum, as applicable, the following:
    • Common Clinical Data Set;
    • 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) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 and § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1 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) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 and § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1 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.

Receive Payload

  1. Using the ETT: Message Validators - C-CDA 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_CCDS” criteria and the file name.

Parse and Process

  1. For each payload received in step 1 of the SUT, 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) 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 SUT 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).
  3. The tester verifies that summaries received, parsed, and processed in step 2 of the SUT also contain the following data elements as applicable:
    • Common Clinical Data Set;
    • 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 SUT 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) 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 SUT, the tester uses visual inspection to verify that 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) 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.

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

System Under Test Test Lab Verification

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) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 or § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1. 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:

  • Common Clinical Data Set;
  • Encounter diagnoses;
  • Cognitive status;
  • Functional status;
  • Ambulatory setting only: reason for referral, and referring or transitioning provider's name, and office contact information; and
  • Inpatient setting only: the discharge instructions.

Using transition of care/referral summary information retrieved in section (b)(1)(ii)(A) step 1 of the SUT, 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) and § 170.205(a)(4) 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 from the:

  • Common Clinical Data Set;
  • Encounter diagnoses;
  • Cognitive status;
  • Functional status;
  • Ambulatory setting only: reason for referral, referring or transitioning provider’s name, and office contact information; and
  • Inpatient setting only: the discharge instructions.

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

System Under Test Test Lab Verification

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) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 or § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1.
  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) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 and § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1.
  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.

Display Section Views

  1. Using visual inspection, the tester verifies that 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 SUT, 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 that data first displayed in step 1 of the SUT 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 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 set in the previous step (step 4 of the TLV). 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 that the number of transition of care/referral summary sections initially displayed in step 1 of the SUT corresponds to the quantity of sections to be displayed in step 6 of the SUT.

Paragraph (b)(1)(iii)

System Under Test Test Lab Verification

Data Entry

  1. Based upon the health IT setting, the health IT developer uses the ETT: Message Validators - C-CDA 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) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1, 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 following content in accordance with the specified standards as applicable:
    • Common Clinical Data Set as specified in section (b)(1)(iii)(A);
    • Encounter diagnoses as specified in section (b)(1)(iii)(B);
    • Cognitive status as specified in section (b)(1)(iii)(C);
    • 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.

Data Entry

  1. For each transition of care payload sent by the SUT, the tester uses the transition of care/referral summary information document downloaded in step 1 of the SUT 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 SUT 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 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 that for each supported health IT setting the following type of transition of care/summary care records have been created by the SUT:
    • Continuity of Care Document (CCD);
    • C-CDA R2 R2.1 Referral Note Document; and
    • Inpatient setting only: C-CDA R2 R2.1 Discharge Summary.

Paragraph (b)(1)(iii)(A)

System Under Test Test Lab Verification

The Common Clinical Data Set

The content of the transition of care/referral summaries created in Data Elements and Vocabularies applicable to the Common Clinical Data Set (CCDS) section (b)(1)(iii) contains the Common Clinical Data Set where applicable and represent such data in accordance with the standards specified in the CCDS Reference Document for C-CDA R2 R2.1 documents.

The verification that the Common Clinical Data Set content is in accordance with the standards specified in the CCDS Reference Document for a document specified in accordance with § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1 is performed as part of the verification done in section (b)(1)(iii) steps 2-3 of the TLV.


Paragraph (b)(1)(iii)(B)

System Under Test Test Lab Verification

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®.

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 TLV.


Paragraph (b)(1)(iii)(C)

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.

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).


Paragraph (b)(1)(iii)(D)

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.

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).


Paragraph (b)(1)(iii)(E)

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.

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 TLV to verify the unstructured text data element Reason for Referral.


Paragraph (b)(1)(iii)(F)

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.

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 TLV.


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

System Under Test Test Lab Verification

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.
  • 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

The verification 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, 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).


Paragraph (b)(1)(iii)(G)(1)(ii) Optional

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.

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.


Version 1.6 Updated on 05-02-2018
Revision History
Version # Description of Change Version Date
1.0

Initial Publication

10-29-2015
1.1

Revised to include guidance about Cognitive status, guidance on testing and validation of ToC/referral summaries, and copy edits for improved readability.

01-05-2016
1.2

Clarification added- (b)(1) test results may be considered for (b)(4) and/or (b)(5).

04-22-2016
1.3

Spelled out the difference between sending and receiving protocol options for (b)(1)(i)(A)&(B).

Clarified (b)(1)(i)(C) that the Edge system receiving via IMAP4 or POP3 protocols is permitted and that their use continues to apply to this portion of the criterion.

08-19-2016
1.4

Clarification added – (b)(1) exchange using TLS/SASL or a secure network is permitted.

Clarification of the cipher suite requirements due to updated standards.

07-07-2017
1.5

Provides notification of March 2017 Validator Update of C-CDA 2.1 Corrections adoption and compliance requirements for the entire criterion.

09-29-2017
1.6

Provides notification of April 2018 Validator Update of C-CDA 2.1 Corrections adoption and compliance requirements for the entire criterion. Note: Due to an error in calculation ONC is also updating the dates for compliance with the March 2017 Validator Update of C-CDA 2.1 Corrections that were adopted September 29, 2017.

05-02-2018
Regulation Text
Regulation Text

§170.315 (b)(1) Transitions 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) and § 170.205(a)(4) 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) and § 170.205(a)(4).
      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) and § 170.205(a)(4).
      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) and § 170.205(a)(4).
    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) and § 170.205(a)(4) 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)(4) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:.
    1. The Common Clinical Data Set.
    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)(4).
    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, 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).
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) 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: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1, August 2015

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

§ 170.207(a)(4) International Health Terminology Standards Development Organization (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT® ) U.S. Edition, September 2015 Release

§ 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 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.

Please refer to the Data Elements and Vocabularies applicable to the Common Clinical Data Set (CCDS) as outlined in the Common Clinical Data Set Reference Document

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

§ 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1, August 2015

§ 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

§ 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

 

Additional Resources

§ 170.207(a)(3) International Health Terminology Standards Development Organization (IHTSDO)  Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) International Release July 31, 2012 and US Extension to SNOMED CT® March 2012

Certification Companion Guide: Transitions of care

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product development. The CCG is not a substitute for the 2015 Edition final regulation. It extracts key portions of the rule’s preamble and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the 2015 Edition final rule or other included regulatory reference. The CCG is for public use and should not be sold or redistributed.
 

 

Certification Requirements

Privacy and Security: This certification criterion was adopted at § 170.315(b)(1). As a result, an ONC-ACB must ensure that a product presented for certification to a § 170.315(b) “paragraph (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 (b) 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) “VDT” and (e)(2) “secure messaging,” which are explicitly stated.

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively the developer must state that no accessibility-centered design was used.
  • C-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 Certification Companion Guide for more details.
Table for Privacy and Security
Technical Explanations and Clarifications

 

Applies to entire criterion

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]
  • We recommend health IT developers and providers follow the guidance provided in the HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm. This Companion Guide includes industry best practices guidance for consistent implementation of the C-CDA Release 1.1 standard, including mapping Common MU Data Set elements into the C-CDA standard. [see also 80 FR 62633] We understand that HL7 is developing a Companion Guide for C-CDA Release 2.1 and intend to update this document once it becomes publicly available. In the meantime, we recommend developers follow the guidance provided by the HL7 CDA Example Task Force for implementation of the C-CDA Release 2.1 standard.
  • 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 as part of required testing and certification to this criterion. [see FAQ #51] 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. Consistent with FAQ 51, 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., C-CDA 2.1 Validator). Similarly consistent with FAQ 51, 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 Program.
  • For a Health IT Module presented for testing and certification to § 170.315(b)(1), ATLs and/or ONC-ACBs may use those successful test results to demonstrate/attest to conformance with the requirements of § 170.315(b)(4) and/or (b)(5).

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

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 of 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).

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

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 considered to be “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]

Paragraph (b)(1)(ii)(A)

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:

  • We are requiring 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 the health IT be able to detect valid and invalid ToC/referral summaries during testing. We strongly recommend developers consider how the health IT 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. Health IT Modules will not be tested for C-CDA Release 1.1 Referral Note and Discharge Summary document templates. 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.

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

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 available.

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

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]

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

Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes the Common Clinical Data Set, 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 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]
  • We provide the following OIDs to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • ICD-10 Procedure Coding System OID: 2.16.840.1.113883.6.4
    • 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 the September 2015 Release 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 has been deprecated in Release 2.1 and has been 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.

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

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 transition of care/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]
  • We recommend 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]
  • C-CDA Release 2.1 cannot distinguish between historical and current address, but can accommodate more than one address. [see also 80 FR 62637]
  • The C-CDA validation tool will test adherence to the use of the HL7 postal format for address. [see also 80 FR 62637]

Regulation Text
Regulation Text

§170.315 (b)(1) Transitions 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) and § 170.205(a)(4) 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) and § 170.205(a)(4).
      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) and § 170.205(a)(4).
      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) and § 170.205(a)(4).
    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) and § 170.205(a)(4) 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)(4) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:.
    1. The Common Clinical Data Set.
    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)(4).
    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, 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).
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)

Content last reviewed on July 13, 2018
Was this page helpful?