TOC+Abstract+Model+Consensus+Page

include component="page" wikiName="siframework" page="TOC Header" Please enter your comments/endorsement of the Transitions of Care (TOC) Abstract Model in the table below. Enter your name and organization, and then a Yes/No vote.

If your vote is no, please explain __**in detail**__ what your objections are and how you believe they can be resolved.


 * **Workgroup Member** || **Representing Organization** || **Endorsement (Yes/No)** || **If No, what can be done to make it Yes?** ||
 * Mayuri Patel || ICA || Yes ||  ||
 * Bob DeAnna || Recursion Software || Yes ||  ||
 * Chris Doucette || Deloitte || Yes ||  ||
 * Tom Caruso || BITT || Yes || The two sets of "1, 2, 3, 4" is confusing. The Box listing the Information Flows should be bulleted.

The source IT system could be providing the discharge summary to the patient.

The Etc. in the diagram suggests a lack of understanding of the possible Consumer IT Systems || 2. Should show validation results 3. Not clear if this does or should initiate transports. If so, this should be modeled; if not then information flow should be to some representation of TOC Services, not just from Producer to Consumer. 4. Not clear how use cases with multiple operations fit (i.e Send Rx and update PHR) 5. Information Package is confusing. Is this diagram supposed to model one operation? If so, it should make it clearer that the Information Package is one of the list elements 6. Some use cases include database operations should as store or retrieving but there is no representation of a data store on the abstract diagram 7. Some uses cases involve transformations (i.e. to create CCD or C32, etc.). I think transformations should be added to the list of interactions
 * Mark Bamberg || MEDfx || Yes || 1. Doesn't provide enough information to make it useful

MODIFIED to yes after discussion and ellaboration || Avoid wording that implies unintended limitations, e.g., for ToC Abstract Model Interactions, "2. The source provides the ToC information package to the consumer" (implying only one recipient). Suggest saying "to consumer(s)" or "to one or more consumers" Same for #3 and #4, say The consumer(s) receive, decipher...". ||
 * David Tao || Siemens || Yes w comment || Explain up front that the ToC Abstract Model is modeling the use case (actual clinical transition of care) and not modeling the supportive tools (validators, extractors) that may be produced in the reference implementation.
 * Jaime Estrada || Health Information Network of Arizona || Yes || In principle, this works well. ||
 * John Moehrke || IHE ITI and GE Healthcare ||  ||   ||
 * Ken Pool || OZ Systems, Inc || Yes || Limited and the communication depicted as directly between parties suggests an linkage that frequently will not exist or certainly not be so straightfoward. A decoupled model where the sender just sends it "somewhere" and a different construct shows a consumer getting it from "somewhere" would seem to have been more representative. ||
 * Krishna Murali Brahmandam || Proheamon, Inc. ||  ||   ||
 * Steve Rushing || Georgia Tech || Yes ||  ||
 * Andrew Splitz || S&P Consultants, Inc ||  ||   ||
 * John Wandelt || Georgia Tech Research Institute (GTRI) ||  ||   ||
 * Lester Keepper || SHAPE HITECH || Yes ||  ||
 * Ernest Grove || SHAPE HITECH || Yes ||  ||
 * Vassil Peytchev || Epic ||  ||   ||
 * Mark Palen || System Admin Services, LLC || Yes ||  ||
 * David Cheng || IBM ||  ||   ||
 * Larry Sampson || MN HIE ||  ||   ||
 * Susan Nedza MD || HealthyCircles, LLC || Yes ||  ||
 * Robin Barnes || AHRQ/USHIK || Yes ||  ||
 * Gary Dickinson || CentriHealth ||  ||   ||
 * Terri Skalabrin || CORHIO || Yes ||  ||

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