ToC+Archived+RI+Architecture+Scope

include component="page" wikiName="siframework" page="TOC Header" This page has been archived for ease of access. Please see the ToC RI Architecture Scope page for the most current version of the ToC RI Architecture Scope. 

Scope of Reference Implementation
The goal of the ToC RI Architecture is to identify the layers, components, interactions, patterns and standards that are necessary to create a robust reference implementation that can be used by the community. It will support the Purpose and Goals of the ToC Initiative and the ToC Use Cases by providing **open source code** to assist developers (vendors, providers, individuals, etc.) to **more efficiently create valid ToC information packages (content)**, such as [|C32 CCDs] and other Clinical Summaries being defined by the CDA Harmonization and Documentation Workgroups, that can be exchanged and understood equivalently by senders and receivers, as described in the Abstract Model. There are some baseline goals, and some "stretch goals" depending on the amount of use that each component would be expected to receive. It is understood that content must be secured, transported, audited, etc., but this particular ToC Initiative and its reference implementation focus only on the **content** of the information packages.

RI Baseline Goals (Required for the Project)

 * **"Enable Clinical Summary validation services...": ToC Information Package Validation Tools.** These tools will validate that a ToC Information Package is complete and correct. These tools can validate ToC documents that are created either by the RI or any other method (e.g., ToC documents produced by vendors through their own code). These tools may be similar to tools currently provided by NIST, but will fully support any new constraints from the ToC initiative (including the CDA consolidation when it is approved), and will be offered to NIST to incorporate into their toolkit for validators.
 * **"Reduce template development time....": Code that Creates ToC Information Packages.** These tools can be used by developers (of EHRs, PHRs, etc.) to "jump start" their effort to create documents and/or templates included in ToC information packages.

RI "Stretch" Goals (Optional for the Project, depending on need and time)

 * ** Code to Produce Clinical Documents from EHR Data (run-time).** Through architectural layers, provide code that supports the ability of the source to "create a ToC Information Package" e.g., as required for Discharge or Consults.
 * ** Code to Consume Clinical Documents by EHR (run-time).** Through architectural layers, provide code that supports the ability to "decipher and validate the ToC Information Package" and "view and incorporate the information that was provided by the source." This will only extract the data from the ToC Information Package into discrete standardized data elements, but will not attempt to reconcile the data (e.g., create a single allergy list) within the clinical application.

RI Assumptions

 * **The RI focuses on development tools for clinical content**, consistent with the scope and charter of the ToC Initiative.
 * **RI provides tools as aids, not as "standards."** RI tools do not supersede or replace balloted standards or implementation guides (e.g., CDA is a standard, but any APIs provided by RI services are optional aids to produce standardized outputs, not to become standards in themselves).
 * **Primary Focus is on Development-time tools.** The RI can be used as is, or modified, by developers to create software modules that generates ToC information packages. It can also be used by developers and testers to validate ToC information packages. The development-time tools help generate or validate code that conforms to standards and implementation guides/specifications.
 * **Secondary Focus is on Run-time tools.** "Run time" tools, if they are produced, would actually be executed during a production exchange. For example, provide data element services to transform actual patient data from an EHR into a CDA section or CDA document. The run-time tools help generate ToC information packages or subsets thereof.
 * **Transport, Security, Privacy, Addressing, Audit, and Patient Identification are out of scope for the ToC RI.** These are all essential components from an overall system perspective. However, this ToC initiative is about content, not about transport or other infrastructure. The RI will not produce code to transport, encrypt, or otherwise "secure" the payloads from a sender to a receiver. Other projects (Direct Project, Nationwide Health Information Network Exchange and CONNECT, etc.) have produced RI open source code for transport, encryption, and other infrastructure. (include links to their source libraries). Some standards -- e.g., access control, audit log, authentication, integrity, encryption of data in rest and in transit, have already been specified by ONC in its Final Rule for EHR Standards and Certification. Other ONC S&I Framework Initiatives, such as Provider Directory and Certificate Interoperability, address gaps in standards and implementation guidance that have not been previously specified in regulations and/or standards.

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