Implementation+Guidance+Fact+Finding

=Transitions of Care Implementation Guidance Fact Finding=

ToC Implementation Guidance Fact Finding Activity
This page is intended to capture topics for additional guidance to be included in the ToC Companion Guide. The primary motivator for this activity is the reality that //anticipating// all guidance needed to ensure successful implementations is impossible, but inclusion of any and all topics which enhance implementation guidance will best serve the healthcare community to support stakeholders in achieving care transition objectives of Meaningful Use. In other words, "what are the things that you wish that someone had explained to you about Consolidated CDA?"

A copy of the Consolidated CDA IG may be downloaded from [|HL7]for reference.

Implementation Guidance Topics
This list of topics for additional guidance to be included in the ToC Companion Guide is not intended to be exhaustive and volunteers are encouraged to **add any topics they feel would benefit the healthcare community by including in the ToC Companion Guide.** The table below details the topic and the section of the ToC Companion Guide where the additional guidance should be addressed. Sections of the ToC Companion Guide and brief descriptions are listed below as a reference.


 * __Sections of the ToC Companion Guide__**
 * Section 2: __General CDA Guidance__
 * Section provides CDA guidance to assist in understanding concepts integral to implementation of the MU2 requirements
 * Section 3: __Indicated C-CDA Structure__
 * Section details the sections and entries indicated by MU2 and ToC with additional guidance to assist implementers
 * Section 4: __ToC Implementation Guidance__
 * Section details ToC recommendations for implementing MU2 requirements including clinical scenarios, XML examples, and best fit document recommendations for care transition MU2 Objectives

**Implementation Guidance Topics**
(D. Tao note: ToC has discussed whether a request should be made to HL7 for anew nullFlavor that is similar to MSK (masked) but not for reasons of sensitivity/security, but for reasons of clinical judgment. Currently, it is not obvious that any of the HL7 nullFlavors fit the situation where information exists in a record, but is deliberately not sent because it would be unhelpful to the intended recipient. See also Topic #4) HL7's null flavor MSK ("Masked") says some data was deliberately not sent for security, privacy or "other" reasons, but that may not not be the right nullFlavor to use to indicate that some data were withheld due to clinical judgement. Here is an example of why it is important. Providers using EHR systems to get MU “credit” for the transition of care measure, they must either send something or indicate that there was no clinically relevant data to be sent given the clinical situation. For example, A PCP sends a patient to a dermatologist for Rx for warts. The provider has plenty of lab data available for that patient, but none of it will be helpful to the dermatologist. If they send none without something triggering the system that "this was my judgment call and I did it on purpose" (a new null flavor = clinical discretion) they won’t get numerator credit for that patient for MU. (E.Jones Question - Guidance needed) Validation question - If data is needed per MU requirements (e.g. immunization administered during the visit or Smoking status (element within a section)), and the document we choose to use has the section as optional, will it force a null flavor so that the section can be validated? || 2 || CDA - Text on nullFlavor Guidance Because HL7 nullFlavors have been established, and it is infeasible to add to the nullFlavor value set in time for the Companion Guide publication, ToC assumes that only the existing nullFlavors can be used. The HL7 "MSK" nullFlavor is commonly associated with reasons of security or privacy. But it can be used to indicate "other reasons" too. In the absence of a more specific nullFlavor to address withholding of information for reasons of clinical judgment that it is not pertinent, MSK is more appropriate than other current HL7 nullFlavors to indicate that information exists but was not included. The HL7 definition of MSK is as follows: "There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons . There may be an alternate mechanism for gaining access to this information.Note: using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail. " || 5/21/2012, updated 7/17/2012 07/20/2012 || (D. Tao note: I updated the supporting materials to be consistent with the Document Recommendations and ToC analysis done in the past month. This document also includes other guidance related to the topics on this page). || 2 || || 7/6/2012 updated 8/6/2012 || Notes from ToC call on May 14th: Don't "change the practice of medicine" by forcing extra work; make it easy to do the right thing, hard to do the wrong thing. If it is made too hard to be selective, some persons will not want to spend the extra time and will just do a "data dump" even if that is not helpful for the receiver. Also, is there a need for a new "null flavor" or other indication that indicates "Some information has been deliberately not sent, at the sender's discretion?" Dr. Leftwich questioned the necessity, since he said that the document is a "summary" and a summary by definition is not "all the data." On the other hand, would it be useful for the receiver to know that some information was not sent, so that they could ask for more if necessary? || 3 || See document for Topic #2 || 7/5/2012 || the same thing || Some MU requirements could be met in more than one way. Some ways are obvious, e.g., the requirement for a "Reason for Visit" can be handled by including the C-CDA "Reason for Visit" section. But what if someone wants to handle it via the "Hospital Admission Diagnosis" section, the "Problem" section or the "Chief Complaint" section? How much variation should be allowed for MU and for certification, and how should ToC provide guidance in these cases with several possibilities? || 3 || 1st draft by David Tao. Rather lengthy and detailed. Is it helpful? || 7/11/2012 updated || SHOULD or MAY sections || If a section is required (SHALL) by the document type but no information is available, nullFlavor should be used at the section level. But what is the ToC recommendation if the section is a SHOULD or MAY (ToC priority A or B)? If there is no information, should the section be coded with a nullFlavor, or should it just be absent? Does it matter whether this is handled consistently by all vendors? || 4 || (D. Tao update) Proposed guidance for sections that have SHOULD or MAY constraints (ToC Priority A or B that are not required by MU or by the C-CDA document type). If there is no pertinent information to include, the section should be omitted entirely. It is not necessary to create the section with a nullFlavor. Example 1: in a referral, if there is no History of Past Illness (a ToC B section not required for MU), simply **omit** the section. Example 2: in a discharge, if there is no Plan of Care, that section **must be included** and given a nullFlavor, because it is required (both by MU and by the Discharge Summary document type). || 7/5/2012, updated 7/12/2012 || differ for a vendor vs a provider? || Need to clearly explain this concept: A SHALL in a spec is interpreted by a vendor to mean that the product SHALL provide the ability to include the data. Of course, there will be instances of patient CDAs where that data is not present. How should a provider interpret a SHALL? Does it mean that the data must always be sent regardless of relevance? Related: should real-world instances of CDAs be sent through a NIST (or equivalent) CDA validator and rejected by the receiver if they fail? E.g., if a required section is not present? But what if the section is not present because it is not clinically relevant?
 * **#** || **Topic** || **Brief Description** || **CG Section** || **Supporting Materials** || **Date Added** ||
 * 1 || Null Flavors || Guidance on the use of nullFlavors and any implications on MU requirements.
 * 2 || Optional Sections || Guidance on the inclusion of optional sections
 * 3 || Extensions to CDA R2 || C-CDA IG: Appendix G (i.e. sdtc:raceCode) || 2 || C-CDA IG May 2012 Ballot || 6/4/2012 ||
 * 4 || Selectivity of information || Guidance from ONC and CMS needed for the case of "clinical judgment." The CMS MU NPRM allows for //additional// data to be sent based on clinical judgment. But what about the case where some clinical data is deemed by the sending provider to be completely irrelevant to the receiver, and where the summary of care record will be much more usable and helpful without it? Can that data be omitted even though MU says it is required?
 * 5 || Many ways to handle
 * 6 || Section null flavors for
 * 7 || How does the meaning of SHALL
 * (See the Supporting Materials document for Topic #2)** || 3 ||  || 7/6/2012 ||
 * 8 || Preliminary and updated versions of documents || Guidance is also needed on what to do if a preliminary incomplete version of a document is sent (e.g., a Discharge Summary sent on or shortly after discharge, that does not have the narrative Hospital Course section yet and thus is sent with a nullFlavor "NAV" (temporarily unavailable, but will be available later) for that section. What are the recommendations for sending an updated document? The analogy was made to a "wet read" in an imaging report, followed by the final report. ||  ||   || 2/10/2012 ||
 * 9 ||  ||   ||   ||   ||   ||