This wiki has undergone a migration to Confluence found Here
C-CDA 2.1 Companion Guide Project
Revision as of 14:58, 17 March 2016 by Benjamin Flessner1 (talk | contribs) (→Issues/Guidance To Consider for Inclusion: Add immunizations)
Return to SDWG page.
Return to C-CDA: Enhancing Implementation (ONC Grant Project) page.
Contents
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 (still to be held)
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
- 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.
- 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)
- Clarity on how to represent implantable devices and the representation of UDI information (CDA Examples Task Force 3/10/2016)
- Guidance on effectiveTime for immunizations (do not use low+high when moodCode=EVN) per DSTU Comment #945
Deliverables for Review
- Draft Companion Guide CCDS Requirements Mapping.xlsx (Deprecated in favour of the requirements mapping below)
- 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.