ToC+RI+Arch+Workflow

include component="page" wikiName="siframework" page="TOC Header" This wiki page is to describe how the Transfer of Care (ToC) Reference Implementation (RI) will work, along with its relationship to the Clinical Element Data Dictionary (CEDD). This wiki page is now up for consensus. To participate in the consensus process, click the ToC Architecture Workflow Diagrams Consensus Votes page.

Key Concepts of the RI Architecture
The RI Architecture will use the mapping information (schematron) from the Clinical Element Data Dictionary to define data elements as required by the ToC Documents, namely the Discharge Instructions, the Discharge Summary, the Consultation Request Clinical Summary and the Consultation Summary. The Reference Implementation shall be capable of providing the necessary definitions as prescribed by Meaningful Use. The following two diagrams show how the RI Architecture/CEDD can be used to build the ToC documents from the Clinical Element Data Dictionary Objects and likewise how it can be used to decompose the ToC Documents into the atomic data element groups, ending with their Clinical Element Data Dictionary Objects (e.g The data element group Demographics includes data elements such as First Name, Last Name and Gender). Additional information on the ToC CEDD is available through the ToC CIM/Vocabulary WG.

= =

= = = =

Reference Implementation Workflow
The purpose of the Reference Implementation is to aid in the development of systems which create and consume Transfer of Care documentation. The aid may come in the form of tools and/or code that may be incorporated into EHR and other system implementations. The priority of Reference Implementation shall be driven by the priorities of the Use Case, and is currently stated by the ToC RI Architecture Scope. The following are conceptual Reference Implementations that are examples of how the ToC Reference Implementation may be used.

Assumptions
The following assumptions apply to the Reference Implementation workflows:
 * Errors and Warnings will be returned by the RI in the case of semantics, syntax and where applicable vocabulary issues. Where possible the severity of the issue will also be identified by the RI. However, the behavior of the application relative to the handling of errors and warnings is a Policy decision and is out of scope.

Reference Implementation Workflow - Creation of a ToC Document
One of the goals of the ToC Reference Implementation is to provide code which will enable the User to create an instance of a ToC Document based upon the ToC Clinical Element Data Dictionary and one of the ToC Document templates, namely (1) the ToC Discharge instructions, (2) the ToC Discharge summary, (3) the ToC Consultation Request Clinical Summary or (4) the ToC Consultation Summary. Diagram 3 below, depicts the steps that might be entailed in creating an instance of a ToC document using the RI/CEDD ToC Document creation as depicted in Diagram 1. The shapes in green are the steps that are performed by the Reference Implementation, while the blue shapes are inputs/outputs to/from the Reference Implementation. The goal of the Reference Implementation is the creation of libraries that could potentially be embedded in a product or used as an external tool. Alternatively, the Reference Implementation open source code could be used as sample code for aid in the development of product code.



RI ToC Document Creation Implementation Workflow:

 * **INPUT**: The Source System (e.g. EHR System) provides the ToC data elements required to create the desired ToC Document.
 * The RI will accept data elements input from the source system (e.g., an EHR or other source).
 * The RI will process the data elements as required by the ToC Document using the ToC CEDD. Note, that the RI will need to report any errors (e.g., invalid data or lack of required data) in the data elements provided.
 * The RI will create a ToC Document per the requirements of the ToC Document.
 * **OUTPUT**: A ToC Document for the specific ToC Document using the EHR data elements is available for use by any Application.

Reference Implementation Workflow - Consumption of a ToC Document (Decomposition)
A second goal of the ToC Reference Implementation is to provide code which will enable the parsing of an instance of a ToC Document based upon the ToC schematron. Using the RI/CEDD ToC Document decomposition as depicted in Diagram 2, Diagram 4 below shows the steps that might be entailed in decomposing an instance of a ToC document. for consumption by the Consumer. The shapes in green are the steps that are performed by the Reference Implementation, the dark blue shapes are inputs/outputs from the Reference Implementation, and finally the light blue shapes provide status back to the calling Application.



RI ToC Decomposition Document Implementation Workflow


 * **INPUT**: Consumer System (e.g. EHR System) will receive an instance of a ToC Document (e.g. ToC Discharge Summary) created by the Source System
 * The RI will accept the ToC document instance.
 * The RI will decompose the ToC Document instance using the ToC Document schematron.
 * **OUTPUT:** Any errors in the syntax of the ToC Document instance will be returned so the Application can process them.
 * **OUTPUT**: The RI will return the relevant Clinical Element Data Dictionary Objects with their values to the Consumer System.

Reference Implementation Workflow - Validation of a ToC Document (Validation Tool)
The third goal of the ToC Reference Implementation is to provide a tool which will enable the parsing and validation of the syntax and semantics of an instance of a ToC Document based upon the ToC schematron. Using the RI/CEDD ToC Document decomposition as depicted in Diagram 2, Diagram 5 below shows the steps that might be entailed in validating an instance of a ToC document. The shapes in green are the steps that are performed by the Reference Implementation, the blue shapes are inputs/outputs from the Reference Implementation and and finally the light blue shapes provide status from the validation tool.

RI ToC Document Validation Implementation Workflow


 * **INPUT:** The User (or EHR System) will submit a ToC Document created by the EHR to the RI Validation Tool.
 * The RI Validation Tool will accept the Source document input by the User.
 * The RI Validation Tool will decompose the ToC Document instance using the ToC Document schematron.
 * **OUTPUT:** Any errors in the syntax of the ToC Document itself will result in the output of a Validation Report which can be used to aid the User in fixing any issues with the ToC document.
 * The RI will validate the ToC data elements against the ToC schematron to determine if any semantic errors exist.
 * **OUTPUT:** Any errors in the semantics of the data elements will result in the output of a Validation Report which can be used to aid the User in fixing any issues with the document.
 * **OUTPUT**: The RI Validation Tool will provide a final Validation Report on the validity of the ToC Document instance.

ToC Document Validation Example
The validation of a ToC document will check to see that the ToC Document conforms to the CEDD. Errors will be generated in the case that required fields are missing, and Warning will be generated in the case that recommended fields are missing. The following is an example of what the Validation would return in the case for components of a CDA Medications Section attributes: The following is an example of what the Validation would return in the case for components of a CDA Medications Section attributes:
 * **Medical Attribute** || **Required?** || **Status if missing** ||
 * Product || Yes || ToC Document **Error** ||
 * Start/Stop Date || Sent if Known || ToC Document **Warning** (See Note 1) ||
 * Frequency || Sent if Known || ToC Document **Warning** (See Note 1) ||
 * Dose || Sent if Known || ToC Document **Warning** (See Note 1) ||

//**Note 1:**// It would be up to the developer of the document to determine if the absence of these Medication attributes are critical to the specific type of the Transition of Care serviced of by the ToC Document.

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