CDA_IG_C-CDA_RUBRIC_CRIT_R1_O1_2019MAY

 

HL7-International-Logo_2_x2                                

 

 

 

HL7 Guidance: C-CDA Rubric Criteria, Release 1

MM 2020

 

HL7 Informative Guide

 

Sponsored by:
Structured Documents

Patient Care

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2019 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.  HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off .

Use of this material is governed by HL7's IP Compliance Policy .


I MPORTANT NOTES:

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.

If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material") , the following describes the permitted uses of the Material.

A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.

INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.

C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part.

NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.

Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

 

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with , the foregoing.

 

Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”).  Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability.

 

Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology

Owner/Contact

Current Procedures Terminology (CPT) code set

American Medical Association
https://www.ama-assn.org/practice-management/cpt-licensing

SNOMED CT

SNOMED International   http://www.snomed.org/snomed-ct/get-snomed-ct or info@ihtsdo.org

Logical Observation Identifiers Names & Codes (LOINC)

Regenstrief Institute

International Classification of Diseases (ICD) codes

World Health Organization (WHO)

NUCC Health Care Provider Taxonomy code set

American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

 

 

 

 

Table of Figures:

Figure 1: @Code and @ DisplayName Alignment

Figure 2: @Code and @DisplayName Misalignment

Figure 3: Referenced Code System Preferred Name:

Figure 4: Entry Instance ID

Figure 5: Text Reference – Clinically Sensical Example (Medication)

Figure 6: entryTextReference Alignment – Medication Example

Figure 7: entryTextReference Mislignment – Medication Example

Figure 8: entryTextReference Alignment – Problem Example

Figure 9: entryTextReference Mislignment – Problem Example

Figure 10: Organizer and component observation effectiveTime agreement

Figure 11: Organizer and component observation effectiveTime disagreement

Figure 12: Organizer effectiveTime poor practice – nulling component observation effectiveTime

Figure 13: Template IDs with proper version identified in @extension

Figure 14: Template IDs with no version identified in @extension

Figure 15: effectiveTime and Time within lifespan agreement – sdtc:deceasedTime

Figure 16: effectiveTime and Time within lifespan disagreement – sdtc:deceasedTime

Figure 17: effectiveTime and Time within lifespan agreement – deceased observation

Figure 18: effectiveTime and Time within lifespan disagreement – deceased observation

Figure 19: Select Appropriate Precision vs Over Precise effectiveTime Examples

Figure 20: Appropriate Multiple Name Example

Figure 21: Inappropriate Multiple Name Example

Figure 22: Appropriate Precision of BirthTime Example

Figure 23: Inappropriate Precision of BirthTime Example

Figure 24: Appropriate Presence of Allergy Reaction Observation Example

Figure 25: Absence of Allergy Reaction Observation Example

1         Overview

This document contains rubric criteria created through an ongoing project in the HL7 Structured Documents Work Group (SDWG), originating in 2016. Throughout 2018 a group of HL7 members created a new set of rubrics to add to the original rubric. This project identified key problematic areas in real system generated C-CDA documents where similar data was consistently represented differently or incompletely. Variably constructed data removes the ability to reliably share and compare data, adversely impacting interoperability. The hope is that the rubric will promote expansion of nationwide interoperability by allowing providers and health IT developers to identify inconsistencies with data representation in C-CDA documents and proactively adopt tighter constraints to eliminate the variability.

 

Rubric criteria indicate where the implementation community using the C-CDA standard has agreed the constraints need to be tighter and more specific in order to support improved interoperability. The C-CDA Rubric process provides a predictable, transparent, and collaborative process that highlights areas for improvement in the C-CDA specifications which can be implemented in systems today and are needed to expand nationwide interoperability.

 

The balloting process provided transparent, collaborative vetting of existing and new rubric criteria to establish and evolve the criteria.

 

1.1       Need

There is an industry need for disparate systems to exchange information with each other.

End users can utilize these rubric criteria to determine the quality of the C-CDA documents produced by their applications. Iterative discussions between clinical information users and C-CDA document creators based on these rubrics will lead to C-CDA data quality improvement.

2         C-CDA Rubric

2.1       Explanation of the Rubric Criteria

The rubric criteria are a set of tighter constraints then those that exist in C-CDA R2.1 that the implementer community agreed are needed to expand interoperability. They are meant to be utilized in best practice testing tools to provide feedback about generated C-CDA documents with respect to adherence to industry acknowledged best practices.

 

They also are intended to help drive the EHR vendor community towards consistent implementation of the C-CDA standard. They are not to be overinterpreted as additional requirements for certification.

 

There are two types of Rubric criteria identified:

  • Required – All tools adopting these criteria should throw an error.
  • Informational - All tools adopting these criteria should throw a warning, not an error.

3         Common Rubrics

3.1       Required

3.1.1         Rubric-1: DisplayName SHALL be Accurate

If an @displayName is present with an @code then the text of the @displayName SHALL be the text of the code system’s preferred name.

 

3.1.1.1        Rubric Intent

If code's DisplayName is present and it conflicts with the codeSystem's preferred displayName then a tool should throw an error. If a DisplayName isn't present, then a tool should not throw an error. Testing tools will require at least a basic terminology service to implement this Rubric.

 

3.1.1.2        Examples

 

C-CDA Examples Task Force Link: Any entry example: http://hl7-c-cda-examples.herokuapp.com/

 

 

Figure 1 : @Code and @ DisplayName Alignment

<manufacturedMaterial>

       <code code = "573621" codeSystem = "2.16.840.1.113883.6.88"

       codeSystemName = "RxNorm"

       displayName = "Albuterol 0.09 MG/ACTUAT [Proventil]" />
</manufacturedMaterial>

 

 

 

Figure 2 : @Code and @DisplayName Misalignment

<manufacturedMaterial>

       <code code = "573621" codeSystem = "2.16.840.1.113883.6.88"

       codeSystemName = "RxNorm"

       displayName = "Aspirin” />
</manufacturedMaterial>

 

 

Figure 3 : Referenced Code System Preferred Name:

 

 

3.1.2         Rubric-2: Identifiers SHALL be Unique

If Instance Identifiers (IDs) are duplicate in a document instance, then the attributes of that class, when present, SHALL have the same values OR SHALL be the id in an Entry Reference template [act: identifier urn:oid:2.16.840.1.113883.10.20.22.4.122]

AND/OR

(in the case of encounter) The encompassingEncounter/ID SHALL be identical to ONE encounterEntry/id.

 

3.1.2.1        Rubric Intent

Identifiers (e.g. <id/>) in a CDA document on clinicalStatements are used to provide unique identification to each statement. IDs can be used to aid in secondary use of data, auditing, etc. These generally must be unique across a single document instance. But there are exceptions: Entry Reference (TemplateID 2.16.840.1.113883.10.20.22.4.122) ids must equal the id of another entry in the document. An encompassing encounter will have the same id as ONE encounter in the section. It is also permitted that one id is the same as another id IF it is a repeated instance of that clinical statement residing elsewhere intentionally.

 

3.1.2.2        Examples

 

C-CDA Examples Task Force Link: Any entry example: http://hl7-c-cda-examples.herokuapp.com/

 

Figure 4 : Entry Instance ID

 

This id should be unique throughout a document instance across all entries other than the exceptions stated above

 

<observation classCode = "OBS" moodCode = "EVN" >
   <!-- ** Allergy observation ** -->
   <templateId root = "2.16.840.1.113883.10.20.22.4.7" extension = "2014-06-09" />
   <templateId root = "2.16.840.1.113883.10.20.22.4.7" />
   <id root = "901db0f8-9355-4794-81cd-fd951ef07917" />  

</observation>

 

 

 

3.1.3         Rubric-3: Each entry SHALL contain at least one Text reference

Minimally, in each outermost (primary) act in each entry, when entry/code exits, there SHALL be a code/Text/reference that points to the human readable text identified with section/text/@ID

 

3.1.3.1        Rubric Intent

The intent of this rubric is to encourage referencing between narrative and the coded entry to enable validation and comparison of the accuracy of narrative that is read by humans and the contained computer processable encoded data that the human may not see. This rubric is simply that the reference is present.

 

3.1.3.2        Examples

C-CDA Examples Task Force Link:

For examples on technical accuracy of text referencing across entry types please review the methods of referencing in the C-CDA examples task force links below. Note that these do not have clinically relevant codes or text:

 

Narrative Reference - Supply

Narrative Reference - Procedure

Narrative Reference - Organizer

Narrative Reference - SubstanceAdministration

Narrative Reference - Act

Narrative Reference - Encounter

Narrative Reference - Observation

 

 

Figure 5 : Text Reference – Clinically Sensical Example (Medication)

Note: A poor example is the absence of at least one text reference. In addition, it is not necessary to place a reference in multiple locations within a single entry

 

<!-- Section Text -->

<tbody>

<!-- This ID is referenced from the coded entry-->
   <tr ID = "Medication_1" >
        <td>

           <content> Noscapine 3 MG/ML Oral Solution </content>
       </td>
        <td>
          <content> every 4 to 6 hours prn for cough </content>
        </td>
        <td>
            <content> 6 mg (2 mL) </content>
       </td>
       <td> 12/21/17 - 12/31/17 </td>
       <td> Active </td>
   </tr>
</tbody>

 

<!—Corresponding Entry -->

 

<entry typeCode = "DRIV" >
   <substanceAdministration classCode = "SBADM" moodCode = "INT" >  
      <templateId root = "2.16.840.1.113883.10.20.22.4.16" />
      <templateId root = "2.16.840.1.113883.10.20.22.4.16" extension = "2014-06-09" />
      <id root = "7482acd4-693c-4539-b0db-f21c2bf477c0" extension = "1015" />
      <text>
         <!-- This reference refers to the human readable text in the section. The sectionText reflects the

          meaning of the elements, attributes and coded terminology in this entry -->
         <reference value = "#Medication_1" />
      </text>
      <statusCode code = "active" />  
         <effectiveTime xsi:type = "IVL_TS" >
<low value = "20171221" />
<high value = "20171231" />  
         </effectiveTime>
         <effectiveTime xsi:type = "PIVL_TS" institutionSpecified = "true" operator = "A" >
               <period xsi:type = "IVL_PQ" >
   <low value = "4" unit = "h" />
    <high value = "6" unit = "h" />
</period>
          </effectiveTime>
          <routeCode code = "C38288" codeSystem = "2.16.840.1.113883.3.26.1.1" codeSystemName = "NCI

           Thesaurus" displayName = "ORAL" />
          <doseQuantity value = "2" unit = "mL" />
<consumable>
   <manufacturedProduct classCode = "MANU" >
      <templateId root = "2.16.840.1.113883.10.20.22.4.23" extension = "2014-06-09" />
      <templateId root = "2.16.840.1.113883.10.20.22.4.23" />
      <id root = "7482acd4-693c-4539-b0db-f21c2bf477c0" extension = "1015" />
      <manufacturedMaterial>
          <code code = "102494" codeSystem = "2.16.840.1.113883.6.88" displayName = "Noscapine 

                           3 MG/ML Oral Solution" />
       </manufacturedMaterial>
</manufacturedProduct>

             ….

        </entry>

 

 

3.1.4         Rubric-4: entryTextReference alignment

 

Where a link between the narrative (section.text), identified with section/text/(any)/@ID="xxx" and coded clinical data (entry) exists, identified with entry/act/text/reference/@value="#xxx",  the section.text must conceptually align with the meaning of the encoded attributes and elements within the entry it links with. 

 

3.1.4.1        Rubric Intent

The intent of this rubric is to compare the accuracy of narrative that is read by humans and the contained computer processable encoded data that the human may not see. In addition to the presence of textReference, this rubric assesses for accuracy between coded entries and human narrative.

Note 1: For this rubric to be fully implemented a terminology service and text processing must be leveraged.

Note 2: As many textReferences as there are present should be compared. Note that if the text has MORE text in it than in the coded entries, that is OK - so long as it does not conflict.

 

3.1.4.2        Examples

For a full example of tagging technique of textReferencing see 3.1.3 Rubric-3 and its example Figure 5 .

The examples here will focus on truncated examples where alignment exists and where it does not.

 

For examples on technical accuracy of text referencing across entry types please review the methods of referencing in the C-CDA examples task force links below. Note that these do not have clinically relevant codes or text:

 

Narrative Reference - Supply

Narrative Reference - Procedure

Narrative Reference - Organizer

Narrative Reference - SubstanceAdministration

Narrative Reference - Act

Narrative Reference - Encounter

Narrative Reference - Observation

 

Figure 6 : entryTextReference Alignment – Medication Example

 

<tbody>

<!-- This ID is referenced from the coded entry-->
   <tr ID = "Medication_1" >
        <td>

           <content> Noscapine 3 MG/ML Oral Solution </content>
       </td>
        <td>
          <content> every 4 to 6 hours prn for cough </content>
        </td>
        <td>
            <content> 6 mg (2 mL) </content>
       </td>
       <td> 12/21/17 - 12/31/17 </td>
       <td> Active </td>
   </tr>
</tbody>

      <text>
         <reference value = "#Medication_1" />
      </text>

<routeCode code = "C38288" codeSystem = "2.16.840.1.113883.3.26.1.1" codeSystemName = "NCI

           Thesaurus" displayName = " ORAL " />

 

         <effectiveTime xsi:type = "PIVL_TS" institutionSpecified = "true" operator = "A" >
               <period xsi:type = "IVL_PQ" >
   <low value = "4" unit = "h" />
    <high value = "6" unit = "h" />
</period>
          </effectiveTime>

         …

      <manufacturedMaterial>
          <code code = "102494" codeSystem = "2.16.840.1.113883.6.88" displayName = " Noscapine 

                           3 MG/ML Oral Solution " />
       </manufacturedMaterial>

 

 

Figure 7 : entryTextReference Mislignment – Medication Example

 

<!-- Section Text -->

<tbody>

<!-- This ID is referenced from the coded entry-->
   <tr ID = "Medication_1" >
        <td>

           <content> Acetaminophen </content>
       </td>
        <td>
          <content> Per Rectum </content>
        </td>
        <td>
            <content> 2 tabs </content>
       </td>
       <td> 12/21/17 - 12/31/17 </td>
       <td> Active </td>
   </tr>
</tbody>

      <text>
         <reference value = "#Medication_1" />
      </text>

<!-- Entry -->

 

<routeCode code = "C38288" codeSystem = "2.16.840.1.113883.3.26.1.1" codeSystemName = "NCI

           Thesaurus" displayName = " ORAL " />

      <manufacturedMaterial>
          <code code = "102494" codeSystem = "2.16.840.1.113883.6.88" displayName = " Noscapine 

                           3 MG/ML Oral Solution " />
       </manufacturedMaterial>

 

Figure 8 : entryTextReference Alignment – Problem Example

 

<!-- Section Text -->

<tbody>

<!-- This ID is referenced from the coded entry-->

<tbody>
   <tr ID = "Problem1" >
      <td> Community Acquired Pneumonia </td>

<!—Note: This could be a synonym or less granular term instead of exact same for example Community Pneumonia or Pneumonia. It would also be acceptable to have increased narrative text such as: Mrs. Seven, a pleasant elderly woman, who lives in Anytown, USA came down with Community Acquired Pneumonia o n February 27 2014 -->
          <td>
<content> Onset: February 27 2014 </content>
          </td>
          <td> Active </td>
   </tr>
</tbody>

<!-- Entry -->

<text>
<reference value = "#Problem1" />
   </text>
   <statusCode code = "completed" />
   <effectiveTime>
    <!-- This represents the date of biological onset. -->
        <low value = "20140227" />
  </effectiveTime>
    <!-- This is a SNOMED code as the primary vocabulary for problem lists-->
     <value xsi:type = "CD" code = "385093006" codeSystem = "2.16.840.1.113883.6.96"
         codeSystemName = "SNOMED CT" displayName = " Community Acquired Pneumonia " />


 

 

Figure 9 : entryTextReference Mislignment – Problem Example

 

<!-- Section Text -->

<tbody>

<!-- This ID is referenced from the coded entry-->

<tbody>
   <tr ID = "Problem1" >
      <td> Celiac Disease </td>
          <td>
<content> Onset: February 27 2014 </content>
          </td>
          <td> Active </td>
   </tr>
</tbody>

<!-- Entry -->

<text>
<reference value = "#Problem1" />
   </text>
   <statusCode code = "completed" />
   <effectiveTime>
    <!-- This represents the date of biological onset. -->
        <low value = "20140227" />
  </effectiveTime>
    <!-- This is a SNOMED code as the primary vocabulary for problem lists-->
     <value xsi:type = "CD" code = "385093006" codeSystem = "2.16.840.1.113883.6.96"
         codeSystemName = "SNOMED CT" displayName = " Community Acquired Pneumonia " />

 

 

 

3.1.5         Rubric-5: The EffectiveDate/Time elements in an Organizer act must encompass the underlying observations.

Each /organizer/component/observation/effectiveTime/@value SHALL be equal to or within the organizer's /organizer/effectiveTime/low/@value and the organizer’s /organizer/effectiveTime/high/@value

 

3.1.5.1        Rubric Intent

The intent of this rubric is to encourage technical accuracy with respect to clinical practice. For example, a CBC laboratory result report would not contain CBC components (e.g. WBC, RBC, etc.) that are from a blood specimen drawn at a different time.

 

3.1.5.2        Examples

C-CDA Examples Task Force Link:

Result Section Examples: http://hl7-c-cda-examples.herokuapp.com/sections/Results

Vital Sign section examples: http://hl7-c-cda-examples.herokuapp.com/sections/Vital%20Signs

 

Figure 10 : Organizer and component observation effectiveTime agreement

 

<organizer classCode = "BATTERY" moodCode = "EVN" >
   <!-- ** Result organizer (V3) ** -->
   <templateId root = "2.16.840.1.113883.10.20.22.4.1" extension = "2015-08-01" />
   <templateId root = "2.16.840.1.113883.10.20.22.4.1" />
   <id root = "7d5a02b0-67a4-11db-bd13-0800200c9a66" />
      <code code = "57021-8" displayName = "CBC W Auto Differential panel in Blood"   

      codeSystem = "2.16.840.1.113883.6.1" codeSystemName = "LOINC" />
   <statusCode code = "completed" />
   <effectiveTime>
      <low value = "202003190830-0800" />
      <high value = "202003190830-0800" />
   </effectiveTime>   

   <component>
      <observation classCode = "OBS" moodCode = "EVN" >
      <!-- ** Result observation (V3) ** -->
         <templateId root = "2.16.840.1.113883.10.20.22.4.2" extension = "2015-08-01" />
         <templateId root = "2.16.840.1.113883.10.20.22.4.2" />
         <id root = "107c2dc0-67a5-11db-bd13-0800200c9a66" />
         <code code = "718-7" displayName = "Hemoglobin" codeSystem = "2.16.840.1.113883.6.1"

             codeSystemName = "LOINC" />
         <statusCode code = "completed" />
        <effectiveTime value = "202003190830-0800" />

         …

 

Figure 11 : Organizer and component observation effectiveTime disagreement

 

<organizer classCode = "BATTERY" moodCode = "EVN" >
   <!-- ** Result organizer (V3) ** -->
   <templateId root = "2.16.840.1.113883.10.20.22.4.1" extension = "2015-08-01" />
   <templateId root = "2.16.840.1.113883.10.20.22.4.1" />
   <id root = "7d5a02b0-67a4-11db-bd13-0800200c9a66" />
      <code code = "57021-8" displayName = "CBC W Auto Differential panel in Blood"   

      codeSystem = "2.16.840.1.113883.6.1" codeSystemName = "LOINC" />
   <statusCode code = "completed" />
   <effectiveTime>
      <low value = "202003190830-0800" />
      <high value = "202003190830-0800" />
   </effectiveTime>   

   <component>
      <observation classCode = "OBS" moodCode = "EVN" >
      <!-- ** Result observation (V3) ** -->
         <templateId root = "2.16.840.1.113883.10.20.22.4.2" extension = "2015-08-01" />
         <templateId root = "2.16.840.1.113883.10.20.22.4.2" />
         <id root = "107c2dc0-67a5-11db-bd13-0800200c9a66" />
         <code code = "718-7" displayName = "Hemoglobin" codeSystem = "2.16.840.1.113883.6.1"

             codeSystemName = "LOINC" />
         <statusCode code = "completed" />
        <effectiveTime value = "202003200930-0800" />

         …

 

Figure 12 : Organizer effectiveTime poor practice – nulling component observation effectiveTime

 

<organizer classCode = "BATTERY" moodCode = "EVN" >
   <!-- ** Result organizer (V3) ** -->
   <templateId root = "2.16.840.1.113883.10.20.22.4.1" extension = "2015-08-01" />
   <templateId root = "2.16.840.1.113883.10.20.22.4.1" />
   <id root = "7d5a02b0-67a4-11db-bd13-0800200c9a66" />
      <code code = "57021-8" displayName = "CBC W Auto Differential panel in Blood"   

      codeSystem = "2.16.840.1.113883.6.1" codeSystemName = "LOINC" />
   <statusCode code = "completed" />
   <effectiveTime>
      <low value = "202003190830-0800" />
      <high value = "202003190830-0800" />
   </effectiveTime>   

   <component>
      <observation classCode = "OBS" moodCode = "EVN" >
      <!-- ** Result observation (V3) ** -->
         <templateId root = "2.16.840.1.113883.10.20.22.4.2" extension = "2015-08-01" />
         <templateId root = "2.16.840.1.113883.10.20.22.4.2" />
         <id root = "107c2dc0-67a5-11db-bd13-0800200c9a66" />
         <code code = "718-7" displayName = "Hemoglobin" codeSystem = "2.16.840.1.113883.6.1"

             codeSystemName = "LOINC" />
         <statusCode code = "completed" />
        <effectiveTime value = "NI" />

         …

 

3.1.6         Rubric-6: Validation – Schema and schematron validation SHALL be the first step in rubric evaluation

 

Validation against CDA schema and C-CDA R2.1 Schematron SHALL occur as the first step in tooling that supports Rubric assessment.

3.1.6.1        Rubric Intent

The intent of this rubric is to encourage all C-CDA R2.1 rubric tooling to ensure only valid documents are assessed. Tooling should provide notification if an invalid document is presented for evaluation.

 

3.1.6.2        Examples

NA

 

3.1.7         Rubric-7: Validation – XML documents that do not pass schema and schematron SHALL NOT receive a grade.

 

XML documents that do not pass base xml schema and C-CDA R2.1 schematron without errors SHALL not receive a grade.

3.1.7.1        Rubric Intent

The intent of this rubric is to prevent end user misconception about document quality.

 

3.1.7.2        Examples

NA

 

3.2       Informational

 

3.2.1         Rubric-8: Template IDs SHALL have version dates in @extension

 

A C-CDA R2.1 document, SHALL have at least one of the C-CDA R2.1 templateIDs is asserted at /ClinicalDocument/templateId, and SHALL have a /ClinicalDocument/templateId/@extension indicating the version, represented with "YYYY-MM-DD". AND, all template IDs that are defined in C-CDA R2.1 templates or C-CDA R2.1 supplemental templates contained in that document  SHALL have at least one template ID with a templateId/@extension indicating the version, represented with "YYYY-MM-DD". Additional, non-C-CDA R2.1 templates identified by templateIDs MAY be present.

 

3.2.1.1        Rubric Intent

 

The intent of this rubric is to encourage use of the correct C-CDA R2.1 template IDs and the correct format of those IDs (with the version extension). However, additional template IDs are permitted in open templates. All C-CDA templates are open templates.

 

3.2.1.2        Examples

C-CDA Examples Task Force Link: ANY example: http://hl7-c-cda-examples.herokuapp.com/

 

Figure 13 : Template IDs with proper version identified in @extension

 

<!-- ** At the document level ** -->

<ClinicalDocument xmlns = "urn:hl7-org:v3" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns:voc = "urn:hl7-org:v3/voc" xmlns:sdtc = "urn:hl7-org:sdtc" >
   <realmCode code = "US" />
   <typeId extension = "POCD_HD000040" root = "2.16.840.1.113883.1.3" />
   <!-- CCD template ID-->
   <templateId root = "2.16.840.1.113883.10.20.22.1.2" extension = "2015-08-01" />
   <templateId root = "2.16.840.1.113883.10.20.22.1.2" />

 

<!-- ** At the entry level ** -->

<observation classCode = "OBS" moodCode = "EVN" >
   <!-- ** Allergy observation ** -->
   <templateId root = "2.16.840.1.113883.10.20.22.4.7" extension = "2014-06-09" />
   <templateId root = "2.16.840.1.113883.10.20.22.4.7" />

   <id root = "7d5a02b0-67a4-11db-bd13-0800200c9a66" />

</observation>

 

 

Figure 14 : Template IDs with no version identified in @extension

 

 

<!-- ** At the document level ** -->

<ClinicalDocument xmlns = "urn:hl7-org:v3" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns:voc = "urn:hl7-org:v3/voc" xmlns:sdtc = "urn:hl7-org:sdtc" >
   <realmCode code = "US" />
   <typeId extension = "POCD_HD000040" root = "2.16.840.1.113883.1.3" />
   <!-- CCD template ID-->
   <templateId root = "2.16.840.1.113883.10.20.22.1.2" />

 

<!-- ** At the entry level ** -->

<observation classCode = "OBS" moodCode = "EVN" >
   <!-- ** Allergy observation ** -->
   <templateId root = "2.16.840.1.113883.10.20.22.4.7" />

   <id root = "7d5a02b0-67a4-11db-bd13-0800200c9a66" />

</observation>

 

 

3.2.2         Rubric-9 effectiveTime and time lifespan

 

EffectiveTime and time element values SHALL be less than one year prior to recordTarget/patientRole/patient/birthTime/value and less than 90 days before:

 

1) recordTarget/patientRole/patient/sdtc:deceasedTime value

OR

 

2) Deceased Observation templateId root="2.16.840.1.113883.10.20.22.4.79"]/observation/effectiveTime/low @value.

 

 

Exception: Family history section [templateId “2.16.840.1.113883.10.20.22.2.15"]/entry/organizer[ templateId“2.16.840.1.113883.10.20.22.4.45" ]  /component/observation [TemplateId “2.16.840.1.113883.10.20.22.4.46"]/effectiveTime/@value SHALL be excluded from this rubric test

 

3.2.2.1        Rubric Intent

 

The intent of this rubric is to discourage non-sensical dating of entries and header time elements with a document instance.

 

3.2.2.2        Examples

C-CDA Examples Task Force Link: NA – Example task force focus is on sections and entries not whole documents and so comparison between header elements and entry time examples do not exist and are not planned.

 

Figure 15 : effectiveTime and Time within lifespan agreement – sdtc:deceasedTime

 

 

<!-- ** BirthTime ** -->

<birthTime value = "19450501" />
<!-- A full CDA example may include the Deceased Observation to indicate cause of death -->
<!-- A Deceased Observation may (also) be present in any section. Problem List is a suitable location -->
<sdtc:deceasedInd value = "true" />

<!-- ** Patient Deceased Time in header ** -->
<sdtc:deceasedTime value = "202003151500+0500" />

<!-- ** Example logical header times ** -->

<legalAuthenticator>
    <time value = "20200215223615-0500" />

<documentationOf>
   <serviceEvent classCode = "PCPR" >
   <effectiveTime>
        <low value = "19750501" />
        <high value = "20200315" />

<!-- ** Example logical entry effectiveTimes ** -->

<!-- ** Author -->

       … 

           <author>
<templateId root = "2.16.840.1.113883.10.20.22.4.119" />
<time value = " 202003151500+0500 " />

      …

<!-- ** Performer -->

          <performer>
               <time value = " 202003151400+0500" />

…..

<!-- ** Clinical Statements -->

  <!-- ** Point in time -->

  <effectiveTime value = "201909271300+0500" />

<!-- ** Range -->

<effectiveTime xsi:type = "IVL_TS" >
    <low value = "20191103" />
    <high value = "20191203" />
</effectiveTime>

 

Figure 16 : effectiveTime and Time within lifespan disagreement – sdtc:deceasedTime

 

 

<!-- ** BirthTime ** -->

<birthTime value = "19450501" />

<!-- A full CDA example may include the Deceased Observation to indicate cause of death -->
<!-- A Deceased Observation may (also) be present in any section. Problem List is a suitable location -->
<sdtc:deceasedInd value = "true" />

<!-- ** Patient Deceased Time in header ** -->
<sdtc:deceasedTime value = "202003151500+0500" />

<!-- ** Example illogical header times ** -->

<legalAuthenticator>
    <time value = "00000000000-0000" />

<documentationOf>
   <serviceEvent classCode = "PCPR" >
   <effectiveTime>
        <low value = "19750501" />
        <high value = "20250315" />

<!-- ** Example illogical entry effectiveTimes ** -->

<!-- ** Author -->

       … 

           <author>
<templateId root = "2.16.840.1.113883.10.20.22.4.119" />
<time value = " 202103151500+0500 " />

      …

<!-- ** Performer -->

          <performer>
               <time value = "0000000000 00+0000" />

…..

<!-- ** Clinical Statements -->

  <!-- ** Point in time -->

  <effectiveTime value = "000009271300+0000" />

<!-- ** Range -->

<effectiveTime xsi:type = "IVL_TS" >
    <low value = "20201103" />
    <high value = "20201203" />
</effectiveTime>

 

 

Figure 17 : effectiveTime and Time within lifespan agreement – deceased observation

 

 

<!-- ** BirthTime ** -->

<birthTime value = "19450501" />

<!-- ** Example logical header times ** -->

<legalAuthenticator>
    <time value = "20200215223615-0500" />

<documentationOf>
   <serviceEvent classCode = "PCPR" >
   <effectiveTime>
        <low value = "19750501" />
        <high value = "20200315" />

 

 

<entry>
    <observation classCode = "OBS" moodCode = "EVN" >

<!-- ** Deceased Observation Template ** -->
        <templateId root = "2.16.840.1.113883.10.20.22.4.79" extension = "2015-08-01" />
<id root = "6898fae0-5c8a-11db-b0de-0800200c9a77" />
<code code = "ASSERTION" codeSystem = "2.16.840.1.113883.5.4" />
<statusCode code = "completed" />
<effectiveTime>
       <low value = "202003151500+0500" />
</effectiveTime>
<value xsi:type = "CD" code = "419099009" codeSystem = "2.16.840.1.113883.6.96" displayName = "Dead" />
    </observation>
</entry>

<!-- ** Example logical entry effectiveTimes ** -->

<!-- ** Author -->

       … 

           <author>
<templateId root = "2.16.840.1.113883.10.20.22.4.119" />
<time value = " 202003151500+0500 " />

      …

<!-- ** Performer -->

          <performer>
               <time value = " 202003151400+0500" />

…..

<!-- ** Clinical Statements -->

  <!-- ** Point in time -->

  <effectiveTime value = "201909271300+0500" />

<!-- ** Range -->

<effectiveTime xsi:type = "IVL_TS" >
    <low value = "20191103" />
    <high value = "20191203" />
</effectiveTime>

 

Figure 18 : effectiveTime and Time within lifespan disagreement – deceased observation

 

 

<!-- ** BirthTime ** -->

<birthTime value = "19450501" />

<!-- ** Example illogical header times ** -->

<legalAuthenticator>
    <time value = "00000000000-0000" />

<documentationOf>
   <serviceEvent classCode = "PCPR" >
   <effectiveTime>
        <low value = "19750501" />
        <high value = "20250315" />

 

<entry>
    <observation classCode = "OBS" moodCode = "EVN" >

<!-- ** Deceased Observation Template ** -->
        <templateId root = "2.16.840.1.113883.10.20.22.4.79" extension = "2015-08-01" />
<id root = "6898fae0-5c8a-11db-b0de-0800200c9a77" />
<code code = "ASSERTION" codeSystem = "2.16.840.1.113883.5.4" />
<statusCode code = "completed" />
<effectiveTime>
       <low value = "202003151500+0500" />
</effectiveTime>
<value xsi:type = "CD" code = "419099009" codeSystem = "2.16.840.1.113883.6.96" displayName = "Dead" />
    </observation>
</entry>

<!-- ** Example illogical entry effectiveTimes ** -->

<!-- ** Author -->

       … 

           <author>
<templateId root = "2.16.840.1.113883.10.20.22.4.119" />
<time value = " 202103151500+0500 " />

      …

<!-- ** Performer -->

          <performer>
               <time value = "0000000000 00+0000" />

…..

<!-- ** Clinical Statements -->

  <!-- ** Point in time -->

  <effectiveTime value = "000009271300+0000" />

<!-- ** Range -->

<effectiveTime xsi:type = "IVL_TS" >
    <low value = "20201103" />
    <high value = "20201203" />
</effectiveTime>

 

 

3.2.3         Rubric-10 effectiveTime and time precision

 

If more than 1 instance of effectiveTime or Time is present where there are all zeros in the hours, minutes, and seconds locations (or more) then a warning SHALL be issued.

3.2.3.1        Rubric Intent

 

The intent of this rubric is to ensure that care is taken when specifying dates and times to only capture data with as much precision as is known.  The timestamp format allows for partial dates and partial times to be specified

 

3.2.3.2        Examples

C-CDA Examples Task Force Link: ANY example: http://hl7-c-cda-examples.herokuapp.com/

 

Figure 19 : Select Appropriate Precision vs Over Precise effectiveTime Examples

 

<!-- ** BirthTime ** -->

<!-- ** BirthTime - Likely correct precision in older child or adult ** -->

<birthTime value = "19450501" />

<!-- ** BirthTime - Likely excessive precision in older child or adult ** -->

<birthTime value = "194505010000-0000" />

<!-- ** Likely correct precision – entry example - observation ** -->

<entry>
    <observation classCode = "OBS" moodCode = "EVN" >

     …

          <effectiveTime>
       <low value = "2020031515+0500" />
          </effectiveTime>

 

<!-- ** Likely excessive precision – entry example - observation ** -->

<entry>
    <observation classCode = "OBS" moodCode = "EVN" >

     …

          <effectiveTime>
       <low value = "2020000000+0000" />
          </effectiveTime>

 

4         Header Specific Rubrics

4.1       Required

4.1.1         Rubric-11 Patient Name

 

If more than 1 patient name is present, recordTarget/patient/name @use SHALL be present and SHALL equal "L" on one of the patient element instances.

AND

  • If more than 1 patient name is present, recordTarget/patient/name @use SHALL be present and SHALL equal a value from EntityNameUse value set https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.1.11.15913/expansion/Latest OTHER than "L" on one of the patient element instances

      OR

  • patient/name ("part": family or given or prefix or suffix)/qualifier SHALL be present and SHALL equal a value from EntityPersonNamePartQualifier value set https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.26/expansion/Latest in any additional patient/name element instances

 

4.1.1.1        Rubric Intent

 

The intent of this rubric is to ensure that when multiple and alternative patient names exist in a document instance it is possible to determine the meaning or use of the different names and to ensure that at least one of the names is the patient’s legal name.

 

4.1.1.2        Examples

C-CDA Examples Task Force Link: TBD. Some examples on name part order and one example of name/part/qualifier exist: http://cdasearch.hl7.org/examples/view/a5c2321b-06e1-4141-88f2-0ac1b902748d

 

Figure 20 : Appropriate Multiple Name Example

<patient>
<!-- The "L" is "Legal" from the value set EntityNameUse 2.16.840.1.113883.1.11.15913 -->
<name use = "L" >
<given> Evangeline </given>
<!-- The "CL" is "Call Me" from value set EntityPersonNamePartQualifier 2.16.840.1.113883.11.20.9.26  -->
<given qualifier = "CL" > Eve </given>
<!-- The "SP" is "Spouse" from value set EntityPersonNamePartQualifier 2.16.840.1.113883.11.20.9.26  -->
<family qualifier = "SP" > Betterhalf </family>
<!-- The "BR" is "Birth" from value set EntityPersonNamePartQualifier 2.16.840.1.113883.11.20.9.26  -->
<family qualifier = "BR" > Everywomen </family>
</name>
<!-- The "A" is "Artist/Stage" from the value set EntityNameUse 2.16.840.1.113883.1.11.15913 -->
<name use = "A" >
<given> Starlight </given>
<family> Superwomen </family>
</name>

             …

  </patient>

 

Figure 21 : Inappropriate Multiple Name Example

<patient>
    <name>
         <given> Evangeline </given>
         <given > Eve </given>
         <family> Betterhalf </family>
         <family> Everywomen </family>
         <family> Superwoman </family>
      </name>
      <name>
           <given> Marci </given>
           <given > Jane </given>
           <family> Betterhalf </family>
    </name>

             …

  </patient>

 

 

4.1.2         Rubric-12 Patient birthTime value SHALL be precise to the day

4.1.2.1        Rubric Intent

 

The intent of this rubric is to encourage systems to capture and communicate the year and day of birth.

 

4.1.2.2        Examples

Figure 22 : Appropriate Precision of BirthTime Example

<!-- ** BirthTime ** -->

<!-- ** BirthTime - Correct precision in older child or adult ** -->

<birthTime value = "19450501" />

<!-- ** BirthTime – Acceptable precision in neonate** -->

<birthTime value = "202005011515-0800" />

 

Figure 23 : Inappropriate Precision of BirthTime Example

<!-- ** Imprecise BirthTime ** -->

<birthTime value = "1945" />

 

5         Section/Domain Specific Rubrics

This portion of document describes rubrics that are unique to attributes or elements in entries within the stated section. The examples in this portion of the document will include only appropriate/accurate examples rather than inappropriate examples. The inappropriate examples are simply the absence of the rubric requirement as opposed to alternate poor formatting. [GD1]

5.1       Required

5.1.1         Allergies

5.1.1.1        Rubric-13: Allergy - Intolerance Observation SHALL have a Reaction Observation

Allergy - Intolerance Observation TemplateID 2.16.840.1.113883.10.20.22.4.7 SHALL contain Reaction Observation (V2) (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.4.9:2014-06-09

nullFlavor in @value SHALL be permitted

5.1.1.2        Rubric Intent

The intent of this rubric is to require the presence of the reaction that occurred when a person was exposed to the represented allergen. The base standard only recommends the inclusion of the reaction (SHOULD). In addition, a null value is permitted within the reaction observation to encourage an assertion that the reaction is unknown if it is truly unknown.

5.1.1.3        Examples

C-CDA Examples Task Force Link: Allergy to PCN with Reaction: http://cdasearch.hl7.org/examples/view/46224f150dee048bc8f907116d285b332739d3a0

 

Figure 24 : Appropriate Presence of Allergy Reaction Observation Example

<observation classCode = "OBS" moodCode = "EVN" >
    <!-- ** Allergy observation (V2) ** -->
    <templateId root = "2.16.840.1.113883.10.20.22.4.7" extension = "2014-06-09" />
    <templateId root = "2.16.840.1.113883.10.20.22.4.7" />

    <participant typeCode = "CSM" >
    <participantRole classCode = "MANU" >

        <playingEntity classCode = "MMAT" >
               <code code = "70618" displayName = "Penicillin" codeSystem = "2.16.840.1.113883.6.88"

                codeSystemName = "RxNorm" />

        </playingEntity>

       </participantRole>
    </participant>

    <entryRelationship typeCode = "MFST" inversionInd = "true" >
          <observation classCode = "OBS" moodCode = "EVN" >
<!-- ** Reaction Observation (V2) ** -->
<templateId root = "2.16.840.1.113883.10.20.22.4.9" extension = "2014-06-09" />
<templateId root = "2.16.840.1.113883.10.20.22.4.9" />

      …

               <value xsi:type = "CD" code = "422587007" codeSystem = "2.16.840.1.113883.6.96"

               displayName = "Nausea" />

  <!-- ** OR – observation/value here is allowed to contain a null value** -->

            <value nullFlavor = "UNK" />

      …

</observation>

 

Figure 25 : Absence of Allergy Reaction Observation Example

<observation classCode = "OBS" moodCode = "EVN" >
    <!-- ** Allergy observation (V2) ** -->
    <templateId root = "2.16.840.1.113883.10.20.22.4.7" extension = "2014-06-09" />
    <templateId root = "2.16.840.1.113883.10.20.22.4.7" />

    <participant typeCode = "CSM" >
    <participantRole classCode = "MANU" >

        <playingEntity classCode = "MMAT" >
               <code code = "70618" displayName = "Penicillin" codeSystem = "2.16.840.1.113883.6.88"

                codeSystemName = "RxNorm" />

        </playingEntity>

       </participantRole>
    </participant>

<!-- ** Reaction Observation (V2) Should be here ** -->

      …

</observation>

 

5.1.1.4        Rubric-14: Allergy statements SHALL contain authorTime

In an Allergy statement, the SHALL be at least one authorTime: Either the Allergy Concern Act TemplateID 2.16.840.1.113883.10.20.22.4.30 OR the Allergy - Intolerance Observation TemplateID 2.16.840.1.113883.10.20.22.4.7 SHALL contain the Author Participation template

:2.16.840.1.113883.10.20.22.4.119 which SHALL contain author/time which SHALL NOT be nulled

5.1.1.5        Rubric Intent

The intent of this rubric is to encourage the provision of information that can be interpreted as the last time a clinician addressed or noted the allergy and to prevent sending of null values in the time attribute.

5.1.1.6        Examples

C-CDA Examples Task Force Link: C-CDA Examples Task Force Link: Allergy to PCN with author/time in the Allergy Concern Act AND the Allergy-Intolerance Observation: http://cdasearch.hl7.org/examples/view/46224f150dee048bc8f907116d285b332739d3a0

 

Figure 26 : Appropriate Author Times in Allergy Statements Example

<entry typeCode = "DRIV" >
<act classCode = "ACT" moodCode = "EVN" >
<!-- ** Allergy Concern Act (V3) ** -->
<templateId root = "2.16.840.1.113883.10.20.22.4.30" extension = "2015-08-01" />
<templateId root = "2.16.840.1.113883.10.20.22.4.30" />
                                 …
<author typeCode = "AUT" >
<templateId root = "2.16.840.1.113883.10.20.22.4.119" />
<!-- Same as Concern effectiveTime/low -->
<time value = "199805011145-0800" />
<assignedAuthor>
<id extension = "555555555" root = "2.16.840.1.113883.4.6" />
<code code = "207QA0505X" displayName = "Adult Medicine"

                                                                codeSystem = "2.16.840.1.113883.6.101"

                                                                codeSystemName = "Healthcare Provider Taxonomy (HIPAA)" />
</assignedAuthor>

                                  <!-- ** AND/OR** -->

                                             <entryRelationship typeCode = "SUBJ" >
                                  <observation classCode = "OBS" moodCode = "EVN" >
                  <!-- ** Allergy observation (V2) ** -->
                <templateId root = "2.16.840.1.113883.10.20.22.4.7" extension = "2014-06-

                                                 09" />
               <templateId root = "2.16.840.1.113883.10.20.22.4.7" />
               <id root = "4adc1020-7b14-11db-9fe1-0800200c9a66" />
               <code code = "ASSERTION" codeSystem = "2.16.840.1.113883.5.4" />
              <text>
  <reference value = "#allergytype1" />
              </text>
                                           ….
              <author typeCode = "AUT" >
    <templateId root = "2.16.840.1.113883.10.20.22.4.119" />
    <time value = "199805011145-0800" />
    <assignedAuthor>
        <id extension = "222223333" root = "2.16.840.1.113883.4.6" />
        <code code = "207KA0200X" displayName = "Allergy"

                                                       codeSystem = "2.16.840.1.113883.6.101" codeSystemName = "Healthcare

                                                        Provider Taxonomy (HIPAA)" />
</assignedAuthor>
              </author>

                                   …

 

 

 

5.1.2         Encounter

5.1.2.1        Rubric-15: If an encompassingEncounter is present in a document and encounterActivity(s) are present in the body of the document, at least one of encounterActivity(s) SHALL exist and SHALL not conflict with the encompassingEncounter

 

Where encompassingEncounter is present in the C-CDA R2.1 header AND Encounter Activitie(s) in EVENT mood are present in the body of the document, then the encompassingEncounter date/time and ID and effectiveTimes SHALL equal at least one of the Encounter Activity encounter/IDs and its encounter/effectiveTime(s) in the body of the document.

 

5.1.2.2        Rubric Intent

 

The intent of this rubric is to ensure that a document with an encompassingEncounter AND encounter activities should reiterate the encompassing encounter information in an encounter activity and that the information must align.

 

5.1.2.3        Examples

 

C-CDA Examples Task Force Link: ANY Encounter example to view encounter activity representation: http://hl7-c-cda-examples.herokuapp.com/sections/Encounters

 

 

Figure 27 : encompassingEncounter and encounter Activity Alignment

<!-- ** EencompassingEncounter ** -->

<componentOf>
    <encompassingEncounter>
        <id extension = "31528" root = "1.2.840.114350.1.13.6289.1.7.8.698084.8" />
        <effectiveTime>
            <low value = "20160618115807-0500" />
            <high value = "20160625150000-0500" />
        </effectiveTime>
       <!-- This encompassingEncounter SHALL contain exactly one [1..1] dischargeDispositionCode,
       which SHOULD be selected from ValueSet NUBC UB-04 FL17 Patient Status

        urn:oid:2.16.840.1.113883.3.88.12.80.33 DYNAMIC (CONF:1198-8476). -->
        <dischargeDispositionCode code = "1" codeSystem = "2.16.840.1.113883.3.88.12.80.33"
           codeSystemName = "National Uniform Billing Committee (NUBC)"
            displayName = "Discharged to Home or Self Care (Routine Discharge)" />


    <!-- ** Encounter Activity** -->


<entry typeCode = "DRIV" >
    <encounter classCode = "ENC" moodCode = "EVN" >
         <!-- ** Encounter Activity (V3) ** -->
         <templateId root = "2.16.840.1.113883.10.20.22.4.49" extension = "2015-08-01" />
         <templateId root = "2.16.840.1.113883.10.20.22.4.49" />
          <id extension = "31528" root = "1.2.840.114350.1.13.6289.1.7.8.698084.8" />
          <!-- CPT code should be used for ambulatory visits, but for a hospitalization, another codeSystem

             is more appropriate - translation to an HL7 Act Encounter code shown-->
         <code code = "99238" displayName = "Discharge day management services"   

          codeSystem = "2.16.840.1.113883.6.12" >
<originalText>
    <reference value = "#Enc1_Type" />
</originalText>
<translation code = "IMP" codeSystem = "2.16.840.1.113883.5.4" displayName = "Inpatient"

                  codeSystemName = "Act Encounter Code - Act Code" />
             </code>
             <effectiveTime>
    <low value = "20160618115807-0500" />
                    <high value = "20160625150000-0500" />
             </effectiveTime>
             < sdtc:dischargeDispositionCode code = "1" codeSystem = "2.16.840.1.113883.3.88.12.80.33"  

              codeSystemName = "National Uniform Billing Committee (NUBC)" displayName = "Discharged to

              Home or Self Care (Routine Discharge)" />

             …..

     </encounter>

</entry>

 

 

5.1.3         Goals

 

5.1.3.1        Rubric-16: Relating Goals in a Care Plan Document Type

If a Goal Observation

[observation: identifier urn:oid:2.16.840.1.113883.10.20.22.4.121 is present, then it SHALL contain either an Entry Reference

[act: identifier urn:oid:2.16.840.1.113883.10.20.22.4.122 2015-08-01 which points to/contains the ID of a Health Concern Act (V2)

[act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.132:2015-08-01 OR a Problem Observation (V3)

[observation: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.4:2015-08-01 within the document, or be contained by, or contain a Problem Observation (V3)

[observation: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.4:2015-08-01 or Health Concern Act (V2)

[act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.132:2015-08-01 using the REFR actRelationshipType.

5.1.3.2        Rubric Intent

5.1.3.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.3.4        Rubric-17

5.1.3.5        Rubric Intent

5.1.3.6        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.3.7        Rubric-18

5.1.3.8        Rubric Intent

5.1.3.9        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.4         Immunizations

5.1.4.1        Rubric-19

5.1.4.2        Rubric Intent

5.1.4.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.5         Medications

5.1.5.1        Rubric-20

5.1.5.2        Rubric Intent

5.1.5.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.5.4        Rubric-21

5.1.5.5        Rubric Intent

5.1.5.6        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.5.7        Rubric-22

5.1.5.8        Rubric Intent

5.1.5.9        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.5.10    Rubric-23

5.1.5.11    Rubric Intent

5.1.5.12    Examples

C-CDA Examples Task Force Link: ANY example:

5.1.5.13    Rubric-24

5.1.5.14    Rubric Intent

5.1.5.15    Examples

C-CDA Examples Task Force Link: ANY example:

5.1.6         Problems

5.1.6.1        Rubric-25

5.1.6.2        Rubric Intent

5.1.6.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.6.4        Rubric-26

5.1.6.5        Rubric Intent

5.1.6.6        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.6.7        Rubric-27

5.1.6.8        Rubric Intent

5.1.6.9        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.7         Results

5.1.7.1        Rubric-28

5.1.7.2        Rubric Intent

5.1.7.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.8         Social History

5.1.8.1        Rubric-29

5.1.8.2        Rubric Intent

5.1.8.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.8.4        Rubric-30

5.1.8.5        Rubric Intent

5.1.8.6        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.9         Vital Signs

5.1.9.1        Rubric-31

5.1.9.2        Rubric Intent

5.1.9.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.1.9.4        Rubric-32

5.1.9.5        Rubric Intent

5.1.9.6        Examples

C-CDA Examples Task Force Link: ANY example:

 

5.2       Informational

5.2.1         Allergies

5.2.1.1        Rubric-33

5.2.1.2        Rubric Intent

5.2.1.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.2.2         Goals

5.2.2.1        Rubric-34

5.2.2.2        Rubric Intent

5.2.2.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.2.2.4        Rubric-35

5.2.2.5        Rubric Intent

5.2.2.6        Examples

C-CDA Examples Task Force Link: ANY example:

5.2.3         Medications

5.2.3.1        Rubric-36

5.2.3.2        Rubric Intent

5.2.3.3        Examples

C-CDA Examples Task Force Link: ANY example:

5.2.4         Results

5.2.4.1        Rubric-37

5.2.4.2        Rubric Intent

5.2.4.3        Examples

C-CDA Examples Task Force Link: ANY example:

6         References

 

This link is where the current rubric is located, where you can find more information about the process for creating a rubric, and where you can find call information.

The Consolidated CDA (C-CDA) implementation guide contains a library of CDA templates, incorporating and harmonizing previous efforts from Health Level Seven (HL7), Integrating the Healthcare Enterprise (IHE), and Health Information Technology Standards Panel (HITSP). It represents harmonization of the HL7 Health Story guides, HITSP C32, related components of IHE Patient Care Coordination (IHE PCC), and Continuity of Care (CCD).  

The C-CDA Scorecard leverages the work completed by an ONC-funded grant   SMART (Substitutable Medical Apps Reusable Technologies)   and promotes best practices in C-CDA implementation by assessing key aspects of the structured data found in individual documents. It is a tool designed to allow implementers to gain insight and information regarding industry best practice and usage overall. It also provides a rough quantitative assessment and highlights areas of improvement which can be made today to move the needle forward.  

 

 

 

 

 


[GD1] If exceptions after building this portion – mention here