Presentation on theme: "Invitation to Join Open Health Tools"— Presentation transcript:
1 Invitation to Join Open Health Tools Draft bySkip McGaughey
2 AGENDA Introduction Invitation Vision and Goals What is Open Health ToolsObjectives of Open Health ToolsStrategyStakeholders CommunitiesWho participates in Open Health Tools FoundationEarly Adopter ProgramApproach to StandardsApproach to Open Source:Open Source ProjectsTechnology SchematicEcosystem ProjectsOrganization:Governance PrinciplesMembership QualificationsMembership ResponsibilitiesSpecific Board Member ResponsibilitiesMembership RightsOrganization SchematicBusiness ModelSchedule
4 INVITATION:The Founding Members by unanimous vote are inviting you to be a founding member.
5 VISION OF OPEN HEALTH TOOLS To enable a ubiquitous ecosystem where members of the Health and IT professions can collaborate to build open, standards-based interoperable systems that enable patients and their care providers to have access to vital and reliable medical information at the time and place it is needed.
6 GOALS OF OPEN HEALTH TOOLS (Technology) Design and Develop Open Health Technology:Specifically we will create and enable an open source community of software developers to design and develop open standards based technology that meets interoperability requirements early adopters.Utilize an Open Source Paradigm to form a community and develop the technology which enforces an open and transparent communication and coordination software development processCombine open standards programs, open source development, multiple cooperating vendors and major health consumers into successful software technology deliverables.Combine a series of councils to integrate the technical/IT and clinical communities. Create Clinical (physician and health professional), Architecture, Planning, and Requirement Councils to assure the software technology is designed, tested and meets the needs of the targeted end users.Create and maintain a technology harvesting program to identify, outreach and absorb aligned health industry software and provide the hosting environment to make publicly available under multiple licenses.
7 GOALS OF OPEN HEALTH TOOLS (Ecosystem) Enable a Healthy Ecosystem to Deliver Open Health Technology :Specifically we will support profit based organizations to create, enable and nurture a community of individuals, vendors, commercial and public organizations to deliver the Open Health Technology.Grow the membership at a sustainable pace with broad participation from diverse communities including public institutions, vendors, users, academia, and developers.Build self defining, self actualizing teams that share economies of scale and community collaboration to achieve their collective common self interests.Create, enable and nurture a third party Open Health Certification program so that the Open Health Technology is a trusted source for interoperable health tools.
8 WHAT IS OPEN HEALTH TOOLS? A community of National, Regional & Local Health Services Providers Open Health Tools is a community of major health providers from several countries, regions, and local organizations who recognize that a common interoperable platform and exemplary tools for medical records is essential to effectively and efficiently meet the needs of patients, physicians, providers, payers as well as policy makers.A community of health professionals Open Health Tools is a community of health professionals who collaborate in providing the requirements for technology and interoperable information systems to improve the quality, safety and efficiency of human health.A community of Open Standards Organizations Open Health Tools is a community of health standards organizations who collaborate in providing health interoperability.A community of Open Source Developers Open Health Tools is an open source community focused on developing a Health Information Platform of frameworks, exemplary tools and reference applications that make it easy and cost-effective to build and deploy software in today’s connected and unconnected world.A community of vendors Open Health Tools is a consortium of major software vendors who utilize the Open Health Technology to create wealth, increase profit and market share, while providing expertise and assets to the community
9 OPEN HEALTH TOOLS STRATEGY Enable a community of individuals, vendors and organizations to integrate appropriate standards, early adopter implementations, reference applications and the necessary integration tooling to support this community.Enable healthcare information interoperability by providing a common software tool platform based upon open standards for creating software.Provide a range of exemplary tools and several reference / example applications to facilitate the use of and illustrate the Open Health Tool Technology.Provide software tooling to enable easy integration with existing systems and processes.Create, nurture and enable suppliers to participate in an ecosystem that allows them to profit from open standards and open source software.Enable an environment and management system that is open, transparent, and is based upon a meritocracy
10 STAKEHOLDER COMMUNITIES Community of Health ProfessionalsCommunity of National Health ServicesCommunity of VendorsConsumersProvidersPatients PhysiciansCommunity of Regional, State and Local Health ServicesCommunity of Open Source Technology DevelopersThe rectangle demonstrates several interacting components that influence interoperability.There is a complex set of relationships between the four corners of the square. The National Health Services, used generically to include such players as the NHS, Infoway, Nehta, Veterans Health Administration etc – have strong ties with all the players.Note that no side of the pyramid alone produces interoperability. Though we can improve the mechanisms of interoperability to “state of the art” technology using standards-based middleware and mechanisms such as dynamic discovery, interoperability cannot be achieved unless the corresponding information has semantic meaning.Interoperability is achieved as one scales the pyramid, improving the semantic integrity and understanding of the knowledge, as well as improving the access mechanisms by which that knowledge can be attained.At the peak (but not actually part of the pyramid) is the software application itself. These applications, built upon many or all of the components depicted below it, provide the integrating mechanism by which the component technologies and knowledge come together to provide business value.Community of Standards Organizations
11 EARLY ADOPTER PROGRAM Objectives: Participants: Drive the technology, requirements, and standards into successful customer engagements that meet the needs of the customers that are then incorporated into the technology, and standards.Establish customer, physician, patient requirements as paramount in the development and deployment of the several reference applications and tools.Create 3 or 4 exemplary early implementations to help plan, design, develop and deploy successful reference health applicationsParticipants:Potential Consumers Vendors (TBD)4 Large national systems3 SDOs3 States (Phase 2)3 Regional systems (Phase 2)3 Municipalities (Phase 3)
12 THE APPROACH TO STANDARDS Strategy:Adopt recognized industry standards and best practices in services.Maintain close working relationships with identified SDOsProvide feedback to SDOs via early adopter program and communities to foster creation of useful, usable healthcare standards that address real healthcare requirements.Important SDOs:HL7: CCD, Semantics, Documents, ServicesOMG: technical specifications of servicesIHE: pragmatic community for adoptionIHTSDO (SNOMED): Semantics, terminology definitions for healthcareASTM: CCR / CCD specificationsISO/CEN/HL7: EHR requirements and specificationsISO
13 THE APPROACH TO OPEN SOURCE? Open Health Open Source Is:Royalty free source codeOpen access to all source codeMultiple commercial friendly licensesNot discriminatory or restrictive of any person or group of persons,Rights to make derivative worksRights to package, service, support, redistribute, brand and price with or without attributionPrinciples of openness, transparency, and meritocracy applying to all projects and activities.Symbiotic relationship between Open Standards and Open Source. Open Health Tools implements Open Standards.
14 THE APPROACH TO OPEN SOURCE? Advantages of Open Health Open Source TechnologyProvides a well established & proven development process to deliver quality software on schedule, within budget, by small collaborative teams.Provides a well established and proven collaborative environment to enable vendors to optimize their self interest while collaborating and competing.So vendors will incur lower costs and time to market advantages to leverage extensive base of high quality free source code and skills baseEnables a large virtual community of developers to grow with the software, resulting in:improved quality due to open rigorous peer review with many developers,extensive tuning and improvement of the software,rapid porting of code to new hardware and platforms,rapid response to changing requirements and conditions,detailed understanding of how the system works due to the open, transparent nature of process.Enables multi vendor, multi platform and multi language solutions.
15 OPEN HEALTH OPEN SOURCE PROJECTS Projects Leadership RolesCommittedPlatform Project Open Health ToolsHL 7 Messaging Tools Project NHSClinical Content Tools NHSeHealthForge Project, Open Health ToolsSOA Tools Project, Open Health ToolsPending or expressed interestTerminology Tools Project, NEHTA / (IHTSDO)Test and Conformance Tools Canada InfowayArchitecture Reference Implementations OPENReference Application (Image) OPENReference Application (Laboratory) OPENReference Application (Pharmacy) OPENPublic Health Analytics OPENState Government (Medicare / Medicaid) OPENState Government (Mental Health) OPENTools to help SDO’s develop Standards OPENCommon Technology ProjectsSOA Device interfaceSecurity Privacy and Trust Inpriva
16 OPEN HEALTH ECOSYSTEM PROJECTS Enable niche market creation:Enable rich after markets e.g. Education, Services ,Enable multiple total product solutions,Provide links and aggregation services for Members & their products.Enable Member collaboration and networking:Enable tools to self identify and self organize,Enable language specific target markets (French Japanese, Korean, German, Mandarin)Enable Member lead mindshare and PR activities:Analysts briefings,Press and mindshare activities,Collaborative advertising,Joint reference accounts,Joint collateral and content creations and distributionsEnable academic and research full participation
17 Healthcare Service Bus (HSB) Open Health Tools -- Service Architecture To: drive the architecture (Strawman), continual iteration between customer needs, standards and reference builds, Collaboration based upon vested self interest,Health Information NetworkInfrastructure ServicesInteroperability ServicesRRPatient Information ServicesPublic Health Information ServicesProvider RegistrySecurity ManagementHL7 V3RRRRHealthcare Information ExchangeElectronic Health Record (EHR)Outbreak ManagementPatient ResolutionPrivacy ManagementTerminologyRRDe-Identified Patient Data WarehousePersonal Health Record (PHR)Public Health ReportingService RegistryCommunity ManagementDocument ProcessingRPublic Health ServicesPharmacy SystemRadiology Center PACS/RISLab System (LIS)Hospital, LTC, CCC, EPRPhysician Office EMREHR ViewerPublic Health ProviderPharmacistRadiologistLab ClinicianPhysician/ ProviderPhysician/ ProviderPhysician/ ProviderPOINT OF SERVICEHSB Access NodeHSB Support ServicesInteroperability ServicesRepresentative HIN ServicesRepresentative Commercial ServicesOpen HealthIT Core InitiativeROpen HealthIT Reference Implementation
18 CLINICAL APPLICATION LAYERS Business Use CaseClinical Use CaseClinical Content ModelClinical TemplatesClinical ArchetypesTerminology ToolsReference Model, Types, Terminology
19 CLINICAL APPLICATION LAYERS Business Use CaseClinical Use CaseClinical Content ModelClinical TemplatesMessaging ToolsClinical ArchetypesReference Model, Types, Terminology
20 CLINICAL APPLICATION LAYERS Business Use CaseClinical Use CaseClinical Content ModelClinical TemplatesUI ToolsClinical ArchetypesReference Model, Types, Terminology
21 CLINICAL APPLICATION LAYERS Business Use CaseClinical Use CaseClinical Content ModelApplication DesignClinical TemplatesClinical ArchetypesReference Model, Types, Terminology
22 Open Health Tools Governance Principles Members are all equalAll members have single voteAll members sign same agreements:Membership Application and bylawsIP PolicyWeb Site Terms of ReferenceLogo AgreementCommitter and Contributor guidelines and agreementsLow barriers to entry with all members meeting same criteriaOpen transparent environmentNo confidential informationWell established open software development processes and guidelines which are published and open to all.All deliberations of Board and Councils are open. (Only personnel matters are private.)All projects are open and transparentCommercially friendly license to build vibrant eco-systemContribution ModelThose who contribute decideNo obligations to contributeMerit based contributions as selected by peers
23 MEMBERSHIP QUALIFICATIONS Public and private organizations and individuals who:Participate in the health industry. The following are examples:Governmental institutions and standards bodies;Producers and consumersNational, regional, state and local health service providersVendors and non profit organizationsPayers and public health organizationsIndustry domain expertsMake a significant contribution to the success of Open Health Tools. The following are contribution examples:Source code, designs and specificationsIntellectual propertyResources and expertiseExpress public support for Open Health ToolsSign the Open Health Tools Membership Agreement and Logo Agreement
24 MEMBERSHIP RESPONSIBILITIES Specific Board Member Responsibilities:Each member organization appoints one person to serve as a Steward (ie voting member of Board of Directors)Steward represents your organization in establishing the Open Health Tools policies, behavior, plans, priorities, technology plans and directions.Steward should be a senior executive who can allocate resources and represent their respective organization.Time commitment is one day per quarter for board meetings.Each board member can appoint a delegate and an employee to be a member of the executive committee, which meets periodically and is responsible for operations.Obligations:There are no financial obligations for membershipAll contributions are voluntary and based upon self interest. Beyond the initial contribution there are no obligations to contribute.No member can bind the Open Health Tools or other members.All technology is provided on an “as is basis”, without warranties or conditions, no liability
25 MEMBERSHIP RIGHTSBoard Member Citizen of Ecosystem Member of Exec CommitteeParticipate in:Development ProjectsRequirements CouncilArchitecture CouncilPlanning CouncilClinical CouncilFinance CommitteeLegal CommitteeMembership CommitteeQuarterly Project reviewsHires & fires Executive DirectorTerminates and reinstates MembersApprove:VisionPolicy, plans & proceduresRelease roadmapTop Level ProjectsManagement budgetFormal affiliationsLegal counselIP policyAmendments Bylaws & Membership AgreementActions affecting member liabilitiesCan act as Spokesperson
26 ORGANIZATION SCHEMATIC OVERVIEW MembersOpen Health ToolsBoard of StewardsManagement TeamOfficersCommitteesCouncilsProjectsExecutive DirectorSecretaryCCOCTOExecutiveFinanceMembershipLegalCompensationMarketingClinicalRequirementsArchitecturePlanningHL7 Messaging ToolsTerminology ToolsTest and Conformance ToolsSOA ToolsHSB Core ComponentsTechnology ToolsReference Application tools
27 BUSINESS / CONTRIBUTION MODEL FoundationsIndividualsVendorsGovernmentContributes MoneyContributes PeopleAllocates Money Pump primingMatching Funds for ProjectsProjectsOpen SourceEcosystemHealthFriends of eHealthCharitable Non ProfitOpen Health ToolsBoard of StewardsMembers are not obligated for financial contribution or dues.
31 Open Health Tools is based upon the Eclipse Experience Eclipse Open Source CommunityThe Eclipse Eco-systemThe community takes the Open Source Technology and build products for profit and use.The community includes 800,000 vendors and organizations, 10 Leadership Projects, 150 Members, in 120 countries project.The economic value of the “free” code is $700,000,000 (USD). The commercial value of the revenue generated to members is in excess of 2 Billion (USD)Eclipse FoundationEclipse Eco-systemThe Eclipse Open SourceThe community builds the technologyhas over 4 million developers and 120 open source projects. These projects can be conceptually organized into seven different "pillars" or categories:-Enterprise Development-Embedded and Device Development-Rich Client Platform-Rich Internet Applications-Application Frameworks-Application Lifecycle Management (ALM)-Service Oriented Architecture (SOA)The Eclipse Foundation Enable & Manage Eclipse-Infrastructure Support-Intellectual Property-Legal-Marketing-Enable Eco-system-Enable Open Source
32 OPEN HEALTH TOOLS COMMUNITIES Open Source CommunityOpen Health ToolsEco-systemPrivate PublicCommercialApplicationsCode & DataNon-EclipseOpenSourceCommunityEclipse Open Source CommunityEclipse Eco-systemThe Open Health Tools Open SourceThe community builds common services, frameworks, exemplary tools and example applications.For example:Record Locator Services & Hl7 Messaging Terminology Services & Identity ManagementThe Open Health Tools Eco-systemThe community takes the Open Health Tools Technology and builds, packages, and sells the technology as products, applications, tools, for profit and use.
33 REFERENCE APPLICATIONS Objectives:Build quality software by stressing the technology to meet the real time needs of users.Design, develop and deploy several reference applications to demonstrate the performance, viability, scalability and usability of the technology. Provide examples of these capabilities.Utilize the reference applications to assure that the data, business logic, communications, and tools are integrated and interoperate as appropriate. Provide examples of these capabilities.Introduce and integrate the deployment and implementation methodologies in real world environments.Assure the reference applications meet the needs of the early adopters.Create several reference applications that can be used as samples and examples to assist developers to demonstrate the development process and functionality.
34 REFERENCE APPLICATIONS LimitationsOpen Health Tools will be limited to 2 or 3 reference applications.Actual reference applications will be approved by the Board.The Open Health Tools Foundation is prohibited from generating revenue from reference applications.The Open Health Tools Foundation is prohibited from supporting or providing services for fees.Any private, public, or commercial entity can use the reference applications. They can:brand, support and, service the reference applications in any way they desire;bundle, package and distribute, locally or world wide, based upon their channels and partner programs;freely distribute the software assets with or without attribution.
35 PROPOSED TOP LEVEL PROJECTS ( I ) Platform (Lead: Open Health Tools) Create reference implementations of cross-platform runtime infrastructure, specifically, Healthcare Service Bus core components and services as specified in the Architecture and Road Map.Cross-platform frameworksHSB core servicesCDA viewer/editorOther exemplary appsHL 7 Messaging Tools Project (Lead: NHS) Assemble and/or develop a comprehensive, harmonized tool suite to enable definition, development and deployment of semantically interoperable EHRs.HL7 Messaging (HTC Road Map)Static Model DesignerDynamic Model DesignerSchema and Code GeneratorsPublishing ToolsMessage Editing and TestingDesign Analysis and VerificationArtifact Repository and Configuration Management
36 PROPOSED TOP LEVEL PROJECTS ( II ) Test and Conformance Tools (Lead: Canada Infoway)The project will work with other Open Health Tools projects to insure that Open Health Tools components can be certified as compliant to applicable standards – relieving vendors who adopt Open Health Tools products from the cost of such certification.HL 7 V3 Test and Compliance ToolsHSSP Test and Compliance ToolsIHE Test and Compliance ToolsOthers to be added based on community needseHealthForge Project, (Lead: Open Health Tools) Harvests and publishes noteworthy Applications and Tools that deliver significant value to the community and/or illustrate the use of the open source technology.Levels of noteworthy Applications and Tools:Contributed: made available by members under an appropriate open source licensePeer Selected: a Contributed application or tool that has been peer selected on the basis of criteria such as technical excellence, innovation, market leading, etc.Exemplary: Peer Selected application or tool that conforms to OHF Architecture and is based on OHF technology; illustrates best practices.
37 PROPOSED TOP LEVEL PROJECTS ( III ) SOA Tools Project, (Lead: Open Health Tools) Service Oriented Architectures and Web Services technology, based on Sun Java 2 Enterprise Edition (J2EE) or Microsoft .NET infrastructure, support the assembly of loosely coupled distributed systems from existing IT system elements. This principally requires the development of a Healthcare Services Bus (HSB), which is the essential shared infrastructure, and a set of common services providing such functions as Identity Management, Health Record Location, Security, Privacy, Data Mapping and Transport, and so forth. Wrappering existing APIs in order to publish new web services (mainly these are code and schema generators)Creating and parsing XML based representation of EHR dataManaging elements of the distributed system and routing messages between themSimplifying SOA interactions and service composition by using programming models (typically this translates to a combination of code generators with coding guidelines and conventions)Administration of the resulting distributed SOA based system (e.g. error handling, logging, etc.)
38 PROPOSED TOP LEVEL PROJECTS ( IV ) Terminology Tools Project, (Lead: NEHTA / IHTSDO (SNOMED CT))Tools are required to manage, develop, update, maintain, search and deploy terminologies. Terminology management tools must provide consistent and standardized access across disparate terminology sources through a common set of vocabulary APIs, and support access across a federated vocabulary distribution model. Tools will be developed to:Create and maintain coded concepts, value sets, and domains in a controlled and repeatable formatsProvide version and configuration management of terminology contentCollect, collate, and update terminology content from distributed sourcesDeploy versioned terminology content with appropriate support for traceability and audit.Make terminology content accessible from modeling tools such as HL 7 Message Tools, e.g.Specify static and dynamic binding of vocabulary elements to a static model attribute at design timeResolve value set contents at run time when a value set is bound to a static model attributeProvide a reference implementation of HL 7 Common Terminology Service
39 TECHNICAL ORGANIZATION Technical activities led by Chief Technology Officer (CTO)Health information at the clinical, medical, technical and administrative management will be provided to the Requirements, Architecture, Planning, Medical CouncilsManagement of Development ProjectsDivided into Top Level ProjectsOperate by open source rules: open, meritocracy, transparency, and peer reviewFollows Eclipse open source development modelCharter, Project Management Committee, contributor categories, etc.Projects may be hosted at other organizations where appropriate and by agreement (e.g. Oregon State University, Eclipse, Apache)In some cases projects will be self-hosted by Open Health Tools.
40 DEVELOPMENT RESOURCE MODEL Four kinds of resources:Open Health Tools technical staffSmall number of domain and IT expertsOpen source contributorsIn-kind resources provided by MembersOther volunteer contributorsThe largest source of resourcesFunded open source projectsSmall number of projects directly funded by Open Health ToolsProjects selected based on Open Health Tools priorities plus technical and financial meritMatching Funding provided and managed at the project levelTop Level Project resourcesSponsoring organizations contribute resourcesArchitectureDevelopmentProject managementExecutive and operational sponsorsEvangelistsMatching Resources provided by other Members and Open Health Tools
41 REQUIREMENTS COUNCIL Led by Chief Clinical Officer (CCO) Membership CCO & CTOTop Level Project LeadersPeer selected members representingConsumersInstitutions & Standards BodiesCCO appointments (domain experts)Responsibilities:Harvesting and analyzing requirements from existing public, private, and commercial health and standard organizations,Harvesting and analyzing requirements from academic, research, publications and data bases,Identifying, documenting and management of requirements,Identify and reconcile applicable standards,Liaison with Healthcare CommunityDeliverablesStatements of RequirementUse casesApplicable standardsAcceptance criteriaPrioritiesQuarterly Reports to the CommunityUse Eclipse as a model for other details
42 PLANNING COUNCIL Led by CTO Membership Responsibilities Top Level Project LeadersPeer selected members representingProducersDevelopment Project Management CommitteesCTO appointments (domain experts)ResponsibilitiesCreation and management of development processCreation and management of Road Map (jointly with Architecture Council)Review of proposals for funded developmentMonitor development projectsDeliverablesDevelopment ProcessRoad MapProposal and Project reviewsQuarterly Reports to the CommunityUse Eclipse as a model for other details
43 CLINICAL COUNCILAct as a control point to assure the design, development and deployment of the Open Health Tools systems, applications, and tools to meet the needs for the Health Professionals.Act as a control point to assure early adopters wants and needs are met.Integrate with public health research and organizations.Direct the investigation, evaluation of existing Health Information Systems and direct the other councils to accommodate the results of this research and investigations.Lead the User Interface design teams to assure the design and redesign of the application and tool solutions to meet the needs of the Health Professionals.Work with expert clinician panels, and user groups to assure capture of local, regional, national and international assessment requirements.Responsible the efficacy measures, clinical requirements for patient care, and utilization assessment measures.Responsible for design, development and deployment methodology to collect, measure, analyze and publish Health Outcomes.Act as a liaison to health organizations to collect the requirements, manage the relationships , and assist in the knowledge transfer between the Open Health Tools and the respective health organizations.
44 ARCHITECTURE COUNCILObjective is to have a unified architecture that specifies a common set of specifications that can be used to create reference implementations.Service Architecture will be based on requirements from NHS, NEHTA, Infoway and other early adopters.Architecture will be based around documents, services and components.Documents will be based on HL7 V3, with CDA as the preferred document where possible.Services will be specified using SCA and designed to give an appropriate balance between granularity and flexibility.Services will be based on HSSP (Joint HL7/OMG process) specified services where possible.The services will be specified as Web-based Services where possible.Components will be specified to assist with using documents and services:Template/archetype designerStructured Document EditorsDocument Validation and Transformation tools
45 OPEN HEALTH TOOLS MEMBERSHIP AGREEMENT Agree to vision & scopeAgree to Eclipse Public License where applicableMembers are organizations who select their StewardSteward serves 2 year termMember can terminate agreement at any timeVote of 2/3 of Board terminates membershipSubject to notice and defense provisionsOne vote per StewardNo representation for affiliated organizationsCosts & Board resources are the voluntary responsibility of membersThere are no financial obligations for general membershipThere are no obligations for general membership to make contributions of resources or technology to Open Health ToolsNo member can bind the Open Health Tools or other membersLimitations“as is basis”, without warranties or conditions, no liability
46 OPEN HEALTH TOOLS – By-laws (I) Composition of Open Health Tools BoardStewards (one vote per member organization)Nominated by member organizationCan terminate at any timeCan be terminated by 2/3 vote of BoardTerm of 2 years renewableAssociates (no vote – member of technical, medical, business community)Nominated by Stewards.Can be terminated by majority vote of BoardTerm 1 year with automatic renewableProject lead / Committer representatives (one vote per representative)Elected by Project Leads / CommittersTerm 1 year
47 OPEN HEALTH TOOLS – By-laws (II) Composition of Open Health Tools Board (cont)Chairperson (vote only if tie)Nominated by Steward(s) approved by majority of BoardCan terminate at any timeCan be terminated by majority vote of BoardResponsible for Board operations and chairperson of Executive CommitteeTerm 2 years (renewable)Secretary (no vote)Responsible for records, reporting, and Board membership communication and board membership listsBoard approves plans, policies, projects, programs of the OpenHealth Tools organization
48 OPEN HEALTH TOOLS – By-laws (III) Board appoints by majority vote the following positionsCCO, CTOProject LeadsMedical leadersOfficers and SecretaryPermanent Committee Chairs (Finance, Membership, Legal, Compensation)Executive CommitteeMeetings of the BoardPlace and time defined by Chairperson or 10% of existing StewardsAnnual meeting in Q1 of each yearNotice of 10 days (Special Meetings) or 30 days (Regular or Annual Meetings by (or written)Steward may send Alternate, or provide Proxy to another Steward
49 ROLES FOR ACHIEVING THE VISION Open Health ToolsBoard of StewardsEnable theEcosystemProduce the TechnologyImplement HealthSolutionsManage Open Health ToolsEnable Commercial CommunityOpen Health Tools FranchiseService & SupportEducation TrainingEnd User OutreachResearch AcademicDistribution HostingPlanning, Architecture, Requirements Councils and Project Management CommitteesDesign, plan and develop the projectsCoordinate internal and external development projectsClinical CouncilEnable Care Provider CommunityEarly Adopter Program- National Systems- State Systems- Regional Systems - Municipal SystemsManagement OfficeHosting ServicesEnable and manage collaborationIP Due Diligence
50 REPORTING STRUCTURE REPORTING STRUCTURE MembersNominate RepresentativesOpen Health ToolsBoard of StewardsAppoints Stewards*Non-voting representationAppointsExecutive*Executive DirectorOfficersMembershipSecretaryCommitteesCompensationCCOLegalCTOFinance*****ClinicalRequirementsArchitecturalPlanningCouncilsREPORTING STRUCTURE* Indicates chairperson
51 TECHNICAL DEVELOPMENT STRUCTURE Committer Representative(s)Board of StewardsCTO1PMC Representative(s)Appoints44Project ManagementCommitteeProject ManagementCommittee44262PMC LeadCommittersContributorsPMC LeadCommittersContributors3663655Relationships:1 – Makes appointment recommendations2 – Appoint initial committer(s)3 – Elect additional committers4 – Reports to5 – Has write access to6 – Elects Board repsProject CodeRepository
52 Eclipse and Open Health Tools Relationship Open Health Tools is a loosely coupled industry vertical satellite of Eclipse Foundation.Open Health Tools has its own governance, legal, fiscal, technical, and management structure to enable appropriate health representation in the creation of the plans, policies, programs, and projects that are relevant to the human health.Where possible Open Health Tools will leverage the technology, platform, licensing and communities of Eclipse. This will include:Extensibility platformWeb toolingIntegrated Development EnvironmentsEmbedded tooling and run time environmentsDate ToolingSOA ToolingLife Cycle ManagementTest and PerformanceReporting and Business IntelligenceModelingOpen Health Tools Board joins the Eclipse Foundation and elects a representative to be a Strategic Consumer on the Eclipse Board.
53 CRITICAL SUCCESS FACTORS The following must be achieved to be successfulCreate, manage, store, and retrieve an interoperable Electronic Health Record (EHR) which conforms to industry standards. Enable provision of adapters and generators to transform existing EHR’s into interoperable EHR’s.Information is accessible to authorized persons when they want it, how they want it, and where they want it. Preserve and protect the privacy, security, and identity of individuals and systems.Enable the integration of existing environments into new Open Health IT Solutions:Data and InformationWork flow processesSkills and trainingExisting standardsInformation systems that are easy to learn and use so that the patients, physicians and other stake holders become advocates and proponents.Provide Open Source Technology and pilots to enable ubiquitous information exchange.