§170.315(b)(4) Common Clinical Data Set summary record – create
§ 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:
- The Common Clinical Data Set.
- Encounter diagnoses. Formatted according to at least one of the following standards:
- The standard specified in §170.207(i).
- At a minimum, the version of the standard specified in §170.207(a)(4).
- Cognitive status.
- Functional status.
- Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.
- Inpatient setting only. Discharge instructions.
- 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:
- Date of birth constraint—
- 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.
- 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.
- 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.
- Sex constraint. Represent sex in accordance with the standard adopted in §170.207(n)(1).
- Date of birth constraint—
Applies to entire criterion
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(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:
- Male. M
- Female. F
- 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
| 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:
- The Common Clinical Data Set.
- Encounter diagnoses. Formatted according to at least one of the following standards:
- The standard specified in §170.207(i).
- At a minimum, the version of the standard specified in §170.207(a)(4).
- Cognitive status.
- Functional status.
- Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.
- Inpatient setting only. Discharge instructions.
- 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:
- Date of birth constraint—
- 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.
- 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.
- 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.
- Sex constraint. Represent sex in accordance with the standard adopted in §170.207(n)(1).
- Date of birth constraint—
- Standard(s) Referenced
-
Applies to entire criterion
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(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:
- Male. M
- Female. F
- 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
- Testing
-
Testing Tool
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)
- Revision History
-
Version # Description of Change Version Date 1.0 Final Test Procedure
01-20-20161.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
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
Paragraph (b)(4)
Setup
- 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
- 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
- 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) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1 to create each of the following document templates, as applicable:
- Continuity of Care Document;
- Referral Note; and
- Inpatient setting only: Discharge Summary.
- The CCDS summary record created in step 3 is submitted to the tester for verification.
- 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
- 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
- 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.
- 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).
- 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.
- 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.
| System Under Test | Test Lab Verification |
|---|---|
|
Setup
Data Entry
Create
|
Data Entry
Create
|
Paragraph (b)(4)(i)
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, DSTU Release 2.1, as part of the create verification in (b)(4) steps 3-5 of the TLV.
| 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, DSTU Release 2.1, as part of the create verification in (b)(4) steps 3-5 of the TLV. |
Paragraph (b)(4)(ii)
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) ICD-10-CM for the following conditions:
- Diseases;
- Injuries;
- Impairments;
- Other health problems and their manifestations; and
- Causes of injury, disease, impairment, or other health problem.
- or at a minimum the version of the standard specified at § 170.207(a)(4) 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.
| 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 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)
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.
| 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)
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.
| 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)
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.
| 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:
|
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)
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.
| 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)
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) ITU-T E.123 and ITU-T E.164 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:
- Male. M
- Female. F
- 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).
| 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:
|
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
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.
| 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. |
§ 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:
- The Common Clinical Data Set.
- Encounter diagnoses. Formatted according to at least one of the following standards:
- The standard specified in §170.207(i).
- At a minimum, the version of the standard specified in §170.207(a)(4).
- Cognitive status.
- Functional status.
- Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.
- Inpatient setting only. Discharge instructions.
- 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:
- Date of birth constraint—
- 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.
- 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.
- 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.
- Sex constraint. Represent sex in accordance with the standard adopted in §170.207(n)(1).
- Date of birth constraint—
Applies to entire criterion
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(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:
- Male. M
- Female. F
- 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
| 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:
- The Common Clinical Data Set.
- Encounter diagnoses. Formatted according to at least one of the following standards:
- The standard specified in §170.207(i).
- At a minimum, the version of the standard specified in §170.207(a)(4).
- Cognitive status.
- Functional status.
- Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.
- Inpatient setting only. Discharge instructions.
- 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:
- Date of birth constraint—
- 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.
- 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.
- 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.
- Sex constraint. Represent sex in accordance with the standard adopted in §170.207(n)(1).
- Date of birth constraint—
- Standard(s) Referenced
-
Applies to entire criterion
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(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:
- Male. M
- Female. F
- 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
- Revision History
-
Version # Description of Change Version Date 1.0 Initial Publication
01-05-20161.1 Clarification on testing and certification flexibility permitting leveraging test results from § 170.315(b)(1) for (b)(4).
04-22-20161.2 Provides notification of March 2017 Validator Update of C-CDA 2.1 Corrections adoption and compliance requirements for the entire criterion.
09-29-20171.3 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-20181.4 Provides notification of August 2018 Validator Update of C-CDA 2.1 Corrections adoption and compliance requirements for the entire criterion.
09-21-2018 - Testing
-
Testing Tool
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)
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.
| Base EHR Definition | In Scope for CEHRT Definition |
|---|---|
| Not Included | No |
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.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- Integrity (§ 170.315(d)(8))
- If choosing Approach 2:
- For each applicable P&S certification criterion not certified for approach 1, the health IT developer may certify for the criterion using system documentation which provides a clear description of how the external services necessary to meet the P&S criteria would be deployed and used. Please see the 2015 Edition final rule correction notice at 80 FR 76870 for additional clarification.
Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.
- When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively the developer must state that no accessibility-centered design was used.
- 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.
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.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- Integrity (§ 170.315(d)(8))
- If choosing Approach 2:
- For each applicable P&S certification criterion not certified for approach 1, the health IT developer may certify for the criterion using system documentation which provides a clear description of how the external services necessary to meet the P&S criteria would be deployed and used. Please see the 2015 Edition final rule correction notice at 80 FR 76870 for additional clarification.
Applies to entire criterion
Clarifications:
- 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 Health IT Certification Program Overview] Certified health IT adoption and compliance with the following corrections are necessary because they implement updates to vocabularies, update rules for cardinality and conformance statements, and promote proper exchange of C-CDA documents. There is a 90-day delay from the time the CCG has been updated with the ONC-approved corrections to when compliance with the corrections will be required to pass testing (i.e., C-CDA 2.1 Validator). Similarly, there will be an 18-month delay before a finding of a correction’s absence in certified health IT during surveillance would constitute a non-conformity under the Program.
- March 2017 Validator Update of C-CDA 2.1 Corrections [Effective for testing on December 28, 2017; Surveillance compliance date is March 29, 2019]
- April 2018 Validator Update of C-CDA 2.1 Corrections [Effective for testing on July 31, 2018; Surveillance compliance date is November 2, 2019]
- August 2018 Validator Update of C-CDA 2.1 Corrections [Effective for testing on December 20, 2018; Surveillance compliance date is March 21, 2020]
- 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).
|
Clarifications:
|
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.
|
Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes the Common Clinical Data Set. Clarifications:
|
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]
|
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:
|
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.
|
Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes Cognitive status. Clarifications:
|
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.
|
Technical outcome – The health IT can create a C-CDA (formatted to Release 2.1) that includes Functional status. Clarifications:
|
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.
|
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:
|
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.
|
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:
|
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]
|
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:
|