Presentation is loading. Please wait.

Presentation is loading. Please wait.

0 Chicago, IL March 6 th, 2007 Use Case Requirements, Design and Standards Selection HITSP Use Case Requirements, Design and Standards Selection Date:

Similar presentations


Presentation on theme: "0 Chicago, IL March 6 th, 2007 Use Case Requirements, Design and Standards Selection HITSP Use Case Requirements, Design and Standards Selection Date:"— Presentation transcript:

1 0 Chicago, IL March 6 th, 2007 Use Case Requirements, Design and Standards Selection HITSP Use Case Requirements, Design and Standards Selection Date: March 6 th, 2007 Contract HHSP EC Requirements, Design and Standards Selection Template

2 1 Standards Harmonization Work Plan Tasks I Harmonization Request II Requirements Analysis III Identification of Candidate Standards IV Gaps, Duplications and Overlaps Resolution V Standards Selection VI Construction of Interoperability Specification VII Inspection Test VIII Interoperability Specification Release and Dissemination IX Program Management 3 months 3 weeks 3 months4 weeks 2 months On-going Requirements, Design and Standards Selection Public Review and Input Inspection Test and Public Comment Implementation Support and Testing Comment Resolution and Panel Approval Interoperability Specification Construct Development IS Docs V 1.0 Review Draft Summary of comment resolution IS Docs V 1.0 Summary of comment resolution Requirements, Design, and Standards Selection Consolidated comments Annual Updates as Required PROCESS TASKS DOCUMENTATION Requirements, Design and Standards Selection Template

3 2 Requirements, Design, Standards Selection Process  Many deliverables from last year into one RDSS document  Once this document is finalized, it is submitted to the Panel and Public for review and comments.  Technical Committee or Working Group dispositions the comments, maintaining a written log of all dispositions assigned to the TC/Workgroup  Persuasive comments will be used to inform the IS specifications that are being created in parallel.  Non-persuasive comments are deferred with explanation. Requirements, Design and Standards Selection Template

4 3 Requirements, Design and Standards Selection Sections  RDSS document has 3 main sections:  Requirements Analysis  Technical Design and definition of business and technical actors and transactions which are then mapped to HITSP constructs  Standards Selection with identification of Gaps and Overlaps Requirements, Design and Standards Selection Template

5 4 Requirements Analysis  Mapping from the Use Case Requirements to the Derived Business Requirements – lists the requirements grouped by actor for each event and related action  Data Element Requirements –further describes the data requirements for each specified business requirement and the business actor that is responsible for the data  Business Actors –defines the business actors that are included for the Interoperability Specification  High level UML Interaction (Business Sequence) Diagrams –used to describe the interaction between the business actors, and the actions involved in each scenario that is documented Requirements, Design and Standards Selection Template

6 5 Technical Design  Result of the requirements analysis and iterative standards selection process.  Describes scope of the design as it relates to the requirements for this Use Case  Provides a detailed mapping of the specified requirements to the business and technical actors, and data elements.  Detailed UML interaction diagrams showing the relevant actors, and related transactions  Groupings of specific actions and actors are then mapped to existing or new HITSP constructs Requirements, Design and Standards Selection Template

7 6 Standards Selection  Standards are selected using the Tier 2 Criteria  Presents the standards required to support the major Use Case events  Gaps where there are no standards and the recommended resolutions  Standards overlaps and the recommended resolutions Requirements, Design and Standards Selection Template

8 7 Chicago, IL March 6 th, 2007 Interoperability Specification Maintenance Process HITSP Interoperability Specification Maintenance Process Contract HHSP EC HITSP Specifications Maintenance Process

9 8 Interoperability Specification Maintenance  Define the types of changes that can be made and their significance  Provide an official HITSP definition of the terms ‘minor change’ and ‘major change’ for HITSP specifications  Provide a process for specification maintenance and the method by which the changes made are approved  Please send me your feedback to update and clarify definitions by the end of this week – definitions will be presented to Panel on March 19th HITSP Specifications Maintenance Process

10 9 Minor Changes  Corrections: For grammatical and technical errors or ambiguity in an Interoperability Specification inadvertently introduced either in drafting or in printing and which could lead to incorrect or unsafe application of the publication  Updates for outdated information: outdated information that has become outdated since publication, provided that the modification has minimal effect on the technical solution and processes described in the Interoperability Specification. This includes updates of the versions of current standards that do not result in changes to the underlying constraints to those standards. Or updates made by the SDO that does not introduce new functionality, remove existing functionality, nor introduce any backward compatibility issues.  Clarifications: The provision of examples or more detailed guidance and scenarios to provide a clearer definition and implementation view of the suggested processes and data outlined in the specification. These clarifications do not introduce new concepts or standards.  Re-categorizations of major changes: Changes that are by definition major changes, however, that are demoted to minor changes by Technical Committee leadership due to the minor repercussions of the changes. Technical Committee leadership is defined in the HITSP Technical Committee Operating Guidelines. HITSP Specifications Maintenance Process

11 10 Major Changes  Changes to Use Case: Changes to an Interoperability Specification that involve a change in the associated use case, requirements, or business actors.  Changes to Selected Standards: Changes in the design of the Interoperability Specification that are due to the selection of a new or different standard or HITSP construct.  Updates for outdated information: Changes made to update information that has become outdated since publication, where the modifications result in a change to the fundamental methodology of the exchange of data, technical solution or processes described in the Interoperability Specification. This includes updates of the versions of current standards that result in changes to the underlying constraints to those standards. Or updates made by the SDO that introduce new functionality or remove existing functionality.  Re-categorizations of minor changes: Changes that are by definition minor changes, however, that are elevated as major changes by Technical Committee leadership due to the global repercussions of the changes. Technical Committee leadership is defined in the HITSP Technical Committee Operating Guidelines. HITSP Specifications Maintenance Process

12 11 Change Approval Process: Minor Changes  Existing specification is cycled through Technical Committee to make necessary changes and to produce first a Working Draft, and then finally a Review Draft of the specification  Minor changes are reviewed by the Technical Committee and a final draft is produced  Final Draft specification with minor changes presented to panel and voted on by the Panel  If approved, the sub-version number is updated e.g. v2.1 becomes v2.2, etc. HITSP Specifications Maintenance Process

13 12 Change Approval Process: Major Changes  Existing specification is cycled through Technical Committee to make necessary changes and to produce first a Working Draft, and then finally a Review Draft of the specification  Review Draft specification with major changes is submitted for a Public and Panel comment period  Technical Committee dispositions comments and updates the document to produce a Final Draft Specification  Final Draft specification with major changes presented to panel and voted on by the Panel  If approved, the main version number is updated e.g. v2.0 becomes v3.0, etc.

14 13 Next Steps  Send feedback to me  Next Step is to finalize the change definitions  Clarify and update maintenance process by end of this week from Technical Committee feedback  Final version will be presented at the March 19 th Panel meeting HITSP Specifications Maintenance Process


Download ppt "0 Chicago, IL March 6 th, 2007 Use Case Requirements, Design and Standards Selection HITSP Use Case Requirements, Design and Standards Selection Date:"

Similar presentations


Ads by Google