Overview and Transition

1. Overview and Transition April 30, 2012

2. CONNECT Transition • Purpose: Provide an overview about CONNECT and the intent to transition CONNECT • Agenda • Overview and Background • Current Situation • Desired Changes • The Target: Transition CONNECT to Custodial Agent

3. Overview and Background: Vision and Goals • CONNECT Vision Statement • Accelerate CONNECTing anyone, anywhere, anytime for the secure exchange of healthcare information per the NwHINspecifications • Goals of CONNECT • Facilitate the exchange of health information among public, private, community and tribal health care entities • Enable greater interoperability of systems, while reducing costs and minimizing barriers and risks of implementation • Provide a venue for collaboration among the community of organizations that need and want to exchange health information • Enable the ability for the community to contribute to ongoing development and enhancement of features and functions and implementation of specifications

4. Overview and Background:Establishment of CONNECT Project The Federal Health Architecture (FHA) Program was established as an OMB E-Gov line of business (LoB) • To support federal activities related to the developmentand adoption of health IT standards • To ensure that agencies seamlessly and securely exchange health data with other agencies, other government entities, and with other public and private organizations The CONNECT Gateway Project was later established, as a separate OMB E-Gov LoB • To form a federal health IT consortium to jointly govern and develop CONNECT as a shared investment toward a common solution that would be deployed and operated separately utilizing existing standards and terminologies/value sets

5. Overview and Background: Description of CONNECT • CONNECT is one approach in a family of tools for health data exchange • Open-source software • Provides a secure web-services gateway to the Nationwide Health Information Network (NwHIN) Exchange • Serves as a reference implementation of NwHIN specifications • Intended for bi-directional transport of health data documents among partners • Requires centralized certificate management infrastructure • Code developed and tested centrally, made available to community • Currently not structured to accept code contributions from external entities CONNECT enables health organizations to: Support NwHIN-compliant exchanges Securely exchange health-related information among federal agencies, state agencies, health information exchanges, doctors’ offices, disability organizations, public health organizations, pharmacies, and others

6. Overview and Background: CONNECT Product Operational Context NwHIN The CONNECT product is composed of a Gateway, which provides the NwHIN interfaces, and an Adapter, which provides interfaces to the back-end systems. The Gateway is intended to be generic and configurable, so the Gateway as delivered can be configured and run in production without code modification. The Adapter code as delivered by the CONNECT project is not production quality – it is intended to be an example to guide implementations for specific back-end systems. In practice, the implementation boundaries between the gateway and adapter aren’t always clear. CONNECT Gateway Adapter Back-end Systems

7. Overview and Background: CONNECT Product Operational Context(detailed view) For additional info: connectopensource.org

8. Overview and Background: Benefits of Collaborating on CONNECT Reduced Costs • Agency collaboration in CONNECT’s development has saved the government $200 million* • Open Source Software license • Reduces development costs for adopters Public/Private Collaboration • Brings together stakeholders from all levels of the government and the private sector • Serves as a platform for participation in NwHIN • Supports Meaningful Use exchange goals • Provides national reporting of performance metrics National Distribution • Released to the open market • Health IT stakeholders can deploy the solution separately • Deployed to numerous organizations nationwide *Figure based on applying the Capers Jones model to the CONNECT project

9. Current Situation:Users and Stakeholders • Federal • Centers for Disease Control & Prevention • Centers for Medicare & Medicaid Services • Department of Defense • Department of Veterans Affairs • Indian Health Service • National Disaster Medical System • Social Security Administration Others…

10. Current Situation:Users and Stakeholders • Private and State Healthcare • ApeniMED • HIE-Bridge • Hielix • Marshfield Clinic • Guam HIE • Wright State Univ, Healthlink • Central Virginia Health Network • Community Health Information Collaborative (CHIC) • EPIC • HealthBridge • Indiana Dept of Health • Kaiser Permanente • MedVirginia • New York State Dept of Health • Redwood MedNet • Regenstrief • Southeastern Michigan Health Association • Thayer County Health Services • Washington Dept of Health Many organizations (> 2,000) leveraging Federal investment in CONNECT

11. Current Situation: Definitions of Functions • Governance - decision making authority over planning and integration • Planning – requirements gathering, determining priorities, planning codes releases, developing the roadmap • Development – writing code to implement defined requirements • Integration – integrating code into the CONNECT code base, conducting verification and validation testing, conducting various testing, preparing code for release

12. Current Situation: Current Model • Governance is centralized through a collaboration of federal funding partners and FHA • CONNECT Board of Directors • Change Control Board • Product Manager Group • Planning is done collaboratively through FHA and Federal Partners • Prioritized set of new feature and function requirements and enhancements to current functionality are captured in the “backlog” • The backlog is packaged into CONNECT releases • Development is centralized • ONC contracts for centralized development of CONNECT releases • Testing and Integration is centralized • Testing, on-boarding and O&M support • Software is released to public under permissive open source license • Release Management is centralized but implemented locally at the discretion of each agency. • Operations and Maintenance • ForCONNECT is centralized • For production systems is performed by each agency/organization • Funding is provided by Federal partners through FHA for central planning, development, integration, and test

13. Desired Changes: Justification of Changes • Centralized management and development of CONNECT to date has been value-added • CONNECT has been successful as a reference implementation for the NwHIN specifications • Multiple instances of CONNECT are in production as part of the NwHIN Exchange, with more partners on-boarding • Federal partners have been actively engaged in CONNECT planning, requirement specification and implementation management • Greater value going forward will be gained by leveraging partner engagement and embracing community contributions • CONNECT will continue to implement NwHIN specifications as they evolve • As the Exchange grows, an open, collaborative model will maximize value and optimize benefits • CONNECT has a large community of developers interested in contributing to the open source code base to enhance the product

14. Desired Changes: Nature of Changes • Development and Implementation Control become collaborative • Leverages community contributions and encourages innovation • Encourages communication among community members by healthcare community • Gives stakeholders greater control over the features they care about, by funding and managing their implementation • Governance and Planning become collaborative • Custodial Agent (CA) is a central point of coordination • Federal partners and other participants have direct input • Community plans may be shared, synthesized by CA, and shared in a “roadmap” • Integration Remains Centralized, in a different form • Centralized code integration and testing ensures integrity of CONNECT code • Collaboratively planned releases with community input allows visibility of process and maximizes community contribution

15. The Target: TransitionCONNECT Transition CONNECT to the Next Generation featuring Custodial Agent Coordination and Collaborative Development Present Future

16. Potential CONNECT+Architecture NwHIN • Lightweight Web Services gateway • Clearly defined, common interfaces • Implements only functionality required to meet NwHIN specs • Production quality code • Portable to many application servers • Memory and CPU efficient • Easy to install and run CONNECT+ ADAPT+ • Framework for common software services • Goal of substitutable software services • Common architecture, open source development • “Toolkit”, not necessarily production-quality • Custodial agent will curate some services • Others will be maintained by their owners Back-end Systems Federal collective investment in simpler, modular approach maintained by a Custodial Agency

17. The Target: Transition CONNECT to CA • Governance – performed by a Custodial Agent (TBD) • Planning –performed collaboratively by community, synthesized by Custodial Agent • Input from multiple sources (e.g., anyone can log a bug) • Output is CONNECT development roadmap, requirements and release plan • Development – Collaborative, performed by community • Organizations volunteer to develop features (using staff or contractors) • Completed work is submitted back to Custodial Agent and made available in code repository • No longer managed centrally by ONC • Testing and Integration – performed by the Custodial Agent (TBD) • Work is reviewed for standards adherence, integrated and tested by a Custodial Agent • Development organizations should coordinate efforts with the Custodial Agent • Code is released to public under permissive open source license • Release Management – performed by the Custodial Agent (TBD) • Operations and Maintenance • ForCONNECT is performed by Custodial Agent • For production systems is performed by each agency/organization

18. Agenda

19. CONNECT Open Source Model April 30, 2012

20. Outline • History of CONNECT and open source • Goals for community-based open source model • The Linux ecosystem analogy • Bazaar style open source model • Open topics for discussion

21. Current Cathedral Style Open Source Model ExternalDrivers • Specs • Requirements • Etc. Agency Specific Deployment & Operations Inputs Federal Agencies FHA Federal Agencies CONNECT Governance Open Source CONNECT Code States CONNECT Planning City / Local Dev/Test Envir Dev/Test Envir CONNECT Development Private Sector FHA CONNECT Integration Tech Vendors CONNECT Operations Input/Needs Funding Federal Agencies Direction = Development & Testing Envirironment Post / Retrieve Feedback

22. Open Source CONNECT Code Source Code Repository https://developer.connectopensource.org/display/CONNECTWIKI/Source+Code+Repository

23. Goals For New Development Model • Increase Breadth of Community Participation • More contributions from users, commercial vendors • Spread development costs over a larger user base • Eventually, reduce costs for Federal Partners • Increase product quality: “given enough eyeballs, all bugs are shallow” • Adopt “Bazaar Style” Open Source Model • Development performed collaboratively by community members • Central integration and release management by Custodial Agent

24. Analogy: The Linux Ecosystem Value-added Services Development/User Community Linux Distributions

25. Roles in the Linux Ecosystem • The Linux Foundation • Focuses on the managing the open source project • Responsible for the health and quality of the product • Responsible for the health and breadth of the community • Value-added Service Providers • Focuses on providing value-added services to customers • Responsible for the health of its customers • Development/User Community • Uses the product and submits bug reports • Contributes code/bug fixes to the open source project

26. Bazaar Style Open Source Model

27. Anticipated Role of the Custodial Agent • Establishes the governance framework • Encourages broad and deep community participation • Manages the project infrastructure • Focuses on the integrity of the product • Manages the architecture and development roadmap • Defines the integration and testing process • Coordinates product releases

28. Anticipated Role of Community Members • Community members can: • Use the product, based on released versions • Learn about development plans from the public roadmap • Discuss usage & development on the mailing lists • Submit bug reports as well as changes and bug fixes • Provide requirements to the Custodial Agent • Work with the Custodial Agent to fund and manage the implementation of roadmap features Community Members Federal Agencies States City / Local Private Sector Tech Vendors

29. Open Topics for Discussion • Licensing model for open source software • Community engagement strategy • Long-term sustainment of open source project • Leveraging open source infrastructure

30. Agenda

31. CONNECT Custodial AgentScope of Work April 30, 2012

32. Outline • Introduction • Community Based (Bazar Style) Open Source Model • Anticipated Custodial Agent: Some Key Roles • Other Possible Roles and Responsibilities Summary • Detailed View of Custodial Agent Roles and Responsibilities by Function • Summary

33. Custodial Agent Scope of WorkIntroduction • Gathering market perspectives on a notional Custodial Agent (CA) approach • This briefing defines anticipated: • Roles and responsibilities for a CONNECT Custodial Agent (CA) • Other possible roles and responsibilities

34. Community Based (Bazaar Style)Open Source Model

35. Anticipated Custodial Agent Some Key Roles • Manage CONNECT+ integration and testing • Perform testing of initial CONNECT+ codebase • Define test process/environment for code contributions • Coordinate CONNECT+ architecture • Coordinate CONNECT+ change requests • Synthesize CONNECT+ roadmap • Community outreach • Community website • Community development • Documentation • Innovation support • Education

36. Other Possible Roles and Responsibilities Summary • Executive Agent: • Establish Custodial Agent • Support Contractors • Integrate CA code releases with customer-specific changes • Develop customer-specific code • Develop core CONNECT+ code on behalf of customers • Coordinate the contribution of this code with the CA • Maintain customer-specific and general-purpose ADAPT+ code • Test/certify customer installations of CONNECT+/ADAPT+ • Production support for customers

37. Other Possible Roles and Responsibilities Summary (concluded) • Community • Use the product, based on released versions • Learn about development plans from the public roadmap • Discuss usage & development on the mailing lists • Submit bug reports as well as changes and bug fixes • Provide requirements to the Custodial Agent • Work with the Custodial Agent to fund and manage the implementation of roadmap features

38. Primary Roles and ResponsibilitiesSummary * The Custodial Agent could perform some functions in the Development and Operations categories

39. Detailed View of Program Management • Primary CA Functions • Establish and monitor groups • CA Governing Board • Management Team • Testing / Verification & Validation Team • Advise and broker technical direction for CONNECT

40. Detailed View of Governance • CA Governing Board • Formalize and scope the governance framework and its related process and accountability • Guide and determine strategic direction for CONNECT • Establish and generate agreement upon the design approach • Manage Roles and Responsibilities to ensure full coverage and compliance with strategic directions • Identify and maintain lines of responsibility • Provide and advance formal Concept of Operations • CA Management Team • Provide Compliance Management and advisement for operational systems • Advise and monitor the compliance with of technical requirements for CONNECT • Establish and enforce guidance for best practices • Establish and promote transparency in infrastructure development and process execution

41. Detailed View of Product Management • CA Governing Board • Identifies and communicates community needs • CA Management Team • Provide technical oversight and set high-level development milestones • Direct the independent testing efforts • Build and maintain relationships with other interested partners • Manage requirements • Communicate with all associated organizations • Plan and hold webinars, Code-A-Thons and other industry events

42. Detailed View of Planning • CA Roles • Perform Requirements Planning • Solicit requirements from the Community • Solicit requirements from submitted enhancement requests and other external sources • Ensure that all requirements comply with the specification • Manage architecture and develop roadmap • Manage Code Releases • Apply industry best practices • Provide subject matter experts

43. Detailed View of Development • CA Management Team • Create a Requirements Traceability Matrix (RTM) for product features • Validate designs against the supporting specifications

44. Detailed View of Testing and Integration • Basic Testing • Run all regression testing as new features are introduced • Conduct unit, integration, and full system testing • Multi-System Testing • Develop automated testing system to incorporate most if not all test cases • Conduct independent testing for both functional and nonfunctional elements • Multi-configuration testing (one to one and one to many) • Verification & Validation Team • Conduct testing for all supported platforms • Compare results to product documentation • Compare results to supported specifications • Provide results and recommendations

45. Detailed View of Release Management • Documentation • Provide all technical details needed for any announcements • Provide outreach material • Prepare all appropriate documentation for supported platforms • User guides and reference material (as needed) • Installation instructions • Design documentation • Release notes • Training material (as needed) • Software/Release • Prepare all appropriate source code for all supported platforms • Upload/Post all documentation and source code

46. Detailed View of Operations and Maintenance • CA Roles • Monitor all trouble ticket entries and respond accordingly • Identify trouble ticket from product enhancements and respond accordingly • Ensure the trouble ticket/enhancement submission system is available • Provide support and monitoring of online forums

47. Summary • The CA Scope of Work defines anticipated activities • Program management, Governance, Product Management • Planning, Development, Testing and Integration • Release Management, Operations and Maintenance • Separate roles for Custodial Agent and Support Contractor(s) • Custodial Agent: Responsible for health of product and community engagement • Support Contractor: Responsible for the health of its customers • Interested in feedback on possible approach

48. Questions?

49. Agenda

50. Lunch Break April 30, 2012