VIEWS: 5 PAGES: 9 POSTED ON: 9/9/2012
Technical Committee Restructuring • In recent months, HITSP TC leadership recognized a need to align TC resources to meet the needs generated by the increasing number of use cases and the expanding scope of use cases • TC leaders met face-to-face November 19th to address these concerns and to develop a restructuring proposal if needed • Following are notes from that meeting, including a proposal for the structure of HITSP Technical Committees for 2008 Considerations For Restructuring • The increasing number of use cases and sub-parts of use cases is splintering our HITSP TC resources • Responsibility for constructs overlaps across the use case groups • Unmet needs for maintenance and updating of prior artifacts • Limited resources – number of co-chairs, number of skilled volunteers, number of staff FTE • Need for clear responsibility for deliverables in each of the three dimensions • No matter what overall structure is chosen, still must agree on exact initial subgroup structure, e.g. domain s Objectives For This Meeting • Agree on a fundamental TC structure for 2008 • Agree on responsibilities for each TC • Agree on next steps – Suggest initial subgroups to responsible co-chairs – Timing for co-chair deliverables – Communications Plan – Transition Plan – What do we say when we leave the room TC Restructuring Proposal For 2008 In 2008 there should be 6 HITSP Technical Committees comprising: • 3 Perspective TCs, aligned with AHIC and ONC use cases – Population Perspective TC – Provider Perspective TC – Consumer Perspective TC • 3 Domain TCs with subgroups for agreed health care domains – Care Management and Health Records Domain TC – Infrastructure, Security and Privacy Domain TC – Administrative and Financial Domain TC Responsibilities and Deliverables of TCs: – Perspective TCs are responsible for Interoperability Specifications, and for Requirements and Design (RDSS) artifacts – Domain TCs are responsible for all other Construct artifacts – Each TC determines its own internal structure – Each TC may deputize members to lead subgroups, and co-chairs remain responsible for TC activities Restructuring Proposal Perspective Technical Committees Security & Privacy Workflow and Process Knowledge Representation Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Terminology And Messaging and Datatypes Care Management and Health Records Technical Committee Modeling Domain Infrastructure, Security and Technical Committees Privacy Technical Committee Administrative and Financial Technical Committee - TC Leadership Oversight Foundations - Communications function Committee Meeting Notes and Agreements 1 Discussion Questions, Issues and Challenges (Answers) 1. Need knowledge transfer (This is true regardless of structure) 2. Need success criteria (Input, transfer of responsibility, delivery to internal and external customers, intermediate internal process measures) 3. Need inbound and outbound process definition (Easier in new structure) 4. Need to define customers (Both internal and external customers, including the “expanded” external customer base of implementers outside ONC) 5. Need to define what project team resources are needed (Depends on workflow, may or may not need additional project team resources) 6. Need to define workflow process for construct development (Most process work should focus on the IS integration problem and efficiency improvements, Perspective committee should propose a draft RDSS and ask Domains to fill in) 7. Construct ownership must be defined (General rule: ISs in Perspective TCs, other Constructs in Domain TCs, there may be exceptions in some cases) 8. Need some staff FTE for each domain workgroup and each foundational area (see #5 above) 9. Need to ensure consumers are not left out of the equation (Consumer perspective TC is intended to be responsive to Consumer needs) Meeting Notes and Agreements 2 HITSP Artifact Responsibilities 1. Use Case Perspective IS Technical Committees: - Interoperability Specifications and RDSS (exclusive) 2. Domain Technical Committees & Workgroups - All Domain constructs other than Interoperability Specifications and RDSS 3. Foundations Committee & Workgroups - Foundations strategy and guidance documents Note: any committee may publish technical notes Meeting Notes and Agreements 3 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), including timing of each step within overall timelines and external expectations and dependencies - to include joint leadership review of draft requirements w/ IRB - to include maintenance process - to include communications processes • Formally define communications plan Meeting Notes and Agreements 4 • 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 Construct grows – 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.
Pages to are hidden for
"TC Restructuring Proposal From TC Leadership.ppt - HITSP"Please download to view full document