HITSP Internal Review Board

1. HITSP Internal Review Board Planning Meeting 12/12/07

2. IRB Membership and Leadership • TC volunteer members of IRB • Co- Chairs: Eric Pupo, Charles Parisot • Other members - Steve Hufnagel, Steve Wagner, experts as needed • Staff • Facilitator for IRB - Jack Corley • Other Staff members of IRB – Ed Larsen, Bob Yencha, Gene Ginther

3. IRB Dec 12 Telecon Agenda • Overall IRB Planning • Determine meeting schedule - Regular schedule and/or Ad hoc • Identify Priorities and work schedule for the work items • Other Items for Discussion • Implications of TC Restructuring • Address Near-term Items IRB has been asked to address: • For each existing IS, identify level of effort to implement • “Interoperability Ranking” Concept –discussion started on last IRB call • HITSP Framework – How Does Technical Note Fit?

4. Work Items To Prioritize And Schedule • Establish and operationalize process as Internal Reviewer of Interoperability Specifications to • Ensure consistent application of the Framework • Maximize reuse of HITSP constructs • Address TC Restructuring Implications • Note – Maximize staff use to reduce load on volunteers • Near-term Items IRB has been asked to address: • Evaluate current HITSP Technical Framework (note addition of Technical Note) • For each existing IS, identify level of effort to implement • Identify processes and timing for deliverables that are less than a full Interoperability Specification – the “Interoperability Ranking” Concept

5. Level of Effort to Implement an IS – Conceptual Definition • For each existing IS, identify level of effort to implement - this would be a high-level estimate, perhaps as simple as small, medium, and large

6. HITSP Interoperability Ranking Concept

7. HITSP Interoperability Ranking Concept Background • Need to be responsive to many needs for harmonized standards (CCHIT, NHIN 2, other efforts to advance interoperable health IT nationally). • HITSP required to develop an “Interoperability Ranking” process • Obvious and non-contentious standards in key areas will be fast tracked for harmonization • May not have specificity or implementation guidance to offer the level of interoperability of HITSP Interoperability Specifications.

8. Draft Interoperability Ranking Concept • Increasing levels of Interoperability Ranking • High - HITSP Interoperability Specification • Intermediate: Implementation guidance exists, but is incomplete (e.g., some syntactic interoperability, but limited business or semantic interoperability) • Initial – A high level, “named” standard exists, little guidance as to what parts of, or how, that standard should be implemented; Standard lacks granular implementation guidance. • It is understood that Initial and Intermediate rankings would have significantly less quality, rigor, and reliability. • Need to think of process steps – assess request, validate level requested is appropriate, schedule and identify funding source

9. Initial IRB Thinking on Interoperability Ranking Concept • Initial – Doesn’t seem to add much value; Need practical examples where this would make sense • IRB looked at specific situations for CCHIT, NHIN2, etc. – didn’t see where it would help • Most areas this might apply to are either 1) very obvious standards choice and HITSP could add little or nothing; or 2) Too much confusion exists to make a sensible statement • Intermediate: Implementation guidance exists, but either • Guidance is incomplete (e.g., some syntactic interoperability, but limited business or semantic interoperability); or • HITSP has not done a thorough evaluation • High - HITSP Interoperability Specification; our process • It is understood that Intermediate ranking would have significantly less quality, rigor, and reliability. No plans for addressing Initial Ranking

10. Draft IRB Process for Intermediate Interoperability Ranking • Intermediate - Implementation guidance exists, but is incomplete (e.g., some syntactic interoperability, but limited business or semantic interoperability) or there is a lack of thorough evaluation by HITSP • Need Simplified Use Case – ala IHE – but not to event/action code level • Identify business actors, scope and assumed scenario • Do design at level higher than RDSS document • Initial target – reuse of existing HITSP constructs • For gaps, we point at existing implementation guides developed by other SDOs (e.g., IHE, Oasis, HL7) without doing the level of analysis we would do for an IS • Use reuse tool? • Must be implementable and deliver interoperability

11. TC Restructuring

12. Restructuring Proposal Perspective Technical Committees Care Management and Health RecordsTechnicalCommittee Infrastructure, Security and Privacy Technical Committee Administrative and Financial TechnicalCommittee Population Perspective TC Provider Perspective TC Consumer Perspective TC Cross-TC Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Security & Privacy Workflow and Process Terminology And Knowledge Representation Messaging and Datatypes Modeling Domain Technical Committees - TC Leadership Oversight - Communications function Foundations Committee

13. Meeting Notes and Agreements - HITSP Artifact Responsibilities • Use Case Perspective IS Technical Committees:- Interoperability Specifications and RDSS (exclusive) • Domain Technical Committees & Workgroups- All Domain constructs other than Interoperability Specifications and RDSS • Foundations Committee & Workgroups- Foundations strategy and guidance documents Note: any committee may publish technical notes

14. Meeting Notes and Agreements - Next Steps • Formalize Critical Success Factors for business customers, strategic and operational (see next page) • Define transition plan- Elections should depend on transition plans- Cross-TC groups to elect co-chairs? • Formal process definition and documentation (esp. to promote reuse), with timing of each step in overall timelines, expectations and dependencies, to include:- Joint leadership review of draft requirements w/ IRB- Maintenance process- Communications processes • Formally define communications plan

15. Meeting Notes and Agreements - Draft Initial Critical Success Factors • Maintain and slight growth in volunteer Types 1, Moderate growth for type 2, facilitate engagement of type 3s (pool of future Type 1&2). • Avoid TC leadership burn-out by recruiting among Type 1 volunteers. • Minimize inconsistencies, or late discovery of inconsistencies, especially as number of IS and Constructs grow • Reduce workload on constructs development and maintenance (farm-out but oversee). • Ensure non disruptive reorganization (cannot afford to loose participants or discontinue maintenance activities). • Provide a reasonably easy to read organization for “new comers”. • Scale organization for 4 new use cases every year and maintain 50 constructs and 15 ISs by 2009.

16. Healthcare Information Technology Standards Panel HITSP Framework – not discussed on this call September 15, 2007

17. HITSP Approach • Use Harmonization process to define a set of artifacts called constructs that • Specifies how to integrate and constrain selected standards to meet the business needs of a Use Case • Defines Roadmap to use emerging standards and to harmonize overlapping standards when resolved • The HITSP Framework describes • Types of constructs that could be used to specify how to meet the needs of a Use Case. • Defines specific rules for each construct type, including: • What a construct type can used for. • How construct types can be nested.

18. HITSP Harmonization Framework • HITSP construct types, in decreasing breadth of scope, include: • Interoperability Specification – integrates all constructs used to meet business needs of a Use Case • Transaction package – Logical group of transactions • Transaction - logical group of actions that use components and/or composite standards to realize the actions • Component - groups of base standards that work together, such as message and terminology • Each construct: • May contain construct types that are less inclusive in scope • May constrain any construct or standard it contains. • May be constrained by any construct that contains it • Is a candidate for reuse and repurposing, if a new set of requirements and context can be fulfilled by the construct without impacting existing uses of the construct • Is uniquely identified and version controlled

19. Transaction Pkg. (Composite) Transaction (Composite) Component (Composite) Available for Internal reuse HITSP Framework Defines Context Use Case/Modification Request Interoperability Specification Transaction Package (1..m transaction packages, transactions, or components) Transaction (1..n components or composite standards) Potential for Internal Reuse Component (1..c base or composite standards) SDOs Base Standard #1 Base Standard #2 Base Standard #3 Base Standard #4 Base Standard #5 Base Standard #... Base Standard #n

20. Definitions and Rules

21. Definitions and Rules (continued)

22. Definitions and Rules (continued)

23. Composite and Base Standards

24. Or Technical Note ? Transaction Pkg. (Composite) Technical Note Transaction (Composite) Component (Composite) Available for Internal reuse HITSP Framework – How Does The Concept of a Technical Note Fit? Defines Context Use Case/Modification Request Interoperability Specification Transaction Package (1..m transaction packages, transactions, or components) Transaction (1..n components or composite standards) Potential for Internal Reuse Component (1..c base or composite standards) SDOs Base Standard #1 Base Standard #2 Base Standard #3 Base Standard #4 Base Standard #5 Base Standard #... Base Standard #n

25. Backup Material

26. HITSP Internal Review Board (IRB)Draft Terms of Reference (1 of 2) • Charter: Support TC Leadership and Project Team by providing: • Review and, as needed, recommend changes to HITSP technical framework • Rapid assessments of technical issues and TC plans • Small team (e.g., 8) • Appointed by TC Leadership and Project Team Management • Formed of volunteers from TC Leadership and Project Team • Subject-matter experts as needed for special-topics • Program management has identified 4 staff members – Ed Larsen, Bob Yencha, Gene Ginther, and Jack Corley • TC Leadership recommendations for volunteer membership – Charles Parisot, Steve Wagner, Steve Hufnagel, and Eric Pupo • Determine own leadership and meeting schedule

27. HITSP Internal Review Board (IRB)Draft Terms of Reference (2 of 2) • Meetings • Open, with minutes kept • Participation limited to active members, including subject-matter experts as needed. • Project team support will be provided as possible. • IRB work products submitted to TC, and then, if necessary, to TC Leadership and Project Team for approval and other necessary action. • Priorities and work schedule • IRB will determine • Submit to TC Leadership and Project Management for concurrence.

28. HITSP IRB Activities, Status, and Plan • Evaluate current HITSP Technical Framework • Establish and operationalize process as Internal Reviewer of Interoperability Specifications to • Ensure consistent application of the Framework • Maximize reuse of HITSP constructs

29. HITSP IRB Activities: Evaluate current HITSP technical framework • Includes • HITSP artifacts - RDSS, IS, constructs, subcomponents such as actors and data elements • Use of base and composite standards • Goal: Establish mechanisms and process to continuously improve the mechanisms to • Maximize reuse and repurposing • Minimize unnecessary duplication • Make best use of technical tools, e.g., UML models • Insure consistency across framework and all constructs, standards, actors and data wherever possible • Devise technical strategy for documents and sub documents, e.g., statements to optimize reuse, repurposing and consistency • Make any recommendations for improvement to TC Leadership and Project Team

30. HITSP IRB Activities: Establish and operationalize process as Internal Reviewer • Review new use cases and standards harmonization requests with strong emphasis placed on identifying opportunities for repurposing and reuse. • Recommend Interoperability Specification architecture design approach to TC and TC Leadership • Review and recommend change as indicated to TC work prior to release for comment to ensure compatibility with HITSP technical framework and guidelines for Proper Use, Reuse and Repurposing.

31. DRAFT Proposal Revised HITSP Process Ed Larsen/Jack Corley Contract HHSP23320054103EC October 25, 2007

32. Process Assumptions • ONC adheres to annual cycle starting with prototype Use Cases for Comment in September with final Use Cases delivered in December • HITSP adheres to a fixed annual cycle for new Interoperability Specifications in response to new Use Cases • HITSP cycle starts in January and targets panel approval in October • Based on complexity, TC will pursue Panel IS approval by November • External entities (e.g., Secretary, CCHIT) will maintain their own schedules • Maintenance and update releases of ISs and constructs can occur whenever necessary based on agreement of TC and Leadership • These cycles are superimposed on annual cycle for new IS • No more than 1 update release of same construct in a year • Routine maintenance releases as needed, no more than once a year • HITSP staff will consolidate development cycle as much as possible

33. RDSS Comments Revised HITSP Process 1 Month 1 Month 2-3 Months 3 Months 3 Months Preliminary Use Case Analysis Preliminary Project Plan RDSS Interoperability Constructs Inspection Test/ Public Comment Interoperability Specifications, System Integ. Preliminary Use Case Final Use Case 2-3 Months Maintenance Resolve and Disposition Comments Panel Approval, Public Release Implementors/SDO Feedback

34. Analysis and Comments on Use Case • This becomes a formal TC process, presumably in the September – October • TC Leadership/Project Team will assign responsibilities • TCs hold meetings to review and develop formal comments to AHIC ONC, focused on clarifications and on technical feasibility and business needs

35. 2. Preliminary Project Plan • To identify overall scope, resources, phasing and schedule • TC Leadership in consultation with ARB and Project Team will assign Use Case to TC • Leaders of the TC with facilitators and Project Team • Conducts a high level evaluation of Use Case • Defines preliminary approach and plan to IS that • includes scoping, phasing, resource and scheduling. • Sets out benchmark dates and will be periodically reviewed and modified by the TC leaders and facilitators working with Project Team

36. 3. Requirements analysis, design and standards selection (RDSS) • The TC will • Complete RDSS based on preliminary plan • Extract requirements from Use Case and enter them into RDSS template • Establish a high level design (scoping, review of Reuse Tool, and plans to use existing or new constructs). • ARB will review design for • consistency with HITSP Framework • Adherence to Design Principles (Reuse, Repurposing, Compatibility, etc.) • Cross TC issues

37. 3. RDSS (Continued) • The TC will • Resolve any cross TC issues including repurposing • Complete design section of RDSS template and assemble candidate standards for new or repurposed constructs • Assess standards against Tier 2 criteria and mark as tentatively selected • RDSS document will be completed, reviewed by ERB and published for public comment • RDSS comments will be resolved during construction of the IS

38. 4. Interoperability Specification Construction • The TC will • Implement RDSS detailed design and complete Interoperability Specifications for inspection testing and public comment • Evaluate public comments and use to inform construction of IS and its constructs and disposition in comment tracking tool by publication of IS • Complete the IS and constructs in template formats with staff support • ARB will review any changes to RDSS design and provide feedback • TC will produce final draft for ERB review and formal publication for inspection testing and public comment

39. Resolve Comments and Republish • The TC will • Make final edits and present to Panel for approval • Disposition all test results and comments in comment tracking system and make appropriate edits and changes to the IS and constructs • Consult with the ARB as necessary • Release to publication process at least two weeks prior to request for approval from Panel • The ERB will • Review final documents • make editorial corrections as needed • Consult with TC to resolve content issues as needed • HITSP will release to the Panel at least 5 business days prior to expected approval

40. Panel Approval and Formal Release • Upon approval by Panel, production team will release and post final versions of IS and constructs • If Panel fails to approve an IS or construct it will be returned to the TC to resolve issues Panel identified

41. 7. Maintenance and Support • TBD

42. The Project Team Functions: • Develop and maintain preliminary and ongoing project plan in conjunction with the TC leaders and assigned staff • Provide templates • Organize and manage the inspection testing • Maintain the comment tracking system • Participate in the Architectural Review Board (ARB) • Act as the Editorial Review Board (ERB) • Conduct and manage document production and publication • Coordinate communications with ONC