CDA+-+Publication+Issues

 flat

=Active Publication Consideration Issues= (From: Andrew McCaffrey) || Several versions ago, the HITSP/C32 pointed directly at the HL7 CCD document, including the HL7 CCD document template ID. This CCD document template ID set the document code to LOINC 34133-9 (Summarization of Episode Node). However, starting with HITSP/C32 v2.4, the direct link from C32 to CCD was (deliberately) broken. The philosophy became that C32 would point at sections and entries in HITSP/C83 and HITSP/C83 would point to CCD. When that change occurred, there was no longer a direct link from a C32 document level template to a CCD document level template. As far as we could tell, there was no explicit rule which stated that a C32 document has an "IS A" relationship to a CCD, although it did reuse CCD section and entry templates. (If you feel we've overlooked something in C32 or C83, please let us know\!)
 * **Issue ID** || **Document Reference** || **Issue Title** || **Comment** || **Disposition Description** ||
 * 11051 || HITSP-C32 - Registration and Medication History || C32 Document Code not specified

There is actually some precedent for this. Several IHE Patient Care Coordination (PCC) document types have made the distinction between a IHE PCC document type that is a CCD document (plus some IHE constraints) and an IHE PCC document type that is not a CCD document but which reuses CCD templates at the section and entry level.

Is the lack of a link from the C32 document template ID to the CCD document template a deliberate decision to allow for the use of multiple document LOINC codes in a C32? Or is this an oversight and there should be a rule added to C32 that requires the existence of the CCD template ID? || The link was not deliberately broken. The C32 resolved to IHE XPHR which used the CCD. The format of the new HITSP template may have made the intention unclear. || The VLER IPO Data Exchange Workgroup discovered that, occasionally, different organizations inserted similar sections into different places/depths in the XML structure. Example of XPath Variations forProblem Onset Date: Each C32 field, both the coded and the valid text representation options, should have full XPaths included in the specification (including classCodes and typeCodes, when relevant). ||  || (Back to the Top)
 * V.A.-18 || HITSP/C83 || Multiple Allergy Reactions, One Severity || Make it clear that an Allergy may have 1-Many Allergy Reactions, but only 1 Severity || Decided to refer VA Issue #18 back to the Harmonization WG ||
 * V.A.-21 || HITSP/C83 || Full Xpaths Needed for Data Elements || The current specifications typically only have the very end of the XPath explicitly indicated. There are many cases where it is unclear (ambiguous) exactly how these end XPaths should be anchored. Thus, implementers may select different full XPaths for the same field.
 * Org 1 - entry/act/effectiveTime/low/@value
 * Org 2 - entry/act/entryRelationship/observation/effectiveTime/low/@value
 * V.A.-22 || Reference C32 Stylesheet || Request for a Reference C32 Stylesheet || A reference style sheet should enable viewing of all fields, both code and text, via all options that are considered valid (e.g., originalText, displayName, using references, code without display). Such a reference style sheet will provide numerous benefits:
 * A robust template for organizations to start their own customized style sheets
 * A helpful adjunct to validation---especially for the textual representations, which the NIST validator currently does not provide
 * A valuable, high-usability testing tool || We are searching for an existing C32 stylesheet that satisfies the needs of VA Issue #22 and VA Issue #23. ||
 * V.A.-23 || Reference C32 Document, Fully Populated || Request for a Reference C32 Stylesheet || A sample C32, with all possible fields populated in preferred and valid alternative methods, should be provided. o Explicit examples should also be provided for how to deal with fields for which a specified code is unavailable (i.e., how nullFlavor entries should be done). || We are searching for an existing C32 stylesheet that satisfies the needs of VA Issue #22 and VA Issue #23. ||

=Resolved Publication Consideration Issues= (Back to the Top)
 * **Issue ID** || **Document Reference** || **Issue Title** || **Comment** || **Disposition Description** ||
 * V.A.-19 || HITSP/C83 || Sample XML Needed for ALL (R, R2,O) Data Elements || Documentation must include sample XML for all data elements (R, R2, O) for all content modules. For example, there are 40 data elements in the Medication module, but there is not sample XML for all of them. This requires the implementer to develop/construct the XML. When this happens, the VA-DOD-KP-MedVA exchange has found that this is when multiple methods may be chosen and results in partner-to-partner harmonization to support display in each implementers user interface. || Documentation WG tentatively agreed to include sample XML for all data elements. ||
 * V.A.-20 || HITSP/C83 || Required/SHALL constraints that cannot be satisfied || Documentation should address Required/SHALL constraints that cannot be satisfied \- Does the implementer omit the entry or the content module, or what is the correct XML syntax for nullFlavor? || The group had previously agreed that there would be an introduction section that will explain how to use flavors of null. ||

=Out of Scope= (Back to the Top)
 * **Issue ID** || **Document Reference** || **Issue Title** || **Comment** || **Disposition Description** ||
 * V.A.-24 || C32 Data Element Spreadsheet || Request for a C32 Data Element Spreadsheet || The VLER partners found a spreadsheet that would have a consolidated list of the CCD (e.g.: custondian, legal authenticator) AND C32 fields and the required value sets for those fields (except for extensive vocabularies, such as SNOMED CT and RxNorm) greatly helpful. A verified, publicly available spreadsheet would likely be valuable for other implementers as well.
 * The XPath mapping could be integrated into this same spreadsheet. || Decided to defer this issue past the April ballot. Although not part of the ballot approval, the Documentation WG may provide this as implementer support for later. ||