Reference+Implementation+(RI)

 The RI Workgroup is a Collaborative Open-Source Software (OSS) Development Process. The Workgroup is formed to support the analysis of specifications, development of open-source software, and testing of the data exchange RI sample model following Agile Sprint techniques. Volunteers are requested to assist in all activities. The ONC Support Group is to build the necessary tools and processes to create a productive development environment and support communications to RI Workgroup members during Workgroup meetings. To support the goals and objectives of this Initiative, the Use Case and its requirements will evaluate and address several outcomes, such as the following (to be refined and further validated by the community):  The goal of the 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 purposes and goals of the initiative providing opensource code to assist developers (vendors, providers, individuals, etc.) to more efficiently create valid content/information being defined by the 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., for the particular Initiative and its reference implementation. The Project Scope document may be used to create a general document for initiatives..
 * 1.0 Scope of Reference Implementation **

__Steps: __ ** Requirements ** – Perform analysis of the requirements needed to meet all project objectives. The foundation of this process is the project charter. From this the team can analyze requirements, collectively discuss details associated with each requirements and follow-on discussion to clarify the requirements,

** Define scope ** – This process defines deliverables, assumptions, and constraints and establishes the framework as to how the project development must be performed.

** Baseline Goals ** – Set the baseline and target goals you would like the project to achieve. Tools are available to validate documents that are created either by the RI or any other method (e.g. documents produced by vendors through their own code. These tools may be similar to other tools but will fully support any new constraints for an initiative and can be offered to other vendors to incorporate into their toolkit for validators.

** Stretch Goals ** – Determine goals beyond what you know is achievable to determine maximum potential. Code to Produce Clinical Documents from EHR Data (run-time). Through architectural layers, provide code that supports the ability of the source to "create an 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 Information Package" and "view and incorporate the information that was provided by the source." This will only extract the data from the 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.

** Constraints, exclusions, assumptions ** - The project team must identify the constraints, exclusion, assumption and acceptance criterion they will be working on to complete the project.

**Create Tasks** – This process identifies the deliverables into smaller and manageable tasks by utilizing Agile scrum process.

**Verify scope** - Discuss how the deliverables will be verified against the original scope.

**Control scope** - Manage any changes in the scope baseline.

__Roles and Responsibilities __ <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Evaluate need for scope change request <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Accept project deliverables || <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Facilitate scope change requests <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Facilitate impact assessments of scope change requests <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Organize and facilitate scheduled change control meeting <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Communicated outcomes of scope change requests <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Update project documents upon approval of all scope changes || <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Validate scope change requests <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Participate in impact assessments of scope change requests <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Communicate outcomes of scope change requests to team <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Facilitate team level change review process || <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Evaluate the need for scope changes and communicate them to the project manager as necessary ||
 * **<span style="color: black; font-family: 'Arial','sans-serif';">Role ** || **<span style="color: black; font-family: 'Arial','sans-serif';">Responsibilites ** ||
 * **<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">TBD ** || <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Approved or deny scope change requests as appropriate.
 * **<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">TBD ** || <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Measure and verify project scope
 * **<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">TBD ** || <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Measure and verify project scope
 * **<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">TBD ** || <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 110%;">Participate in defining change resolutions

<span style="color: black; font-family: 'arial','sans-serif'; font-size: 110%;">This wiki page is to facilitate the discussion of the ToC Abstract Model and finalize on the systems and interactions involved. Please provide feedback on the Abstract Model through the discussion tab, and final comments for consensus on the Abstract Model Consensus Page. <span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 110%;">The purpose of the Abstract Model is to model Use Cases. The Abstract Model is intended to help the broad S&I community visualize information flow between the systems that are involved in the care transitions at a high level. It is based on user stories. As the Abstract Model is to be transport agnostic, it will be limited to information data and transactions. <span style="color: #000000; font-family: 'Arial','sans-serif'; font-size: 110%;">The following examples are terms and definitions that refer to the abstract model: Information Package: The Information Package defines content that is exchanged between actors in User stories.The Reference Implementation supports the creation and validation of this content. E.g. the following Information Packages have been identified as critical for the ToC Initiative. • Discharge Summary • Discharge Instructions • Consultation Request Clinical Summary • Consultation Summary Source: The person or entity creating the Information Package that will be provided to one or more consumers for treatment purposes. Consumer: The person or entity receiving the Information Package for treatment purposes. (One or more consumers may be involved).Source IT System: The IT system used by the Source to create the clinical information that will be provided.. This can be an EMR, EHR, Clinical Portal, other types of systems capable of creating Information Packages. Consumer IT System: The IT system used by the Consumer to receive or access the clinical information that is provided during Transition of Care from the Source. This can be an EMR, EHR, PHR, Clinical Portal, other types of systems capable of displaying ToC Information Packages.(One or more Consumer IT Systems may be involved). <span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 110%;">The Abstract Model and the interactions it supports are as shown in the diagram below along with terms and definitions that are relevant to the model. The exact IT mechanisms that will be used to implement the interactions in a real world system are outside the scope of the abstract model.
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 24px;">Abstract Model **
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 24px;">Introduction **
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 24px;">Terms and Definitions **
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 24px;">The Abstract Model **

The following example is a Recommended Approach for Use Case and Functional Requirements Development