Clarifications:

• In order to advance interoperability, the “Common Clinical Data Set” (CCDS) definition and its references have been replaced with the “United States Core Data for Interoperability” (USCDI) standard Version 1 (v1). [see also 85 FR 25941]
• The adoption of version 1 of the USCDI as a standard for the ONC Health IT Certification Program is not specific to a setting of care, a healthcare specialty, or a specific category of health IT user. Nor is the USCDI specific to a particular content exchange standard (e.g., Health Level Seven International (HL7®) Consolidated Clinical Document Architecture (C-CDA), HL7® Fast Healthcare Interoperability Resources (FHIR®), HL7® V2, and NCPDP SCRIPT). Rather, it applies to the certification of health IT and certified health IT’s ability to send and receive the Data Elements defined by USCDI without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. [see also 85 FR 25670], [see also 85 FR 25804], [see also 85 FR 25676]
• For the purposes of the ONC Health IT Certification Program, specific certification criteria are the way the USCDI comes into effect. For example, the USCDI is referenced as part of the data requirements in the updated “transitions of care” certification criterion (§ 170.315(b)(1)), which also specifies that for certification to that criterion, the C-CDA must be used as the syntax to hold all of the USCDI data. [see also 85 FR 25670]
• USCDI includes the most recent versions of code sets at the time of publication of the USCDI v1 standard. [see also 85 FR 25672]
• As indicated in the Final Rule, relevant standards adopted in the Final Rule may enforce stricter requirements than those required specifically by USCDI. Generally, it is not ONC’s intent to override “shall” or “must support” standard requirements unless otherwise specifically stated in the Final Rule. Therefore, all “shall” and “must- support” elements in the adopted IGs (FHIR US Core or applicable C-CDA IG, as determined by criterion) must be supported even if not specified in the minimum required data elements in USCDI v1.
• Developers are not required to incorporate data that was captured prior to the requirements set forth by the Cures Update certification criteria into the standards or data elements of those new requirements. Rather, when such legacy data is represented, the unavailable data should be represented as not available in a manner appropriate to each criterion and the specific standards the criterion requires. However, data that is incorporated after the Health IT Module has become compliant with the 2015 Edition Cures Update USCDI requirement should be made available in, and according to the USCDI standard.

Clarifications:

• C-CDA ONLY Clarification: For certification criteria that reference the USCDI to be included within C-CDA document templates, it is permissible to include “goals” in the Plan of Treatment Section that relate to specific actions documented in the plan of treatment. (see Goals clarifications for additional clarification).

Clarifications:

• The Clinical Notes Data Elements are content exchange standard-agnostic. They should not be interpreted or associated with the specific C-CDA Document Templates that may share the same name. [see also 85 FR 25674]
• Clinical notes originating from the Health IT Module are required to be represented in their plain-text form when included in various content exchange standards (e.g., C-CDA, HL7® FHIR®) as may be applicable to the certification criteria in which the USCDI is referenced. [see also 85 FR 25675]
• Clinical note text that originates from outside Health IT Modules should be exchanged using its original format. Health IT Modules should not convert a “machine readable” format to a non-“machine readable” format (e.g., .docx, PDF).
• The LOINC codes included in the “Applicable Standard(s)” section of Data Elements of USCDI “Clinical Notes” Data Class are generic. There are more specific LOINC concepts for each note type that vary by setting, specialty, etc. In most clinical situations, health IT developers are encouraged to use a more specific LOINC code than the code listed in the “Applicable Standard(s)” column to represent the USCDI “Clinical Notes” Data Elements.
• C-CDA ONLY Clarification: ONC provides flexibility for the Diagnostic and Laboratory Test Result Narratives to be placed in the CCD “Results” or the “Notes” sections.

Clarifications:

• C-CDA ONLY Clarification: For certification criteria that reference the USCDI to be included within C-CDA document templates, “patient goals,” those of the care team, and those that are longitudinal in nature must be recorded in the Goals Section.

Clarifications:

• C-CDA ONLY Clarification: The Problem Section within C-CDA based document templates contains the problem list of the “priority concerns” that the author deemed significant enough to be on the problem list related to the current encounter. Any additional health concerns should not be contained in the Problem Section.

Clarifications:

• C-CDA ONLY Clarification: C–CDA Release 2.1 supports National Drug Code (NDC) code as a translational data element, but the Codes for Vaccines Administered (CVX) code is required to accompany it.
• The Centers for Disease Control and Prevention (CDC) provides a publicly available mapping of NDC codes for vaccines to CVX codes, which ONC encourages developers to utilize.

Clarifications:

• All medications may not yet have an equivalent RxNorm code. Where no RxNorm code exists, a Health IT Module is not prohibited from using another code (e.g., local codes). However, where corresponding RxNorm codes exist, Health IT Modules must be able to use those codes. [see also 77 FR 54199]
• C-CDA ONLY Clarification: The C–CDA R2.1 Cures Update Validator will implement and validate the No Medications best practice. Please follow the HL7® guidance to codify No Medications.

Clarifications:

• ONC included Patient Demographics “address” (to represent the postal location for the patient) and “phone number” (to represent the patient’s telephone number) to improve the comprehensiveness of the healthcare information and patient matching data elements.
• Phone Number
  • C-CDA ONLY Clarification: “Phone number” and “phone number type” must be represented using the same standards, ITU-T E.123 (02/2001) and ITU-T E. 164, as already adopted for this data in 45 CFR 170.207(q) and referenced in the 2015 Edition “transitions of care” certification criterion (§ 170.315(b)(1)(iii)(G)). [see also 85 FR 25672]
• Address
  • In order to meet the requirement for “address” a Health IT Module must capture at a minimum: street name, number, city/town, state, and zip code.
• Race
  • A Health IT Module needs to be capable of recording multiple races for a patient. For Example: White; Asian. [see also 80 FR 62618]
  • When race is included within a transmission (pursuant to other certification criteria that reference the USCDI) the applicable Office of Management and Budget (OMB) roll-up categories must be able to be included in addition to the specific race codes in the CDC code set. The order and grouping of such codes is not dictated by 2015 Edition rules and, thus, defers to a standard or implementation guide’s requirements for how such codes would be represented as part of a transmission.
• Ethnicity
  • A Health IT Module needs to be capable of recording multiple detailed ethnicities for a patient (For example: "Dominican" and "Mexican"). [see also 80 FR 62618]
  • When ethnicity is included within a transmission (pursuant to other certification criteria that reference the USCDI) only one OMB roll-up ethnicity is permitted (in the context of the OMB standard's two question format for race and ethnicity).
  • When "Hispanic or Latino" is the applicable OMB roll-up category, it must be able to be included in addition to the specific ethnicity codes (if applicable) in the CDC code set.
  • C-CDA ONLY Clarification: ONC provides the following object identifier (OID) to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards. “Race & Ethnicity” - CDC code system OID: 2.16.840.1.113883.6.238 [see also 80 FR 62612]
• Race and Ethnicity
  • The following clarifications apply to both Race and Ethnicity.
  • The CDC Race and Ethnicity Code Set Version 1.0 includes over 900 concepts for representing race and ethnicity, in which 921 reference race and 43 reference ethnicity. [see also 80 FR 16816]
  • A product does not need to display all of the race and/or ethnicity codes to meet the certification criterion. The developer has the discretion to create a default selection set or enable customization choices for providers. However, for the purposes of testing, a developer should be prepared to show that the product can represent any of the ethnicities in the value set created by the standard.
  • The concepts in the "Race & Ethnicity" - CDC code system are pre-mapped to the race and ethnicity categories in the OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15. Testing will verify that the more granular race and ethnicity codes are correctly mapped to the OMB standard.
• Language
  • C-CDA ONLY Clarification: ONC provides the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • Tags for Identifying Languages - Request for Comment (RFC) 5646 code system OID: 2.16.840.1.113883.6.316 [see also80 FR 62612]
  • A product does not need to display all of the language codes to meet the 2015 Edition USCDI definition. The developer has the discretion to create a default selection set or enable customization choices for providers. However, for the purposes of testing, a developer should be prepared to show that the product can represent any of the languages in the value set created by the standard
  • Testing for preferred language using the standard at § 170.207(g)(2) (RFC 5646) will focus on all the languages present in ISO 639-2.
  • Consistent with the RFC 5646 the shortest alpha code for the language should be used. Testing will only test the primary language tag and not test for extension components specified in RFC 5646 such as extended language sub-tags, script tag, nor region tag. [see also 80 FR 16817] Specifically:
    • use alpha 2 character code if one exists (ISO 639-1);
    • use alpha 3 character code if an alpha 2 character code does not exist (ISO 639-2); and
    • region extensions (ISO 3166-1) are permitted but not required (However, if a region extension is used, it will be verified for accuracy as part of testing and must be correct).

Clarifications:

• ONC strongly encourages health IT developers to enable users to perform real-time clinical coding using SNOMED CT®, but clarify that real-time clinical coding in SNOMED CT® is not required for the purposes of certification.

Clarifications:

• Even though the “author” Data Element is not explicitly required in USCDI, the health IT standards in which USCDI Data Elements are represented also set specific data element requirements for certain contexts. [85 FR 25675]
• USCDI data elements exchanged via C-CDA require the use of the “Author Participant” template for provenance at the CDA Header, CDA Section, and CDA Entry level. Multiple authors can be entered at the CDA Section and CDA Entry levels. If provenance is the same for all data elements in the C-CDA document, follow guidance in HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide (2019).For USCDI Patient Demographic data class in which there are cases of “multiple” provenance information associated across data elements solely contained in the C-CDA Header (or within the US Core FHIR Patient Profile), Health IT Developers are still required to include provenance information for the individual elements, but have flexibility in how to include it.
• “Author” has not been finalized as a required Data Element within the provenance Data Class in USCDI. However, for exchanging certain data elements, such as “clinical notes,” it is critical to also send the “author” information if available. [85 FR 25675]
•  “Provenance” is constrained to only scope of data for which the health IT developer is the owner/steward. [see also 85 FR 25914]

Clarifications:

• Base EHR definition will now be required to be able to exchange and use smoking status information according to applicable content and formatting standards. [see also 85 FR 25660]

Clarifications:

• Applies to all Vital Signs
  • Systems have the flexibility to choose how to display the vital sign measurement. The requirement only specifies that the vital sign measurement must be exchanged using an applicable unit of measurement with a Unified Code of Units for Measure (UCUM) code. Therefore, systems could exchange a height of 5'6" as 66 inches or 5.5 feet or 167.64 centimeters using the appropriate UCUM code to represent the unit of measure for the measurement (example only). [see also 80 FR 62695]
  • LOINC provides a translation table that enumerates UCUM syntax for a subset of UCUM codes that are commonly used in health IT that may be a useful reference for developers. [see also 80 FR 62695]
  • C-CDA ONLY Clarification: ONC also recommends health IT developers and providers follow the guidance provided in C-CDA Release 2.1 for exchanging vital signs using C-CDAs. [see also 80 FR 62695]
• Blood Pressure
  • Health IT Modules may store and display the systolic and diastolic blood pressure in one field as long as they are exchanged as two separate fields. [see also 80 FR 62694]
• Pulse Oximetry
  • For pulse oximetry, implementers can choose the LOINC® code with "pulse oximetry" in its name that best represents the method of measurement for exchange for the purposes of testing and certification. [see also 80 FR 62694]
• Pediatric Vital Signs o Pediatric vital signs include both the vital measurements and the percentiles used in the growth charts currently recommended by the Centers for Disease Control and Prevention: for infants birth to 36 months of age: weight-for-length; and head occipital-frontal circumference for age; and for children 2-20 years of age: body mass index (BMI) for age. [see also 85 FR 25674]

Clarifications:

• If a device is still implanted in the patient, it is considered “active.” Thus, for the purposes of the USCDI’s reference to unique device identifier (UDI), all of a patient’s current/“active” implanted devices must be included.