Proposed+ONC+Guidance

1. MUST deliver a way to read/write and validate ToC information packages (but not necessarily all supported content for all documents). 1a. SHOULD deliver a way to read/write all supported content, but this may require diving down to a lower level of the API or writing raw XML. 2. MUST deliver a high level API that allows for non-CDA experts to read and write ToC information. 3. High level API MUST be mappable to CIM for requirements traceability to ensure clinically relevant and valid data are exchanged. 4, MUST be model-driven, COULD use CIM model as the API target model. 5. MUST NOT be single platform or bias a particular platform. 6. MUST attract an ecosystem of customers -- including both end users and open source developers, with a reasonable total federal spend and a clear path to "revenue break even", where federal funding is not required.
 * ToC Proposed ONC Guidance**
 * **Design Decision : **ToC RI will be designed to be independent of the platform and technologies for representing the four information packets. As additional information is added/clarified all four packets will be addressed. The first information packet addressed will be Discharge Summary. The implementer is shielded from changes to the structure. The design will abstract CDA, CCD and underlying complex health standards involved. It will be a modular solution that allows various and potentially separate technologies for read/write vs. validate.
 * **Requirement Decision : **The Harmonization team identified the [|DSTU Discharge Summary] as the specification for development. Erik Pupo clarified that the document he sent out (Transition of Care – Document Type Summary) specifies the requirements for the [|four information packets] based upon the consolidated CDA sections/ templateIds. The group agreed RI can move forward using this document by substituting in the CDA R2 sections/templateIds until use of the consolidated CDA is approved. MDHT will utilize these documents to create representations of the information packets. XSLT, XSD, and Schematron may be used as well.
 * **Requirement Decision : ** The group agreed to use Erik Pupo’s ToC [|CIM Version 1.5] to define the CIM structure and ISO types. However, the templateIds specified are based on consolidated CIM, which is still a work in progress. For the first interim RI release (end of August) RI will use [|CDA R2]. The group will then evaluate the state and use of consolidated CIM templateIds for the second interim RI release (end of October).
 * **Assumption : **We assume that the definitions of the four information packets given in Erik Pupo’s document (Transition of Care – Document Type Summary) incorporate the data elements called for in the CIM. Therefore, by implementing the information packets as specified, the ToC RI will implicitly have traceability to the CIM. Testing will start with priority elements A.
 * **Requirement Decision : **The group agreed that testing for the four information packets will implicitly test the CIM, because of the traceability of the information packets to the CIM.
 * **Requirement Decision : **The group clarified that use of [|MDHT], [|OpenMapper], and XSD tools (Mapforce, XMLSpy, etc.) will successfully meet this requirement to deliver a model-driven solution.
 * **Design Decision : **We clarified with the technical team that this refers to the implementation technology platform (e.g.. Java/.Net) and does not refer to the deployment platform (e.g., Unix/Windows). The assumption is that the task is to create a solution that provides implementation platform independence. The ToC solution will be a modular design that permits various technologies (such as [|MDHT] which is a Java-centric technology) to be plugged in as needed to handle the validation and transformation from the CIM model to the four information packets. The implementer will be shielded from knowing the underlying technology.
 * **Business Decision : ** The group agreed that this requirement is addressed by the involvement of the community to produce both the RI and later the pilots. Material is being produced to foster additional involvement from the user community.