ToC+-+RI+Implementation+Overview

include component="page" wikiName="siframework" page="TOC Header" =RI Implementation Overview=
 * Objectives, Scope, Status, Plans, and Products**

The Reference Implementation as a Product
The Transition of Care (ToC) Reference Implementation (RI) is a model-driven, loosely coupled framework to be used to compose and decompose Information Packages (IPs) specified as part of the ToC Initiative. The driving models integrated with the RI are products of the Model-Driven Health Tools (MDHT) system representing the IPs and the underlying standard specifications such as CDA, C48, and C83. The loose coupling is achieved using the Spring Framework for dependency injection in combination with a set of Java interfaces and implementation classes. The model-driven and loosely coupled aspects of the framework provide the basis for extending the RI to accommodate emerging changes to the IP specifications and/or their underlying standards, and for integrating the RI with pilot- or production-level software systems.

The composition of an IP instance document consists in converting clinical ToC data from a standardized non-CDA XML instance document into an equivalent IP instance document, while decomposition consists in the reverse operation. The standardized non-CDA document type specified by the RI is based on the ToC Clinical Information Model (CIM) previously defined by the CIM/Vocabulary Work Group of the ToC Initiative. The CIM is realized as an XML Schema document comprising all of the data elements specified in the CIM, and named as typed using the greenCDA standard. That realization is a family of Java XML binding classes, collectively referred to as the ToC Data Transfer Object (DTO).

The RI exposes an Application Programming Interface (API) defining methods to be invoked by any information processing system into which the RI is integrated. Those methods refer to the ToC DTO as defining either method parameters of method return values, as appropriate, such that the host system passes an instance of the ToC DTO to the IP composition method, and receives an instance of the ToC DTO as the product of the IP decomposition method. In other words, the ToC DTO is the form in which ToC data is communicated between the RI and the hosting system. The hosting system thus needs to understand the ToC DTO specification, and does not need to understand the details of the IP specifications.

The RI is delivered with a set of Java interfaces describing validators, composers, decomposers, and transformers, which are integral to the functionality of the composition and decomposition methods exposed by the API. The RI as delivered also includes Java classes implementing those interfaces, transformation code in eXtensible Style Language (XSL), and the Spring Framework configuration data necessary to integrate them into the RI framework at run time.

The RI distributions are available at []. A new distribution is made available at the end of each development sprint, approximately every two weeks. Each distribution consists of several files. The most recent distribution consists of the following.
 * siframework-toc-api-0.6.1.jar //(API for integration)//
 * siframework-toc-api-0.5.0-sources.jar //(API source code)//
 * siframework-toc-0.6.2.jar //(core functionality)//
 * siframework-toc-0.6.2-sources.jar //(core functionality source code)//
 * siframework-toc-0.6.2-dependencies.zip //(re-used open-source modules)//

The source code is also available directly from the working development repository (Mercurial) at []. Anyone can copy the source code repository to a local system for use, modification, study, extension, or integration.

What is Supported, and What is Not
The ToC RI Implementation is prepared to support the four related Transition of Care Information Packets:
 * Discharge Summary (DS)
 * Discharge Instructions (DI)
 * Consultation Request (CR)
 * Consultation Summary (CS)

In temporary substitution for the currently under balloting Transition of Care Consolidated CDA specification, the RI Workgroup was directed to use a modified form of the CDAR2 specification combined with the ToC Implementation Guidance. The RI is prepared to begin representing the Consolidated CDA specification following it's approved balloting. Ideally the end user of the RI is isolated from this change-over.

The templateIds for the CDAR2 IPs are newly defined in the [|HL7 OID Repository] as follows.
 * Information Packet || Template Id ||
 * Discharge Summary || 2.16.840.1.113883.3.1275.1.1.1 ||
 * Discharge Instructions || 2.16.840.1.113883.3.1275.1.1.2 ||
 * Consultation Summary || 2.16.840.1.113883.3.1275.1.1.3 ||
 * Consultation Request || 2.16.840.1.113883.3.1275.1.1.4 ||

For each IP, all of the required sections are supported and have been validated (see ToC Implementation Guidance for detail on the sections). The optional sections are also under development, but may not be fully validated in the duration of the RI initiative. The optionality of each section is relation to each IP is shown in the chart available at [|http://tocri.sipilotdevelopment.org/redmine/projects/tocri/wiki#Information-Package-Modularity].

In general, the structured data entries composing sections of the IPs are supported, while the unstructured entries, i.e. narrative text, are not supported.

Much more information about the current status of the development effort is available on the development wiki site at [].

The Validation Workbench
Delivered separately is a suite of tools used to validate the RI, collectively referred to as the Validation Workbench (VW). The VW provides the means whereby all of the requirements on the RI and the IPs are specified, test data used to validate the fulfillment of those requirements is composed, tests are run using that test data, and test results are analyzed. The individual components of the VW are as follows.
 * The Traceability Matrix is an Excel workbook listing each conformance specified in each IP and in their underlying standards, uniquely identified with a name and showing the exact language of the conformance taken from the specification. For each conformance, there is a spreadsheet cell that shows whether the RI's implementation of that conformance has been validated.
 * The Test Data Workbook is an Excel workbook wherein the RI validation team has specified test cases and test data to be used to validate the RI implementation of the various conformances. The Test Data Generation Tool is a Java program that consumes the test cases and test data from the Test Data Workbook * and uses them to generate XML documents to be used as input to the RI API for validation purposes.
 * The Test Harness is a Java program that consumes XML documents from a file system folder, passes them to the RI API methods as arguments, collects the RI-generated output documents for comparison to the expected output, and generates a report showing the result of each test case (pass, or fail with errors noted).
 * Full documentation is provided, guiding the reader in the use of the Test Data Workbook, Test Data Generation Tool, and Test Harness.

The VW is provided because the task of validating the composition and decomposition of the IP entails testing a large number of conformances derived from the IP specifications and their underlying standards, but for "happy path" successful operation and for "unhappy path" operation when given incomplete, erroneous, or non-conformant information. Since the RI API deals in XML documents as arguments and results, and since the test cases necessary to validate all of the conformances specified in the IP and underlying specifications number in the thousands, it would be extremely challenging for any validation team to compose all of the necessary input XML files and expected result files by hand, especially given that the IP and underlying specifications may change from time to time, and so the conformances and corresponding test data must change, as well. Another enormous challenge for a validation team would be comparing the output XML files to the expected results by human hand and eye.

The VW attempts to streamline those processes by providing a light-weight tool whereby a validation team can
 * lay out their test cases and test data without hand-coding thousands of lengthy XML files,
 * run a batch of test cases through the RI API all at once, and receive the output of each test case as a batch, and
 * compare a batch of input files to their corresponding output files to determine the pass/fail status of each test.

Using the VW tools, a validation team can validate a version of the RI in a matter of minutes or hours, instead of days or weeks. Another advantage of using the VW is that, aside from the initial process of specifyng the test cases and test data, the entire validation process can be automated, and therefore can be performed as part of a continuous integration process. All of this serves to drastically lower the resource cost of validating the software, and to accelerate the process of finding and resolving defects and other issues. The Validation Workbench will be released to the public in the near future.

Architectural Parameters

 * 1) Use existing standards where and as they apply.
 * 2) Use best existing software tools as much as possible.
 * 3) Avoid inventing anything that has already been invented.
 * 4) Avoid dependency on any particular standard or software tool.
 * 5) Isolate knowledge of details in the driving models.
 * 6) Enable the integration of future components.

These parameters were operative during the design and implementation processes that resulted in the RI delivered in several ways.

Parameters 1 and 3 guided the implementation team, as they guided the earlier ToC Initiation work groups and the MDHT team, to build upon the CDA, C48, C83, ISO, and greenCDA standards and specifications

Parameter 2 guided the implementation team to use XML technology to realize the CIM as the ToC DTO, because the tools available for the validation, transformation, and searching of XML are numerous, mature, and deep in functionality. The tooling associated with the alternatives, JSON, ECore, UML, and so forth, do not have anything like the breadth, depth, or maturity of XML tools.

Going Forward
Given the large number of conformances to be tested and the short time-frame in which the RI has been built, it has been impossible to fully validate the RI, especially in the area of negative testing. The VW provides a framework and set of tools with which the open source community and interested S & I Framework members can carry forward the work of validating the RI, and of validating extended components, new or altered IP models, and future versions of the ToC DTO.

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