C-CDA 2.1 Companion Guide Project

Return to SDWG page.

Return to C-CDA: Enhancing Implementation (ONC Grant Project) page.

Overview

This page supports the HL7 Contract work for the C-CDA R2.1 Companion Guide Project. This project's goal is to produce a new C-CDA Companion Guide to support C-CDA R2.1 and to provide more context in assisting implementers. The purpose of the new Companion Guide is to:

• Supplement the C-CDA R2.1 Implementation Guide to provide additional context to assist implementers and connect them to tools and resources
• Map the common clinical data set (CCDS) to the appropriate C-CDA locations
• Provide technical guidance for representing the 2015 Ed. CEHRT data requirements using the C-CDA Implementation Guide
• Include clinically-valid examples of C-CDA components necessary to meet 2015 Ed. CEHRT requirements
• Recommend an approach to implementations using the C-CDA IG to meet the needs of clinicians and achieve ONC Certification

Resources

To assist with finding "pain points" for implementers, the following initiatives have been taken:

• HL7 C-CDA R2.1 Implementer Survey
• C-CDA Implementation-a-Thon 1
• C-CDA Implementation-a-Thon 2

Issues/Guidance To Consider for Inclusion

• examples (vetted by the Examples Task Force)
• general nullFlavor clarification on how to use and when it is allowed - including examples where valuesets are explicitly declared (e.g. code SHALL be selected from valueset XXX)
• clear conformance statement guidance - i.e. what does SHALL mean as compared to SHOULD or MAY
• discussion re: guidance on narrative text representation
  • (george cole adds the following) we have focused so intently on the discrete content that we've forgotten the challenges of presenting relevant and pertinent content to providers in a meaningful manner. There are some challenges we face with the text element. Some example topics of interest are:
    • representation of content so that any stylesheet can render the document
    • what we'll call the major / related child / related grandchild rendering challenge; how to best represent, how deep to go, ...
      • example: The Interventions Section may contain Planned Intervention Acts, which, besides a whole list of other content, may contain Nutrition Recommendations which, besides a whole list of other content, may contain Planned Medications which may contain Indications (and there are probably more complicated examples)
    • styleCode attribute values - would the industry ever consider moving to a broad set of styleCode values, possibly as defined by the IHE MCV profile?
    • support for multiple views: providers and patients may prefer different views (see MCV above)
    • codes, for example ICD-10 or UDI: which ones are appropriate to display, and when should they not be displayed?
• how to represent gender identity concepts - i.e. beyond administrativeGender value set
• how to represent no known (allergies, meds, etc.)
• how to represent no information about (allergies, meds, etc.)
• guidance for CCDS sections when they are not noted as being part of the base document template
• guidance on how to represent medications for discharge summaries where one could have admission meds, administered meds and discharge meds (and possibly in addition to a medications section)
• examples for detailed race and detailed ethnicity and use of the sdtc extension
• language code clarification as per http://www.hl7.org/dstucomments/showdetail_comment.cfm?commentid=806

  ONC 2015 certification references RFC 5646 which states in 2.2.1 Primary Language Subtag: 

  "When languages have both an ISO 639-1 two-character code and a three-character code (assigned by ISO 639-2, ISO 639-3, or ISO 639-5), only
  the ISO 639-1 two-character code is defined in the IANA registry.

  When a language has no ISO 639-1 two-character code and the ISO 639-2/T (Terminology) code and the ISO 639-2/B (Bibliographic) code
  for that language differ, only the Terminology code is defined in the IANA registry.  At the time this document was created, all languages
  that had both kinds of three-character codes were also assigned a two-character code; it is expected that future assignments of this
  nature will not occur."

• using open templates vs. closed templates
• how to represent pregnant / not-pregnant / unknown
• Guidance on timestamp representation.
• Guidance on how extensions work and where the CDA Schema file is published, how to use schematron; responsibilities of content consumers to validate CDA's or not; best practice on how to process information from invalid CDA's
• Guidance on "What information goes where?" Need to explain that the section definitions constrain what information can be placed in various sections of a document. For example: Pain scale assessment information should not be placed in the Vital Signs section, etc. The Purpose Statement of each section template defines the content allowable in that section.

• • We just had a conversation in the examples task force about correct representation of UTC times. Some people weren’t clear that US ET was -0500 at the end of a timestamp. There is clear documentation for the TS in datatypes documentation. We find that many CDA documents in the wild don’t have the UTC offset information recorded correctly.
• Guidance on best practices for representation of displayName attributes
  • Use display names that come from the code system….so for example, for LOINC you would need to use either the long name or the short name in LOINC for the coded concept being used. (This should be in the datatypes specs in Data Types R2, and we are applying it as longstanding HL7 practice that the task force has established as a best practice.)
• Guidance on what the effectiveTime information means in a Result Organizer vs. the effectiveTime in the Result Observation components within the organizer.
  • DSTU Comment #938 has been added to add clarity in the C-CDA templates that the Organizer/effectiveTime should be the biologically relevant time (ie the specimen collection time or the time when images were taken). The effectiveTime on the observations may be the same, but could be different if the observation completes
• Guidance on what to put in Health Concerns and Problems sections, since both are required in Transition of Care documents for MU3. This guidance has already been written and approved by SDWG and PCWG. (David Tao)
• Guidance on what to put in Goals and Plan of Treatment sections, since both are required in Transition of Care documents for MU3. This guidance has already been written and approved by SDWG and PCWG. (David Tao)
• Guidance from the SDWG Relevant and Pertinent project (assuming it is available in time for the Companion Guide). In general, the topics in this list are technical, but there should also be some clinical guidance as to usefulness and value of various types of information. While such guidance would not be binding because the clinical judgment of the provider creating a document will take precedence over generic guidance in the Companion Guide, it is good to inform the CG with clinical perspectives, of which the Relevant & Pertinent Project is one example. (David Tao)
• Device information and UDI (Brett)
  • Clarity on how to represent implantable devices and the representation of UDI information (CDA Examples Task Force 3/10/2016).
  • Clarity on how to include no implanted devices (CDA Examples Task Force)
  • Consider recommendation from implementation-a-thon to include all devices in the Medical Equipment section in addition to procedures section even if procedure to implant is known.
• Guidance on effectiveTime for immunizations (do not use low+high when moodCode=EVN) per DSTU Comment #945
• Guidance on the value of the substanceAdministration/statusCode/@code for Immunizations, comparing administered immunizations versus immunizations Not Given with a Refusal Reason. Seems that CDA Examples Task Force and proposed certification test data differ on the value used for a refused immunization. (George Cole)
• Include guidance on new LOINC code based upon DSTU Comment 964. Per 2015 final rule: We have revised “body weight measured” to “body weight". These are two different LOINC codes. The DSTU Comment resolution is to add the new LOINC code to the dynamic value set, and to remove the previously used code. Implementers need to be aware of this change. (George Cole)
• Guidance for the requirement to support CLIA requirements in C-CDA. What was the consensus when this topic was discussed on a recent SDWG meeting? (george cole)
  • Specific changes to (e)(1) Data Sets for VDT: (PDF Files)
    • Ambulatory Sample 1 and Inpatient Sample 1:
      • Added Lab Location Details to meet CLIA requirements.
      • Added Diagnostic Imaging Report Information per HL7 guidance.
• Include guidance to clarify use of negationInd
• Include guidance on Date/Time precision - what level of precision should be included; what does it mean to pad out a date/time with zeros (implied precision that isn't really accurate?)
• Guidance on consistent placement of admission and discharge dates (or visit times if ambulatory). We currently don't use these terms in our guide. (Brett - DoD/VA IPO)
• Allergies and problems should always have time recorded in EHR included in CCD. Author.time is required ('last modification date') in the rule (Brett - DoD/VA IPO).
• Guidance on medication boundaries (e.g.: "20151225" includes only the first instant of Christmas, not the whole day), but that in practice folks mean entire day (Brett - DoD/VA IPO).
• Guidance that encounter diagnosis belongs in the encounter section (Brett - DoD/VA IPO)
• Medication ordered vs dispensed is inconsistently implemented (Brett - DoD/VA IPO)
• Guidance on appropriate place to embed a clinical note (Brett - DoD/VA IPO)
• Many sites are using CCD as a single-encounter document. Provide guidance on to do this appropriately (Brett - DoD/VA IPO).
• Add guidance for how to record the time interval of data in a section see Section Timestamp example (Brett - DoD/VA IPO).
• Care Team - Please review and carry forward guidance from the original companion guide (Brett - DoD/VA IPO)

Deliverables for Review

• Draft Companion Guide Requirements Mapping.zip contains the Draft Meaningful Use mappings. It contains two files: the actual Mappings spreadsheet and a Readme file that explains how to interpret the spreadsheet. The Readme will become part of the actual Companion Guide document upon its release.
• Deprecated Draft Companion Guide CCDS Requirements Mapping.xlsx (Deprecated in favour of the requirements mapping below)