ToC+RI+Architecture+Overview+Comments+Page

include component="page" wikiName="siframework" page="TOC Header" Please enter your comments/endorsement of the ToC RI Arch Overview in the table below. To continue to populate the table please add a row to the bottom of the table.

= Comments =
 * **Name** || **Comment** ||
 * David Tao || ARCHITECTURE DRIVERS AND PRINCIPLES
 * "Isomorphic representation?" Is there an easier-to-understand way to say it? I know it means something about being the same, but I don't really understand the intent of this statement.
 * "Domain-specific services?" What are those? What are the domains? Suggest giving some examples.

ARCHITECTURE LAYERS AND DEFINITIONS The Data Elements Layer" and "Data Elements Services Layer" sound too similar, and could be hard for someone to distinguish. Could the first be called the "Data Element Definition Layer" since it doesn't sound like it does any actions on the data, other than represent the CIM. Then the "Data Elements Services Layer" would be easier to understand as "doing things" to the data.

ARCHITECTURE LAYERS VIEW -- The TOC RI Layers Diagram doesn't seem useful, and just takes us space that delays the reader getting to the next diagram. I suggest removing it. The TOC RI Component Diagram is much more descriptive and useful. There's not enough to justify having three levels of the same diagram. Alternatively, you could keep the RI Layers Diagram and the TOC RI Components and Services Diagram, and lose the middle diagram. Two diagrams would be plenty. || 2. Identify "In Scope" services that will be provided as part of the RI - A statement should also be added about the other services and each service be identified as necessary services for ToC RI but out of scope for this Initiative. ||
 * Mayuri Patel || 1. Please label the diagrams so that there is a reference point
 * Steve Rushing || I agree with David Tao's comments & suggestions re improving clarity. ||
 * Lester Keepper & Ernest Grove || The RI Baseline Goals state: “ToC Information Package Validation Tools…will validate that a ToC Information Package is complete and correct.” Also, the Scope Statement and the RI Baseline Goals say: “ These tools will validate that a ToC Information Package is complete and correct.” T he HL7/CCD code also takes into account the S&I present and future “privacy and security” goals of healthcare. To complete this, user identification should be attached to every user action. T his provides auditable tracking that will increase communication, increase compliance efficiently, and lessen fraud.  ||
 * Tom Caruso || I find it hard to separate out "privacy" considerations in the TOC Architecture, though security is certainly controlled by the source and consumer systems. Privacy inputs such as information about patient approvals for sharing with or requests from a particular provider are part of the TOC workflow so how does this get separated out from the TOC Architecture? ||

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