Companion+Guide+Draft+2+Feedback

This page will be used to capture feedback on the draft version of the Companion Guide, beginning on August 23, 2012. At this time, the SWG is requesting feedback on the analysis contained in the Companion Guide. To provide feedback, please add your name, organization, section or sub-section you are providing feedback on, and your comments. If you would like to respond to any of the comments provided, please do so using the discussion board, which is accessible through the navigation bar in the upper right hand corner of the page.

Community Feedback on Draft 2 of Companion Guide
Per verbiage from the final rule - "For medications, it should be interpreted as the last date the medication was documented, ordered, prescribed, refilled, dispensed or edited." || This comment was discussed during the 9/17 SWG meeting. Consensus was to include narrative that indicates that we recognize that the rule contains guidance, and explain our interpretation. ||
 * = **Name** ||= **Organization** ||= **Section** ||= **Comments** ||= **Resolution of Comments** ||
 * Ruth Berge || GE HCIT || No section || Previous testing for MU 2011 reports revealed that having the right version of vocabulary was almost as important as the vocabulary. However nowhere in this Companion guide or in the CCDA Implementation Guide (which is probably not appropriate) is there an example of how to code this situation. If, for example, I receive a LOINC code for version 2.00 then what should my system do with that (where the prescribed version is now 2.40). Conversely how to code this for a document being created. The CDA doesn't provide a version with the vocabulary. If the only LOINC code I have for a test is the wrong version, then what to do? || This comment was discussed during the 9/24 meeting. The samples did not demonstrate including "codeSystemVersion" as an optional attribute, but it is included as a base capability and is likely an encouraged field. The version used should be the version specified by MU2. This discussion is out of scope for the Companion Guide, but will be brought to the attention of the HL7 SDWG for future discussion. ||
 * Emma Jones || Allscripts ||  || Is there guidance on how to indicate "Updated"?
 * Emma Jones || Allscripts || Patients(page74) || MU2 Final rule requires that ability to indicate that a patient declined to specify his or her race, ethnicity, and/or preferred language. Assuming we will need to "share" this information, C-CDA does not seem to have an applicable flavor of null for this. Guidance need as to how we should handle this requirement. || Included guidance on the value set containing a code to indicate unknown/declined to provide ||

Archive of Community Feedback on Draft 1 of Companion Guide
Hoggle || Academy of Nutrition & Dietetics || 2.35 || Page 21: Figure 4 shows the basic Null flavor schema. Later in this section, the comment is made under the Irrelevant/Not Pertinent Data Section that: “…the MSK null flavor might be interpreted by some person to apply in these circumstances.” MSK needs to be defined in this section for the statement to be understood. || Added definition of MSK || Hoggle || Academy of Nutrition & Dietetics || 5.2 || Page 53: Recommended Conformance: Per previous meetings of the IG, I have asked that the following comment be modified. //"MAY: truly optional; can be included or omitted as the author decides with no implications; ToC Priority "B" and no [proposed] MU2 requirement.This is not consistent with the original work of the CEDD. Neither food allergies or diet order are included in MU2, however this WAS included in the original work of the Transitions of Care. Omission of these components in a transition document is a safety risk and this needs to be addressed in the Companion Guide. I will be glad to provide additional information. || Conformance verbs are directly drawn from Consolidated CDA. Text clarifying clinical relevance has been added. The CIM consensus document confirms the “B” priority designation for Diet. The Companion Guide is focused on MU2 implementations for the community, additional ToC section-level guidance can be considered for future drafts. || and, change Summary of Care Record to ToC/Referral Summary ( I think that's the name used in the Final Rule) || Updated for Final Rule summary types || Data Portability requirement. || Encounter diagnoses guidance has been updated to reflect the final rule ||
 * = **Name** ||= **Organization** ||= **Section** ||= **Comments** ||= **Resolution of Comments** ||
 * Lindsey Hoggle || Academy of Nutrition & Dietetics || 2.2.1 || Page 14: First paragraph, last sentence: "The templates are designed in order to create standardized clinical documents—//__but individualized to the patient’s specific situation__--// that are specifically intended to support provider workflows in various cases." The fact that documents should be individualized to the patient needs to be reiterated. || Added content to further explain this point ||
 * Lindsey Hoggle || Academy of Nutrition & Dietetics || 2.3.1 || Page 18: The receiving system is not required to parse the structured entries (discrete fields) in the additional sections, but it must be able to display the entire CDA document, including narrative blocks, in human readable form. || Added content on Open and Closed templates (additional sections); semantic interoperability; restructured section 2 intro for flow ||
 * Lindsey
 * Lindsey Hoggle || Academy of Nutrition & Dietetics || 3.42 || Indicated Sections: This section is confusing. There were multiple different work groups within the ToC Initiative and the results of the consensus of these groups need to be represented in this Companion Guide. I am unable to access hyper linked references from the present draft document. || The hyperlinks go to Companion guide sub-sections, added clarification ||
 * Lindsey
 * Lindsey Hoggle || Academy of Nutrition and Dietetics || 5.6.1 || Page 58: Discharge Diet –Change “May” to “Should.” In any transfer of a patient to a receiving facility, the regulations are that a diet order HAS TO BE written by a physician in order for a patient to be fed. In instances where this is NOT sent to the receiving facility, the patient must remain NPO (No food/beverage) until an order is received. Receiving Providers in Facilities see patients (many times frail patients) going without food/water for up to 72 hours (over a weekend), having tube feedings sent without flush orders (whereby the patient becomes dehydrated) and having a receiving provider randomly order a regular diet for a received patient with no diet order--only to observe that the patient later aspirated and died because he was a stroke patient. || This is consistent with the conformance verbs discussed during the meeting on 7/30. Discharge Diet is a “B” object as of the ToC CIM consensus 8/2011 with no associated MU2 data requirement. ||
 * Lindsey Hoggle || Academy of Nutrition and Dietetics || 5.3 || Page 53: See Requirements Mapping Spreadsheet available via the Wiki: this is an unrealistic request for the reader of the Companion Guide. Many regular participants of the S&I Framework have commented that the wiki is not intuitive. All content for the Companion Guide should be included in the document, appendix and/or a URL for the reader to easily access. || Appendices will be added to show mappings for ToC to C-CDA. ||
 * Lindsey Hoggle || Academy of Nutrition & Dietetics || N/A || I was unable to participate in last week's Monday 5 PM meeting due to conflicting responsibilities, however I do not see the Minutes or a Summary to catch up on progress. || The minutes have posted and are available here. ||
 * Ed Larsen || SDS Team || 1 || It might be helpful to have a Venn or other diagram to help explain relationship/content of C-CDA, MU2 and ToC. The Introduction starts with ToC, then its relationship to C-CDA and then MU2 but that is not the outline of the Companion Guide. || Good suggestion - working on a visual. ||
 * Ed Larsen || SDS Team || 2.3.5 || Pg 22 - Irrelevant - first para - what is MSK null flavor - typo or just not previously defined? || Added definition of MSK ||
 * Ed Larsen || SDS Team ||  || Could Table 3 be reference in text as an example. || With the final rule, the layout (not content) will change to reflect the data sets specified in MU2. ||
 * Ed Larsen || SDS Team || 3.4.5.1 || Is it the Companion Guide intent (and MU 2 does not address) that a patient receiving discharge instructions receives (view, download, transmit) an entire SOCR / Discharge Summary || Guidance will be added to reflect final rule “selected by the patient” ||
 * George Cole || Allscripts || Executive Summary || make clear we are referencing the July 2012 version of C-CDA. Change this:Draft Standard for Trial Use(DSTU) Release 1.1 - US Realm, or "The Consolidated CDA," which was first published in December 2011.To this:Draft Standard for Trial Use(DSTU) Release 1.1 - US Realm, or "The Consolidated CDA,", July 2012. || Changes implemented ||
 * George Cole || Allscripts || 1.2.1 || I know that I have not addressed all of the changes introduced by the Final Rule, but trying to call out some as I see them, so add to the list of MU 2 Objectives: data Portability
 * Gerge Cole || Allscripts || 2.3.1 || Would like to see included the idea that the Sender Should include a style sheet processing instuction, and the Receiver Should attempt to honor any included style sheet processing instruction. Thus, the sender knows that any receiver may view the document exactly as was viewed during provider attestation. For some text about this, see, for example, IHE_PCC_TF_Rev7-0_Vol_1_2011-09-09.pdf, Section 3.4.1.1 View Option "A Content Creator Actor should provide access to a style sheet that ensures consistent rendering of the medical document content as was displayed by the Content Consumer Actor. The Content Consumer Actor shall be able to present a view of the document using this style sheet if present." And from IHE_PCC_TF_Rev7-0_Vol_2_2011-09-09.pdf, Section 3.1.1 View Option: "Render the document for viewing. This rendering shall meet the requirements defined for CDA Release 2 content presentation semantics (See Section 1.2.4 of the CDA Specification: Human readability and rendering CDA Documents). CDA Header information providing context critical information shall also be rendered in a human readable manner. This includes at a minimum the ability to render the document with the stylesheet specifications provided by the document source, if the document source provides a stylesheet. Content Consumers may optionally view the document with their own stylesheet, but must provide a mechanism to view using the source stylesheet." || Feedback discussed during meeting on 9/10 - the SWG agreed to incorporate language ||
 * George Cole || Allscripts || 2.3.5 || Irrelevant (Not Pertinent) Data. This is a Really important section - no other guide will offer any advice on this topic. I think the guidance is less than clear and convincing, or maybe we just need to say some more. The specific example of ..'results are not pertinent…', even when results are required, is incomplete and, without either a use of a nullFlavor at the section level, or a specific result observation and result entry, would not pass validation. This needs work, and consult with the Validator group (MDHT ? ) to determine what to recommend.OR, and I'm also a firm believer in this: we document that Not All Documents will pass MU 2, and that when there are not pertinent data we have a case where we Should output something, knowing that it is not going to pass an MU 2 validation. (I think some of this is addressed in Appendix A, but needs to be called out here if the recommendation is to output something that will not pass MU 2 || Follow-up with SDWG for clarification on null values for sections and discuss with MDHT Team. ||
 * George Cole || Allscripts || 3.2.3.1 || 3.2.3.1 Record Target XML Example Very Nice. Important to add a note: The Consolidated CDA allows (encourages???) the use of multiple identifiers per patient, such as an MRN from a practice as well as a Social Security number.It is important to note that this over-rides the previous constraint, made I believe by IHE Patient Care Coordination, that the document shall have only one patient identifier || Feedback discussed during meeting on 9/10 - decision made to "alert" readers that documents may include multiple identifiers, which may not have been seen in the past ||
 * George Cole || Allscripts || 3.4.3.1 || 3.4.3.1 Plan of Care Section XML Example. I really hope this can be produced, but please, please make sure to vet any example here with the Validator as well as with members of the HL7 Structured Document group. I posed a question to this group on 7/25/2012 to which there has been no answer: How does one relate the multiple entries that May be a part of this section? The example CCD.sample.xml document has a Plan of Care Activity Observation, a Plan of Care Activity Act, a Plan of Care Activity Encounter, and a Plan of Care Activity Procedure – are they meant to be related to each other, or to the text? Could we get an example with multiple “plan items”, for example one with a requested colonoscopy (the current example), a follow up scheduled visit, and a clinical reminder or two? Showing how this might look, with a multitude of entries, would help. || Great suggestion—will incorporate into Plan of Care section example. We have plans to vet through Lantana folks and SDWG as well as run through validation. ||
 * George Cole || Allscripts || 3.5.2 || Needs to be reworked some since Final Rule dropped Encounter Diagnoses from all but the
 * Thomson Kuhn || ACP || 2.3.1 || "Principles in Practice: . . .Consolidated CDA allows for the addition of this section to the defined document type." Where in the C-CDA document is this permission described? Please add a specific citation? || Added guidance on open and closed templates ||
 * Thomson Kuhn || ACP || 2.3.1 and 4.1 || "Summary of agreement between senders and receivers of CDA documents:" This suggests that any system must be capable of creating and consuming any section listed in C-CDA at any time without warning. This seems to defeat the point of having document types. How can such guidance be implemented in certification tests? There must be some limitation on optionality. That is the fundamental purpose of implementation guidance. || Additional guidance added on additional sections and content, validation - sections 2.2 and 2.4 updated. Only required to consume what is required by MU2 where vocabularies are specified (e.g. problems, medication, etc.) ||
 * Thomson Kuhn || ACP || 2.3.2 and 4.1 || "CCD document type considerations for additional optional sections." If this level of optionality is permitted, what is the meaning of a template identifier? Declaring a document-level template indicates conformance to a specification. If this level of optionality is permitted, then the document no longer conforms to the constraints indicated by the template identifier. Should the identifier, then, not be used? In such case what can the receiver know about the document? || Additional guidance added on template IDs, validation, and open and closed templates - sections 2.2 and 2.4. Validators will ignore content beyond where conformance is indicated. ||
 * Thomson Kuhn || ACP || 2.3.4 || "When multiple documents are sent for a care transition, it is not necessary or desirable to include redundant information on multiple documents." This statement clearly violates the conformance requirements of C-CDA. When a document type is declared, certain sections are required. The suggestion that a medication list could be left out of a document whose specification requires one represents not only a violation of the specification, but also a patient safety risk. || Great point - additional clarification language added on naming documents and adding text to communicate purpose and relationships. ||
 * Thomson Kuhn || ACP || 2.3.4 || "These multiple types of documents should all be clearly named and should not be combined into a single document if the data does not align with the purpose of that document type." This guidance seems to conflict with the guidance in 2.3.2 that sections not included in a document specification can be added as needed. Also, explicit guidance is needed regarding how to send multiple documents regarding a single patient transition. How will these documents indicate their relationship with other documents in the set? What will happen when one of the documents is separated from the set? || Great point - additional clarification language added on naming docs and adding text to communicate purpose/relationships. ||
 * Thomson Kuhn || ACP || 2.3.5 || "Principles in Practice:" This recommendation to use narrative text to indicate that required content is not included presents a patient safety risk. Indication that required content is not included must be done in a structured, computer-processable way. || Additional language on handling null content added. ||
 * Thomson Kuhn || ACP || 3.2.1 || "Patient Preferred Language This data element may be implemented as specified **[ IN ]** the Record Target. . ." C-CDA specifies the use of Internet RFC 4646 rather than ISO 639. This paragraph should explain this discrepancy and explain how to address it with specific examples. || Added guidance on differences/relationship between RFC 4646 and ISO 639. ||