CET+-+Use+Case+and+Functional+Requirements+Development



toc

**1.0 Use Case**
The Use Case is the foundation for identifying and specifying the standards required to support the data exchange, reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards. It gives the contextual background of why the Initiative is necessary, in a narrative format, and explains the benefits it will provide upon completion. The Use Case describes detailed Scenarios and User Stories, which serve as examples of how the enhanced technical capabilities will improve the task at hand. The scenarios are accompanied by various diagrams, providing pictorial representations of the processes, and displaying the actors involved as well as the sequence of the information exchange.

As described in the Initiative Overview, Outputs & Phases, the S&I Framework is characterized by 5 phases: Pre-Discovery, Discovery, Implementation, Pilot, and Evaluation. Use Case development takes place during the Pre-Discovery and Discovery phases. The first step in this process is to review the and identify any related work products that can be leveraged moving forward. As the S&I Framework promotes re-use, it is important to perform the due-diligence of researching other related work efforts before engaging the community to create original content as part of the Discovery phase.

Once the Initiative kicks off and is in the Discovery phase, the Initiative Coordinator will help to devise a strategy for creating the Use Case content. The (also provided in the Appendix) includes descriptions that clarify the intent of each section and how it adds value as part of the document. Accompanying these section descriptions are suggested formats that highlight the way the material has been showcased in the past. The Use Case will leverage material gathered as part of Pre-Discovery in the Initiative Charter, such as the scope statement, challenge, target outcomes and timeline associated with the Initiative.

All Use Cases will not always follow the Use Case template exactly as it is laid out. At the discretion of the workgroup and the nature of the information exchange, certain sections may be added or removed to appropriately represent the content. For example, Use Case might have multiple Scenarios and User Stories whereas another Use Case may only have one of each.

An example of a Use Case Table of Contents is as follows (//Note: This example only has one Scenario although in other documents there could be multiple//):

**2.0 Functional Requirements**
Depending on the context of the Use Case, Functional Requirements will include System and/or Information Interchange Requirements and Dataset Requirements.
 * **System Requirements** focus on end user needs within the boundaries of the EHR, or other application (data views, display, actions), internal to the system.
 * **Information Interchange Requirements** focus on “Inter-application” needs for the exchange of data and/or for specifying full semantic interoperability.
 * **Dataset Requirements** list the data elements (atomic data items) that will be available within the message or document. The resulting dataset requirements will be leveraged by the other S&I Framework to develop related artifacts (e.g. Specifications & Implementation Guides).

The Use Case and Functional Requirements development process should also aim to look for various categories of requirements during the requirements gathering process:
 * **Stated Requirements:** Requirements currently defined, and capable of being linked to prioritized business needs, scenarios, businesses processes, or use cases. Stated requirements may also include those obtained during stakeholder interviews, workgroup meetings, User Panel meetings, or through other collaborative venues.
 * **Expected Requirements:** What the stakeholders assume or imply should be included in the solution without explicitly communicating it. These requirements represent a risk to the project because failure to capture expected requirements, results in unpleasant surprises to the stakeholders.

In terms of presentation, the Functional Requirements are included within the Use Case, and they are also submitted in the form of an excel spreadsheet. **The contents of this spreadsheet are identical to those included in the Use Case**. The indicates which sections the content should be pulled from in order to populate each worksheet. This template can be found in the Appendix. Please note, it is recommended that you create this spreadsheet after the requirements have been defined within the Use Case, to reduce the amount of re-work between having to update both documents.

**3.0 Recommended Approach for Use Case and Functional Requirements Development**
This process for developing the Use Case and Functional Requirements is summarized with the figure and steps below.

//Note: As displayed in the key for the figure above, the dotted lines indicate that reviewing previous sections of the Use Case for accuracy after new content is developed, should occur continuously and frequently.The arrows pointing to the Cross Initiative activities indicate that the cross initiative outputs from groups such as the Use Case simplification workgroup should be referenced to determine whether or not there are reusable components that can be pulled into the use case. Over time, this will generate real time use of the core matrix rather than having the Use Case simplification efforts be retrofits.//


 * 1) **Incorporate the Challenge Statement, Value Statement and Scope Statement from the Charter.** These sections of the charter will foster discussion with the workgroup providing introductory context for the Use Case. Crafting language related to these topics is the easiest place to start since some material will already be completed and vetted with the community within the Pre-Discovery. //Note: It is important to distinguish that the Challenge Statement should apply to the Initiative while the Value Statement will apply specifically to the Use Case.//
 * 2) **Develop the Scenarios.** Developing the Scenarios is important to do up front because it helps to organize the Use Case into logical components. The Scenarios provide a great deal of information, including the User Story, which becomes the basis for the Activity Diagrams and Sequence Diagrams. The Activity Flow is another component of the Scenario that lists out the steps within the information exchange.
 * 3) **Develop the User Stories.** Developing the User Stories early on is beneficial because they provide examples of real life applications of the improved technology that the Use Case is meant to support. They summarize the interactions between actors and specify what information is to be exchanged.
 * 4) **Define the Actors.** Once the User Stories are complete, it will become apparent as to which actors will need to be defined within the Use Case. Using the Actors and Roles table (or a similar representation), found in the Use Case template, will help to clearly identify and display each actor’s responsibilities as part of the information exchange.
 * 5) **Identify the Assumptions, Pre-Conditions and Post Conditions.** The Use Case Assumptions section outlines what needs to be in place to meet or realize the requirements of the Use Case (i.e. the necessary privacy and security framework). These points are more functional in nature and state the broad overarching concepts related to the Initiative.The Pre-Conditions and the Post Conditions sections list what must be true before and after an operation, process activity and/or task takes place. Both lists describe the technical state of the system participating in the information exchange. These three categories are critical as they will lay the foundation for creating the Functional and Dataset Requirements. Additionally, these items will act as inputs for the standards harmonization activities.
 * 6) **Develop the Diagrams.** These diagrams are crafted to pictorially represent the interaction between systems.
 * 7) **Develop the Functional Requirements.** Functional Requirements identify the capabilities a system in a role must have in order to enable interoperable exchange of the healthcare data of interest. They provide a detailed breakdown of the requirements in terms of the intended functional behaviors of the application. The Functional Requirements include Information Interchange Requirements, System Requirements and Dataset Requirements and therefore are very important for downstream efforts. See section 2.0 for more details. Please note, the Information Interchange and System requirements are specific to each scenario but the dataset requirements are applicable to the use case as a whole. This is depicted in figure 8, where the Information Interchange requirements are section 10.3.1 and the System Requirements are 10.3.2 and the Dataset Consderations section is section 12.0.
 * 8) **Develop Dataset Requirements.** This table lists the data elements and data element sets that will be available within the message or document. Historically, the optional/required nature of each data element is deferred to the discussions during the harmonization phase.
 * 9) **Finalize Issues, Risks and Obstacles.** Throughout the Use Case development process, this list can be compiled as the workgroup identifies various issues, risks and obstacles associated with the Use Case.
 * 10) **Achieve consensus on the Use Case Package.**
 * 11) **Meet with Use Case Simplification group, adding new elements to core matrix and modifying existing ones.** In this final step, the Use Case workgroup should communicate back to the cross initiative workgroup(s) whether or not there were any modification made to previously documented data elements and also contribute any new data elements to the shared artifacts.This will continue to broaden the breadth and therefore, value of the cross initiative artifacts which with the increased contributions ideally will be able to be useful for future initiatives.

**4.1 Transition to the Implementation Phase**
As part of the progression from the Discovery Phase to the Implementation Phase, requirements and Use Cases will be leveraged to enable selection and harmonization of a standard(s). This will occur with a recommended schedule for release and plan for dissemination, working off of the original project plan that was set forth by the initiative. The introduction of these changes into the health IT community must be well planned and communicated. Release schedules must be coordinated across the S&I Framework along with CMS and ONC rule-making for stages of Meaningful Use criteria to reduce confusion by providers who are anticipating work on meeting future capabilities and standards. Depending on the context of the Initiatives, state and regional health information exchanges will need to understand the scenarios and Functional Requirements that they must be ready to support. Health IT software developers must understand future functional and interoperability requirements to factor into their immediate product roadmap and version planning.

After the Use Case and Functional Requirements have been consensus approved and transitioned to subsequent phases within the S&I Framework, community participants may request for changes to be made. For grammatical or stylistic changes, the workgroup leads will adjust the documents; however, for any revision that would require changing the scope of the Use Case or any of the requirements, the workgroup would have to reconvene, address the update, and conduct another round of consensus on the document(s).

4.2 Integration with Use Case Simplification
The Use Case Simplification Sub-Workgroup has taken on the task of analyzing and amending/appending the Functional Requirements Prototype along with those Functional Requirements that have been gathered as part of various initiatives of the S&I Framework. Overall, the Use Case Simplification Sub-Workgroup’s mission is to reconcile and further simplify the overall structure to the Use Case Outline, Functional Requirements, Dataset Considerations, Templates and Artifacts with the goal of making recommendations to the larger S&I Framework, allowing for reuse in future Use Cases. After the Functional Requirements are identified within a Use Case, they will then be incorporated into the UC Simplification matrix. Please reference the Use Case Simplification Wiki page for contact information related to the Workgroup Leads in order to send any correspondence.

Back to Top