TOC+Implementation+Guidance+SWG+Meeting+Minutes+2-10-2012

include component="page" wikiName="siframework" page="TOC Header" =ToC Implementation Guidance SWG Meeting Minutes=
 * Date:** 2-3-2011
 * Time:** 3:00 - 4:00pm EDT

==Attendance== Russell Leftwich, Holly Miller, Ashley Swain, David Tao, Bob Yencha

==Action Items== ==Agenda Items==
 * **#** || **Date Initiated** || **Action** || **Owner** || **Status** || **Date Closed** ||
 * 1 || 2-10-2012 || Review the Companion Guide materials on the wiki || Ashley, Rich, Bob & Erik || Open ||  ||
 * 2 || 2-10-2012 || Created Sample Section 2 guide || D. Tao || Open ||  ||
 * 1) Welcome and Announcements
 * 2) Implementation Guidance Discussion (Volunteers)
 * 3) Next Steps

==Notes==


 * Concern on what will happen if a creator includes more information for the reciever on the information being sent
 * There will be no need to complete data and incorporate the statements on the particular documents as needed for the optional sections
 * There is a risk that the guidance is not a reinforcement of the basics of CDA and may not include information that could fall through the cracks
 * The assumption is that CDA audience understands the fundamentals of CDA and the original intent
 * The companion guide is aimed at those that do not have a strong baseline understanding of CCD & care transitions
 * There is an expectation that people understand the underlying standard of the CDA guide
 * The question was raised where should the group consolidate guidance with regards to all the documents at once or segment out the information through for example a physical form
 * The risk is compiling stacks of redundant data from both sending and receiving parties. The end goal is to achieve hi speed interoperability and exchange between a transition of care
 * The requirements for a hypothetical transitions of care include - the CCD, physical, operative note, clinical prescriptions etc. and there is a risk that all the documents have redundant information including medications, and tests
 * While duplicative data is a risk, we don't want to prolong the analysis on the provider side in terms of determining of what to send
 * Use cases have emphasize the push as opposed to pull and for every exchange pattern they have not selected particular areas of concern or datasets that are to be constrained.
 * The whole point of Direct is a "push" and in a "push" situation for medications, what would be helpful would be a medication template, or a LOINC code to facilitate the catalog look-up process
 * A push model indicates that the sender has a right to "push" information to a receiving party. If meds, allergies and adverse events are being described, there is a need to highlight the interoperable data and consider what your receiver 's preferences are with regard to information
 * MU does not limit the exchange to CCD- It includes a summary to use a specific model or other materials.
 * The vast majority of senders will not have an opinion on what information should be segmented out. Hypothetically, if serving as a clinician, for example as a cardiologist, they will need echocardiograms & other imaging results but don't necessarily care about vascular function in the lower extremities.
 * It is important the sender is doing work to benefit the receiver and ultimately the patient as well
 * The best practices would be to choose the right document type as well as to send the correct categorization
 * There is a possibility of embedding documents aligned with CDA into a PDF as well as adding a jpg, audio file and sending an actual object. The intent is to make up for content that focuses on required (ccd) then additional/optional ToC section

**Time:** 3:00 - 4:00pm EDT

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"