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

§170.315(b)(4) Common Clinical Data Set summary record – create

Version 1.1 Updated on 02-22-2018
Revision History
Version # Description of Change Version Date
1.0

Final Test Procedure

01-20-2016
1.1

Removed “(i)” from the sentence Each of the C-CDA R2 R2.1 documents created in (b)(4)(i) includes…” for paragraphs (b)(4)(ii) – (b)(4)(vii).

Clarified reference step numbers are from the TLV on the steps under the TLV of paragraphs (b)(4)(i) – (b)(4)(vii).

02-22-2018
Regulation Text

Regulation Text

§170.315 (b)(4) Common Clinical Data Set summary record – 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

Applies to entire criterion

§ 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

Paragraph (b)(4)(i)

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)(4)(ii)

§ 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) ICD-10-CM

 

Additional Resources

§ 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

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 No Documentation Icon Visual Inspection Icon Test Tool Icon ONC Supplied Test Data Icon

 

Paragraph (b)(4)

System Under Test Test Lab Verification

Setup

  1. Using the ETT: Message Validators – C-CDA R2.1 Validator, the user downloads the ONC-supplied data instructions through the sender download selections of the “170.315_b4_CCDS_Amb” or “170.315_b4_CCDS_Inp” criteria and one of the CCDS summary record – Create instruction documents and executes the download.

Data Entry

  1. A user enters the Common Clinical Data Set (CCDS) summary record information downloaded in step 1 in order to create a patient record with the necessary information in the Health IT Module.

Create

  1. Using the Health IT Module, the user creates a CCDS summary record with the minimum content specified in (b)(4)(i) – (b)(4)(vi) as a transition of care/referral summary document formatted in accordance with the standards specified in § 170.205(a)(4) to create each of the following document templates, as applicable:
    • Continuity of Care Document;
    • Referral Note; and
    • Inpatient setting only: Discharge Summary.
  2. The CCDS summary record created in step 3 is submitted to the tester for verification.
  3. Based upon the health IT setting(s) ambulatory and/or inpatient, a user repeats steps 1-4 for each of the ambulatory and/or inpatient CCDS summary record – Create instruction documents found in the ETT: Message Validators. The submission of a CCDS summary record document is required for all of the CCDS summary record instruction documents for a given health IT setting.

Data Entry

  1. Using the CCDS summary record instruction document downloaded in step 1 of the SUT, the tester verifies that the CCDS summary record information entered into the Health IT Module is accurate and without omission.

Create

  1. Using the ETT: Message Validators – C-CDA R 2.1 Validator, the tester uploads the submitted CCDS summary record created by the Health IT Module, through the upload section of the “170.315_b4_CCDS_Amb” or “170.315_b4_CCDS_Inp” criteria and the file name, and executes the upload of the submitted file to the ETT: Message Validators.
  2. For each submitted CCDS summary record document, the tester uses the Validation Report produced by the ETT: Message Validators to verify the Health IT Module passes without error to confirm that the CCDS summary record is conformant to the standard adopted in § 170.205(a)(4). 
  3. As required by the ONC-supplied CCDS summary record instructions, the tester uses the ONC-supplied CCDS summary record instructions and the Message Content Report produced by the ETT: Message Validators to verify the additional checks for equivalent text for the content of all section level narrative text.
  4. Using the ETT: Message Validators Validation Report, the tester verifies that for each supported health IT setting, the following types of CCDS summary record summary documents have been created by the SUT:
    • Continuity of Care Document;
    • C-CDA R2 R2.1 Referral Note Document; and
    • Inpatient setting only: C-CDA R2 R2.1 Discharge Summary.

Paragraph (b)(4)(i)

System Under Test Test Lab Verification

The Common Clinical Data Set

Each of the C-CDA R2 R2.1 documents created in (b)(4) includes at a minimum, the data from the Common Clinical Data Set (CCDS) 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 tester performs verification that the CCDS data elements are in accordance with 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, Draft Standard for Trial Use, Release 2.1, as part of the create verification in (b)(4) steps 3-5 of the TLV.


Paragraph (b)(4)(ii)

System Under Test Test Lab Verification

Encounter Diagnoses

Each of the C-CDA R2 R2.1 documents created in (b)(4) include Encounter diagnoses using at least one standard, either:

  • the standard specified at §170.207(i), code set specified at 45 CFR 162.1002(c)(2) for the indicated conditions or the standard specified at § 170.207(a)(4). 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; and
    5. Causes of injury, disease, impairment, or other health problem.
  • or at a minimum the version of the standard specified at §170.207(a)(4) (ICD-10-CM or SNOMED CT®).

The tester performs verification that the Encounter diagnoses data element 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), as part of the create verification in (b)(4) steps 3-4 of the TLV.


Paragraph (b)(4)(iii)

System Under Test Test Lab Verification

Cognitive Status

Each of the C-CDA R2 R2.1 documents created in (b)(4) includes Cognitive status, when present, in the Health IT Module.

The verification of the Cognitive status data element, when present in the Health IT Module, is performed as part of the create verification in (b)(4) steps 3-4 of the TLV.


Paragraph (b)(4)(iv)

System Under Test Test Lab Verification

Functional Status

Each of the C-CDA R2 R2.1 documents created in (b)(4) includes Functional status, when present, in the Health IT Module.

The verification of the Functional status data element, when present in the Health IT Module, is performed as part of the create verification in (b)(4) steps 3-4 of the TLV.


Paragraph (b)(4)(v)

System Under Test Test Lab Verification

Ambulatory Setting Only

Each of the C-CDA R2 R2.1 documents created in (b)(4) for the ambulatory health IT setting includes the following data:

  • reason for referral;
  • referring or transitioning provider’s name; and office contact information.

The verification of the data element requirements for the ambulatory setting is performed as part of the create verification in (b)(4) steps 3-5 of the TLV. This includes verifying that the content of the CCDS summary record created in (b)(4) includes: reason for referral, referring or transitioning provider’s name and office contact information. Additional verification is done in (b)(4) step 5 of the TLV, to verify that the unstructured data element reason for referral is correct.


Paragraph (b)(4)(vi)

System Under Test Test Lab Verification

Inpatient Setting Only

Each of the C-CDA R2 R2.1 documents created in (b)(4) for the inpatient health IT setting includes discharge instructions.

The verification of the data element requirements for the inpatient setting is performed as part of the create verification in (b)(4) steps 3-5 of the TLV. This includes tester verifies that the content of the CCDS summary record created in (b)(4) includes the discharge instructions. Additional verification is done in (b)(4) step 5 of the TLV to verify that the unstructured data element, discharge instructions, is present and correct.


Paragraph (b)(4)(vii)

System Under Test Test Lab Verification

Patient matching data

Each of the C-CDA R2 R2.1 documents created in (b)(4) includes the following data for patient matching data quality and, where applicable, represent such data as specified below:

  • Name: First name, last name, previous name, middle name (including middle initial), suffix;
  • Date of birth including the year, month and date of birth must be present for a date of birth, when known, and null when unknown;
  • Address;
  • Phone number(s) which are constrained in accordance with the standard specified at § 170.207(q)(1), UTI-E.123 and UTI-E.124; and when multiple phone numbers are present within the Health IT Module they are reflected in the transition of care/referral summaries; and
  • Birth sex in accordance with the standard adopted in § 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 of the data element requirements for patient data matching is performed as part of the create verification in (b)(4) steps 3-5 of the TLV. The verification of the patient matching data within the CCDS summary record created in (b)(4) includes the 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)(4)(vii)(A)(2) Optional

System Under Test Test Lab Verification

Date of Birth with hours, minutes and seconds

If the hour, minute, and second are associated with a date of birth, the technology must demonstrate the correct time zone offset.

The tester verifies that the Health IT Module records the correct time zone offset as part of the time of birth, using visual inspection.


Version 1.2 Updated on 09-29-2017
Revision History
Version # Description of Change Version Date
1.0

Initial Publication

01-05-2016
1.1

Clarification on testing and certification flexibility permitting leveraging test results from § 170.315(b)(1) for (b)(4).

04-22-2016
1.2

Provides notification of C-CDA2.1 errata adoption and compliance requirements within the entire criterion row.

09-29-2017
Regulation Text

Regulation Text

§170.315 (b)(4) Common Clinical Data Set summary record – 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

Applies to entire criterion

§ 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

Paragraph (b)(4)(i)

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)(4)(ii)

§ 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) ICD-10-CM

 

Additional Resources

§ 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

Certification Companion Guide: Common Clinical Data Set summary record – create

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)(4). 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. (C-CDA R2.1 IG), in March, 2017 and previously, ONC assessed, approved and incorporated the following errata as part of required testing and certification to this criterion: C-CDA 2.1 ERRATA [Effective in testing with the C-CDA 2.1 Validator, March 2017; Surveillance compliance date is September 1, 2018] [see also FAQ #51]
  • At the discretion of the ONC-ATL and ONC-ACB, the requirements of this criterion may be met through testing and certification to § 170.315(b)(1).

Paragraph (b)(4)(i)

Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes the Common Clinical Data Set.

Clarifications:

  • Please refer to the standards required for the 2015 Edition Common Clinical Data Set.

Paragraph (b)(4)(ii)

Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes Encounter diagnoses using either ICD-10-CM or SNOMED CT® codes.

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]

Paragraph (b)(4)(iii)

Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes Cognitive status.

Clarifications:

  • 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 is used instead.

Paragraph (b)(4)(iv)

Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes Functional status.

Clarifications:

  • No additional clarifications available.

Paragraph (b)(4)(v)

Technical outcome – In the ambulatory setting only, the health IT can create a C-CDA (formatted to Release 2.1) that includes the reason for referral and the referring or transitioning provider’s name and office contact information.

Clarifications:

  • No additional clarifications available.

Paragraph (b)(4)(vi)

Technical outcome – In the inpatient setting only, the health IT can create a C-CDA (formatted to Release 2.1) that includes discharge instructions.

Clarifications:

  • No additional clarifications available.

Paragraph (b)(4)(vii)

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)(4) Common Clinical Data Set summary record – 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).

Criterion Subparagraph Test Data
(b)(4)

Inpatient Setting - 170.315_b4_ccds_create_inp_sample*.pdf (all samples)

Ambulatory Setting - 170.315_b4_ccds_create_amb_sample*.pdf (all samples)

Content last reviewed on February 21, 2018
Was this page helpful?