ToC+RI+Architecture

include component="page" wikiName="siframework" page="TOC Header" This wiki page is to facilitate the discussion of the ToC RI Architecture and Components that will be used as guidance to create a robust ToC Reference Implementation. Please provide feedback on this page through the discussion tab. To participate in the consensus process, click the ToC RI Architecture Consensus Page.

Introduction
The Transition of Care (ToC) Use Cases describe the sample user stories that are enacted when a patient is being transferred from one care setting to another care setting. In addition, the Use Cases also identify the content that needs to be exchanged for the Transition of Care to happen seamlessly using electronic health information. See Section 9.0 of the Final ToC Use Case. In addition to the Use Cases, the ToC Abstract Model identifies the systems actors and interactions and defines some of the terms and definitions relevant to the ToC Reference Implementation (ToC RI). The goal of the Architecture Overview is to identify the ToC RI architecture layers, components, interactions, patterns, and standards that are necessary to create a robust ToC RI based on the ToC RI Architecture Scope.

**Architecture Methodology**
The Architecture methodology that will be used is based on OMG’s Model Driven Architecture with the goal of creating computable models that can be transformed to a robust reference implementation.

**Architecture Drivers and Principles**
The following are the key architecture drivers and principles that guide the creation of a robust ToC RI
 * Focus on the Data Elements required for ToC Initiative per the Clinical Element Data Dictionary
 * Allow the flexibility to extend beyond the Data Elements supported by the Clinical Element Data Dictionary. (E.g. State regulations may require additional data to be provided as part of a ToC)
 * The Clinical Element Data Dictionary will be an isomorphic representation of input documents or messages
 * Allow the flexibility to decompose the data elements to enable mapping between the CEDD and various standards using the architecture layers.
 * Ability to decompose the data elements, from the structured documents or messages, to enable mapping from one standard to another, as well as structural transformation of the data elements to support the standard syntax requirements
 * Create Domain Specific Services to implement the Clinical Element Data Dictionary
 * Ability to re-use Data Elements outside of the ToC Initiative
 * Use Software Patterns to provide modularity, extensibility and re-usability
 * Allow architecture to be implemented using multiple languages and platforms

**Architecture Assumptions**
The following are the assumptions that have been made in developing the architecture layers and components.
 * The Source and Consumer IT Systems defined in the abstract model handle the various application and system infrastructure services such as Transport, Security, Privacy, Patient Identification, Audit, Addressing. This is further explained in the ToC RI Architecture Scope.
 * The creation of a given ToC Information Package may require the use of multiple input documents and data sources, which through a chain of transformations produce the required ToC Information Packages.
 * The creation of a given ToC Information Package may require the production of multiple output documents in different formats.
 * The ToC Information Package may require the inclusion of additional Data Elements not specified in the CEDD to meet the requirement for a ToC.
 * The RI Architecture shall use a layering approach, following standard enterprise architecture best practices and provides the following advantages adhering to the architectural principles outlined above.
 * 1) Promotes modular software design
 * 2) Separates concerns relating to data, applications and business logic.
 * 3) Allows for extensibility and re-usability at each layer
 * 4) Focuses on each data element and services for each data element that can be packaged with various service orchestrations.
 * 5) Allows for designing computable models and plugging in different transformations, validations, discovery services in the future.

**Architecture Layers and Definitions**
The following definitions describe the individual architectural layers that serve as the guiding principles for the ToC RI Architecture. It should be noted that in the context of this document, the term **//services // ** are used to indicate that the component provides services in a generic manner and does not require or promote use of any particular type of platform or realization method (e.g. REST services, SOAP services etc).

by using objects and attributes to reflect the domain entities and concepts. The Data Elements Definition Layer will need to allow for data elements support outside of those supported by the CEDD. This layer represents the data elements at their most atomic level. The diagrams below represent sample data elements. They are not an exhaustive list of data elements and their attributes. The exact list of data elements and their attributes are being identified by the ToC Clinical Information Model/Vocabulary WG Note that a "data element" is a very granular concept such as described in the HITSP C83 specification and HITSP C154 Data Dictionary. For example, HITSP data element 1.05 Person Name or 1.06 Gender. In fact, some data elements can be subdivided even further, e.g., Given Name, Surname, etc. It is impractical to depict these data elements on diagrams, so they are portrayed as "Data Element Groups" (e.g., Demographics), where each group contains multiple data elements (Demographics contains Person Name, Person Address, Gender, Data of Birth, etc.). Most (but not all) of the actions defined in other Architecture Layers are taken on individual data elements, not on the entire Data Element Group. Some actions, however, may be at the Group level, e.g., assemble multiple data elements into a CDA Problems section. Unlike other layers, the Data Elements Definition Layer does not include "services" that act upon the data, it simply defines the data. Thus the Data Elements Definition Layer can be described as the "data about data" or metadata that defines each data element.
 * Data Elements Definition Layer:**The Data Elements Definition Layer will provide a software representation of the Clinical Element Data Dictionary

Clinical Element Data Dictionary to various standards and formats such as CCR, CCD. This is another "definitional" layer that describes how data elements are organized into Data Element Groups (e.g., CDA or CCR sections) and documents and other packages. It is required to drive the Data Element Service Layer and the ToC Orchestration Services Layers described below.
 * Data Structure Layer:**The Data Structure Layer will house the hierarchical structures and data transformation mappings that will be required to transform the

> This set of services can be used to validate inputs such as clinical documents for valid syntax and vocabulary and inclusion of all required elements, in accordance with the ToC CEDD. It validates individual data elements as part of a larger context, e.g., sections, documents. Unlikely as it is that a service would be used to validate only a single data element in isolation, the ability to validate individual data elements is essential. This is because the same set of data elements may be reused across a variety of different packages (CCD, CCR, HL7 message, etc.) and the validation services are intended to address multiple ways of packaging the data. > This set of services can be used to create ToC information packages or parts thereof. The inputs are data elements (e.g., from an EHR) and the outputs are CEDD-conformant data element groups (e.g., problem list) and/or documents (e.g., CCD or CCR). The Reference Implementation (RI) will include sample open source code that developers can adapt to fit to their applications to facilitate creation of ToC information packages. An RI could provide a software implementation as a set of libraries which themselves can be incorporated into an application to return an output. > This set of services transforms an input into a ToC-CEDD-compliant format. Typically, the input will be a package such as a document, and the output will be a different package. The CCR to CCD transformation is one example. Each data element from the input must be decomposed/mapped into an internal standardized canonical form" and then reassembled into the output. Thus, many transformations occur at the individual data element level, but the practical use is to transform one package (e.g., a document) into another package. An individual data element would not be transformed "into a CCD" for example. Rather, an individual data element would be transformed into "its valid piece" of a CCD, in the context of the overall transformation of a package. > This set of services supports the Data Element Factory and Data Element Transform services. Alternative vocabularies exist in EHRs, and are allowed in Stage 1 Meaningful Use. These services will include definition of the standard vocabularies for each concept, and support translation (to the extent possible) among alternative vocabularies. Note that exact 1:1 mapping among vocabularies (e.g., ICD-9<==>SNOMED-CT) is not always possible. > This set of services supports the manipulation of the data format for use in other applications within a System. An RI could provide a software implementation as a set of libraries which can be incorporated into an application that uses ToC data elements from a spreadsheet (CSV file) or XML file. >
 * Data Element Services Layer:** The Data Element Services Layer provides a set of services that allow for managing the life cycle of the underlying data elements in terms of creation, modification, transformation, validation, display etc. There are several categories of services. The exact services have not been finalized, and examples are for illustration only.
 * **Data Element Validation Services**
 * **Data Element Factory Services**
 * **Data Element Transform Services**
 * **Data Element Vocabulary Services**
 * **Data Element Utility Services**


 * ToC Orchestration Services Layer:** The ToC Orchestration Services use the Data Element Services Layer and the Data Structure Layer to create ToC Information Packages required by the ToC Initiative. Using information from the Data Structure Layer, it will be possible to transform the flat data elements from the Data Element Layer into structured documents and messages. The ToC Information Packages are described in the Abstract Model.


 * Future Orchestration Services:** In the future, there may new service orchestrations which end up using the Data Elements Layer, the Data Element Services Layer and the Data Element Services to enable new use cases. (e.g. ED Care Orchestration Services for Emergency Department use cases).


 * Applications, EMR's EHRs, HIEs, Clinical Portals, and PHR's Layer:** The Applications and Systems that use the ToC Orchestration Services and the complete supporting Layer may incorporate the RI functionality directly into the software implementation, use the code as a template for development, or simply use the software to aid in development. It is the responsibility of vendor Applications and Systems to provide all of the necessary functionality required by their systems, including the Transport, Security, Privacy, Addressing, Audit and Patient Identification features which have been deemed out of scope for the ToC RI.

Architecture Layers View
The following ToC Architecture diagram illustrates the relationship between the various Architectural Layers. The upper layers build upon the layers beneath them.


 * ToC Reference Implementation Architecture Layers**__:__The RI Architecture Diagram illustrates the simple relationship between the various RI Architecture Layers, the Data Element Definition Layer, the Data Structure Layer, the Data Element Services and the ToC Orchestration Services. These layers provide the initial guidance for the ToC Reference Implementation WG to start creating the required logical and physical software structures.


 * ToC Reference Implementation Components**: The RI Architecture Diagram lists the top level components that make up the ToC RI Architecture. The components are identified through the use of software best practices such as abstraction, encapsulation, re-usability, loose coupling, and extensibility. The components depicted in the diagram below (e.g. Data Element Factory Services and Data Element Transformation Services) exemplify the types of components which may need to be created. These components serve as initial guidance to the ToC RI WG to support logical and physical design.


 * ToC Reference Implementation Services:**The RI Architecture Diagram identifies the various services that incorporate each of the components identified above. The Services depicted in the diagram below (e.g. validate Consultation Summary, validate Data Element for CCR) exemplify types of services which may need to be established. The services provide initial guidance to the ToC RI WG for logical and physical design.


 * Diagram 1: ToC Reference Implementation Architecture Diagram**



ToC Reference Implementation Scope and Services:
The ToC RI Architecture Scope defines the baseline scope for the ToC Reference Implementation. In order to satisfy the baseline scope outlined in the ToC RI Architecture Scope, the following layers and services should be considered for further analysis and design by the ToC RI WG.
 * Creation of the various architecture layers to create the initial framework that can support architectural principles.
 * From a component and services standpoint the ToC RI WG should focus on the following:
 * For the Data Elements Layer, enhance the definition of the data elements with the latest CEDD information as it becomes available.
 * For the Data Structure Layer, the RI WG should focus on the mappings and the standards that would be recommended by the Standards Analysis WG and create the framework to absorb those into the Data structure layer.
 * For the Data Element Services layer, the RI WG should focus on the Data Element Validation Services, Data Element Factory Services and Data Element Transform Services as the initial set of services implemented. To the extent that vocabularies are defined by the CEDD work group that should be considered in the ToC RI.
 * For the Orchestration Services layer, services required to create and validate different information packages per the use cases should be supported.

ToC Reference Implementation Interoperability Standards
The Standards Analysis WG has performed a comparison of CCR, CDA and Green CDA Implementation Guides as potential candidates to implement the Clinical Element Data Dictionary. The comparison results will be used to recommend an Implementation Guide that will be used as a baseline to convert the Clinical Element Data Dictionary to an Interoperability Specification based output.

The mapping of a Clinical Element Data Dictionary to an Interoperability Specification output format allows the ToC Data Elements to be used within message structures, clinical documents, storage tables etc.

Terms and Definitions
__**Canonical**__ - Something reduced to its simplest form, i.e.unique (e.g. a prime number). __**Data Element Group**__ - The logical grouping of a set of data elements. Each Data Element Group represents a "core" data concept within the Transition of Care project. Some examples include: Active Medication List, Active Problem List and Patient Demographics.
 * __Isomorphic Representation__** - A mathematical term indicating the relationship between two properties through structure-preserving mapping.

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