slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Invitation to Join Open Health Tools PowerPoint Presentation
Download Presentation
Invitation to Join Open Health Tools

Loading in 2 Seconds...

play fullscreen
1 / 53

Invitation to Join Open Health Tools - PowerPoint PPT Presentation


  • 136 Views
  • Uploaded on

Invitation to Join Open Health Tools. Draft by Skip McGaughey skip@openhealthtools.org. AGENDA. Introduction Invitation Vision and Goals What is Open Health Tools Objectives of Open Health Tools Strategy Stakeholders Communities Who participates in Open Health Tools Foundation

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Invitation to Join Open Health Tools' - bly


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Invitation to Join Open Health Tools

Draft by

Skip McGaughey

skip@openhealthtools.org

agenda
AGENDA
  • Introduction
  • Invitation
  • Vision and Goals
  • What is Open Health Tools
  • Objectives of Open Health Tools
  • Strategy
  • Stakeholders Communities
  • Who participates in Open Health Tools Foundation
  • Early Adopter Program
  • Approach to Standards
  • Approach to Open Source:
    • Open Source Projects
    • Technology Schematic
  • Ecosystem Projects
  • Organization:
    • Governance Principles
    • Membership Qualifications
    • Membership Responsibilities
    • Specific Board Member Responsibilities
    • Membership Rights
    • Organization Schematic
  • Business Model
  • Schedule
open health tools formations
OPEN HEALTH TOOLS FORMATIONS
  • Open Health Tool Foundation is being formed and announced in fourth quarter 2007.
  • The following organizations are initial founding members:
    • National Systems:
      • National Health Service (NHS) in the United Kingdom,
      • National E-Health Transition Authority (NeHTA) in Australia,
      • Canada Health Infoway (awaiting final legal and board approval)
    • Standards Organizations:
      • HL7
      • HSSP (joint effort of HL7, OMG and others)
      • OMG
      • IHTSDO (awaiting final legal and board approval)
  • These organizations have provided tentative approval for the following governance documents:
    • Membership Agreement
    • Membership Bylaws
    • Intellectual Property Policy
    • Terms of Use
    • Membership Application
    • Logo Agreement
invitation
INVITATION:

The Founding Members by unanimous vote are inviting you to be a founding member.

vision of open health tools
VISION OF OPEN HEALTH TOOLS

Vision:

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.

goals of open health tools technology
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 process
  • Combine 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.
goals of open health tools ecosystem
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.
what is open health tools
WHAT IS OPEN HEALTH TOOLS?
  • A community of National, Regional & Local Health Services ProvidersOpen 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 OrganizationsOpen Health Tools is a community of health standards organizations who collaborate in providing health interoperability.
  • A community of Open Source DevelopersOpen 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 vendorsOpen 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
open health tools strategy
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
stakeholder communities
STAKEHOLDER COMMUNITIES

Community of Health Professionals

Community of National Health Services

Community of Vendors

Consumers

Providers

PatientsPhysicians

Community of Regional, State and LocalHealth Services

Community of Open Source Technology Developers

Community of Standards Organizations

early adopter program
EARLY ADOPTER PROGRAM

Objectives:

  • 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 applications

Participants:

  • Potential Consumers Vendors (TBD)
      • 4 Large national systems
      • 3 SDOs
      • 3 States (Phase 2)
      • 3 Regional systems (Phase 2)
      • 3 Municipalities (Phase 3)
the approach to standards
THE APPROACH TO STANDARDS

Strategy:

  • Adopt recognized industry standards and best practices in services.
  • Maintain close working relationships with identified SDOs
  • Provide 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, Services
  • OMG: technical specifications of services
  • IHE: pragmatic community for adoption
  • IHTSDO (SNOMED): Semantics, terminology definitions for healthcare
  • ASTM: CCR / CCD specifications
  • ISO/CEN/HL7: EHR requirements and specifications
  • ISO
the approach to open source
THE APPROACH TO OPEN SOURCE?

Open Health Open Source Is:

  • Royalty free source code
  • Open access to all source code
  • Multiple commercial friendly licenses
  • Not discriminatory or restrictive of any person or group of persons,
  • Rights to make derivative works
  • Rights to package, service, support, redistribute, brand and price with or without attribution
  • Principles 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.

the approach to open source1
THE APPROACH TO OPEN SOURCE?

Advantages of Open Health Open Source Technology

  • Provides 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 base
  • Enables 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.
open health open source projects
OPEN HEALTH OPEN SOURCE PROJECTS

ProjectsLeadership Roles

Committed

  • Platform Project Open Health Tools
  • HL 7 Messaging Tools Project NHS
  • Clinical Content Tools NHS
  • eHealthForge Project, Open Health Tools
  • SOA Tools Project, Open Health Tools

Pending or expressed interest

  • Terminology Tools Project, NEHTA / (IHTSDO)
  • Test and Conformance Tools Canada Infoway
  • Architecture Reference Implementations OPEN
  • Reference Application (Image) OPEN
  • Reference Application (Laboratory) OPEN
  • Reference Application (Pharmacy) OPEN
  • Public Health Analytics OPEN
  • State Government (Medicare / Medicaid) OPEN
  • State Government (Mental Health) OPEN
  • Tools to help SDO’s develop Standards OPEN

Common Technology Projects

  • SOA Device interface
  • Security Privacy and Trust Inpriva
open health ecosystem projects
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 distributions

Enable academic and research full participation

slide17

Healthcare Service Bus (HSB)

Provider Registry

Privacy Management

Community Management

Security Management

Document Processing

Terminology

Patient Resolution

Service Registry

Healthcare Information Exchange

PersonalHealth Record(PHR)

ElectronicHealth Record(EHR)

Public Health Reporting

Outbreak Management

De-Identified Patient Data Warehouse

HSB AccessNode

Open HealthIT Reference Implementation

Representative HIN Services

Interoperability Services

Open HealthIT Core Initiative

HSB SupportServices

Representative Commercial Services

R

R

R

R

R

R

R

R

R

R

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 Network

Infrastructure Services

Interoperability Services

Patient Information Services

Public Health Information Services

HL7 V3

EHR Viewer

Public HealthServices

PharmacySystem

RadiologyCenterPACS/RIS

Lab System(LIS)

Hospital, LTC,CCC, EPR

PhysicianOffice EMR

Public Health Provider

Pharmacist

Radiologist

Lab Clinician

Physician/Provider

Physician/Provider

Physician/Provider

POINT OF SERVICE

clinical application layers

Business Use Case

Clinical Content Model

Clinical Templates

Clinical Archetypes

Reference Model, Types, Terminology

CLINICAL APPLICATION LAYERS

Clinical Use Case

Terminology Tools

clinical application layers1

Business Use Case

Reference Model, Types, Terminology

Clinical Use Case

Clinical Content Model

Clinical Templates

Clinical Archetypes

CLINICAL APPLICATION LAYERS

Messaging Tools

clinical application layers2

Clinical Archetypes

Reference Model, Types, Terminology

Clinical Templates

Clinical Content Model

Clinical Use Case

Business Use Case

CLINICAL APPLICATION LAYERS

UI Tools

clinical application layers3

Clinical Archetypes

Reference Model, Types, Terminology

Clinical Templates

Clinical Content Model

Clinical Use Case

Business Use Case

CLINICAL APPLICATION LAYERS

Application Design

open health tools governance principles
Open Health Tools Governance Principles

Members are all equal

  • All members have single vote
  • All members sign same agreements:
    • Membership Application and bylaws
    • IP Policy
    • Web Site Terms of Reference
    • Logo Agreement
    • Committer and Contributor guidelines and agreements
  • Low barriers to entry with all members meeting same criteria

Open transparent environment

  • No confidential information
  • Well 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 transparent

Commercially friendly license to build vibrant eco-system

Contribution Model

  • Those who contribute decide
  • No obligations to contribute
  • Merit based contributions as selected by peers
membership qualifications
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 consumers
    • National, regional, state and local health service providers
    • Vendors and non profit organizations
    • Payers and public health organizations
    • Industry domain experts
  • Make a significant contribution to the success of Open Health Tools. The following are contribution examples:
    • Source code, designs and specifications
    • Intellectual property
    • Resources and expertise
  • Express public support for Open Health Tools
  • Sign the Open Health Tools Membership Agreement and Logo Agreement
membership responsibilities
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 membership
  • All 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
membership rights
Participate in:

Development Projects

Requirements Council

Architecture Council

Planning Council

Clinical Council

Finance Committee

Legal Committee

Membership Committee

Quarterly Project reviews

Hires & fires Executive Director

Terminates and reinstates Members

Approve:

Vision

Policy, plans & procedures

Release roadmap

Top Level Projects

Management budget

Formal affiliations

Legal counsel

IP policy

Amendments Bylaws & Membership Agreement

Actions affecting member liabilities

Can act as Spokesperson

MEMBERSHIP RIGHTS

Board Member Citizen of Ecosystem Member of Exec Committee

organization schematic overview

Members

Open Health Tools

Board of Stewards

Management Team

Councils

Projects

Committees

Officers

ORGANIZATION SCHEMATIC OVERVIEW

Executive

Finance

Membership

Legal

Compensation

Marketing

Executive Director

Secretary

CCO

CTO

Clinical

Requirements

Architecture

Planning

HL7 Messaging Tools

Terminology Tools

Test and Conformance Tools

SOA Tools

HSB Core Components

Technology Tools

Reference Application tools

business contribution model

Foundations

Individuals

Vendors

Government

Projects

Open Source

Ecosystem

Health

Friends of eHealth

Charitable Non Profit

Open Health Tools

Board of Stewards

BUSINESS / CONTRIBUTION MODEL

Contributes People

Contributes Money

Allocates MoneyPump priming

Matching Funds for Projects

Members are not obligated for financial contribution or dues.

schedule
SCHEDULE

Phase 0

  • Establish Initial Founding Members 2Q2007 Completed
    • NHS, NeHTA, Canada Infoway, HL7, OMG, HSSP
  • Create & agree to common governance documents 2Q2007 Completed
    • Membership Agreement
    • By-laws
    • Logo Agreement
    • Development process
    • Intellectual Property policy
  • Contract & establish hosting services 2Q2007 Completed
  • Phase 0 Bridge Funding 2Q2007 Completed
schedule1
SCHEDULE

Phase 1

  • Invite Founding Vendors 3Q2007
  • Finalize governance documents 3Q2007
  • Announcement 4Q2007
  • Establish Board of Stewards 4Q2007
  • Architecture congruence across Nationals Standards August 20, 2007 (AU)
  • Architecture congruence with invited vendors 4Q2007
  • Create and approve Councils with Charters 4Q2007
  • Create Roadmap 4Q2007
    • Define top Level Projects 4Q2007
    • Select Exemplary Applications4Q2007
    • Select Exemplary tools4Q2007
    • Select Technology tools4Q2007
  • Complete staffing 4Q2007
    • Chairperson, CCO, CTO, PR, Para Legal
open health tools is based upon the eclipse experience

Eclipse Foundation

Eclipse Open Source Community

Eclipse Eco-system

Open Health Tools is based upon the Eclipse Experience

The Eclipse Eco-system

The 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)

The Eclipse Open Source

The community builds the technology

has 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

open health tools communities
OPEN HEALTH TOOLS COMMUNITIES

Open Health Tools

Open Source Community

Open Health Tools

Eco-system

Private Public

Commercial

Applications

Code & Data

Non-Eclipse

Open

Source

Community

Eclipse Open Source Community

Eclipse Eco-system

The Open Health Tools Open Source

The community builds common services, frameworks, exemplary tools and example applications.

For example:

Record Locator Services & Hl7 Messaging Terminology Services & Identity Management

The Open Health Tools Eco-system

The community takes the Open Health Tools Technology and builds, packages, and sells the technology as products, applications, tools, for profit and use.

reference applications
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.
reference applications1
REFERENCE APPLICATIONS

Limitations

  • Open 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.
proposed top level projects i
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 frameworks
    • HSB core services
    • CDA viewer/editor
    • Other exemplary apps
  • HL 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 Designer
    • Dynamic Model Designer
    • Schema and Code Generators
    • Publishing Tools
    • Message Editing and Testing
    • Design Analysis and Verification
    • Artifact Repository and Configuration Management
proposed top level projects ii
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 Tools
    • HSSP Test and Compliance Tools
    • IHE Test and Compliance Tools
    • Others to be added based on community needs
  • eHealthForge Project, (Lead: Open Health Tools)Harvests and publishesnoteworthy 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 license
    • Peer 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.
proposed top level projects iii
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 data
    • Managing elements of the distributed system and routing messages between them
    • Simplifying 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.)
proposed top level projects iv
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 formats
    • Provide version and configuration management of terminology content
    • Collect, collate, and update terminology content from distributed sources
    • Deploy 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 time
    • Resolve value set contents at run time when a value set is bound to a static model attribute
    • Provide a reference implementation of HL 7 Common Terminology Service
technical organization
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 Councils
  • Management of Development Projects
    • Divided into Top Level Projects
    • Operate by open source rules: open, meritocracy, transparency, and peer review
    • Follows Eclipse open source development model
      • Charter, 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.
development resource model
DEVELOPMENT RESOURCE MODEL

Four kinds of resources:

  • Open Health Tools technical staff
    • Small number of domain and IT experts
  • Open source contributors
    • In-kind resources provided by Members
    • Other volunteer contributors
    • The largest source of resources
  • Funded open source projects
    • Small number of projects directly funded by Open Health Tools
    • Projects selected based on Open Health Tools priorities plus technical and financial merit
    • Matching Funding provided and managed at the project level
  • Top Level Project resources
    • Sponsoring organizations contribute resources
      • Architecture
      • Development
      • Project management
      • Executive and operational sponsors
      • Evangelists
    • Matching Resources provided by other Members and Open Health Tools
requirements council
REQUIREMENTS COUNCIL
  • Led by Chief Clinical Officer (CCO)
  • Membership
    • CC
    • CCO & CTO
    • Top Level Project Leaders
    • Peer selected members representing
      • Consumers
      • Institutions & Standards Bodies
    • CCO 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 Community
  • Deliverables
    • Statements of Requirement
      • Use cases
      • Applicable standards
      • Acceptance criteria
      • Priorities
    • Quarterly Reports to the Community
  • Use Eclipse as a model for other details
planning council
PLANNING COUNCIL
  • Led by CTO
  • Membership
    • CTO
    • Top Level Project Leaders
    • Peer selected members representing
      • Producers
      • Development Project Management Committees
    • CTO appointments (domain experts)
  • Responsibilities
    • Creation and management of development process
    • Creation and management of Road Map (jointly with Architecture Council)
    • Review of proposals for funded development
    • Monitor development projects
  • Deliverables
    • Development Process
    • Road Map
    • Proposal and Project reviews
    • Quarterly Reports to the Community
  • Use Eclipse as a model for other details
clinical council
CLINICAL COUNCIL
  • Act 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.
architecture council
ARCHITECTURE COUNCIL
  • Objective 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 designer
    • Structured Document Editors
    • Document Validation and Transformation tools
open health tools membership agreement
OPEN HEALTH TOOLS MEMBERSHIP AGREEMENT
  • Agree to vision & scope
  • Agree to Eclipse Public License where applicable
  • Members are organizations who select their Steward
    • Steward serves 2 year term
    • Member can terminate agreement at any time
    • Vote of 2/3 of Board terminates membership
      • Subject to notice and defense provisions
    • One vote per Steward
    • No representation for affiliated organizations
  • Costs & Board resources are the voluntary responsibility of members
  • There are no financial obligations for general membership
  • There are no obligations for general membership to make contributions of resources or technology to Open Health Tools
  • No member can bind the Open Health Tools or other members
  • Limitations
    • “as is basis”, without warranties or conditions, no liability
open health tools by laws i
OPEN HEALTH TOOLS – By-laws (I)

Composition of Open Health Tools Board

  • Stewards (one vote per member organization)
    • Nominated by member organization
    • Can terminate at any time
    • Can be terminated by 2/3 vote of Board
    • Term of 2 years renewable
  • Associates (no vote – member of technical, medical, business community)
    • Nominated by Stewards.
    • Can terminate at any time
    • Can be terminated by majority vote of Board
    • Term 1 year with automatic renewable
  • Project lead / Committer representatives (one vote per representative)
    • Elected by Project Leads / Committers
    • Term 1 year
    • Can terminate at any time
open health tools by laws ii
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 Board
    • Can terminate at any time
    • Can be terminated by majority vote of Board
    • Responsible for Board operations and chairperson of Executive Committee
    • Term 2 years (renewable)
  • Secretary (no vote)
    • Nominated by Steward(s) approved by majority of Board
    • Can terminate at any time
    • Can be terminated by majority vote of Board
    • Responsible for records, reporting, and Board membership communication and board membership lists
    • Term 2 years (renewable)

Board approves plans, policies, projects, programs of the Open

Health Tools organization

open health tools by laws iii
OPEN HEALTH TOOLS – By-laws (III)

Board appoints by majority vote the following positions

  • CCO, CTO
  • Project Leads
  • Medical leaders
  • Officers and Secretary
  • Permanent Committee Chairs (Finance, Membership, Legal, Compensation)
  • Executive Committee

Meetings of the Board

  • Place and time defined by Chairperson or 10% of existing Stewards
  • Annual meeting in Q1 of each year
  • Notice of 10 days (Special Meetings) or 30 days (Regular or Annual Meetings by eMail (or written)
  • Steward may send Alternate, or provide Proxy to another Steward
roles for achieving the vision

Open Health Tools

Board of Stewards

Manage Open Health Tools

Produce the Technology

Implement Health

Solutions

Enable the

Ecosystem

ROLES FOR ACHIEVING THE VISION
  • Enable Commercial Community
  • Open Health Tools Franchise
  • Service & Support
  • Education Training
  • End User Outreach
  • Research Academic
  • Distribution Hosting
  • Management Office
  • Hosting Services
  • Enable and manage collaboration
  • IP Due Diligence
  • Planning, Architecture, Requirements Councils and Project Management Committees
  • Design, plan and develop the projects
  • Coordinate internal and external development projects
  • Clinical Council
  • Enable Care Provider Community
  • Early Adopter Program
  • - National Systems
  • - State Systems
  • - Regional Systems - Municipal Systems
reporting structure

Members

Open Health Tools

Board of Stewards

Officers

Committees

Requirements

Planning

Architectural

Executive Director

Compensation

Executive

Membership

Clinical

Finance

Legal

CTO

Secretary

CCO

REPORTING STRUCTURE

Nominate Representatives

Appoints Stewards

*

Non-voting representation

Appoints

*

*

*

*

*

*

Councils

REPORTING STRUCTURE

* Indicates chairperson

technical development structure

Project Management

Committee

CTO

Board of Stewards

Committer Representative(s)

PMC Representative(s)

Project Management

Committee

PMC Lead

Committers

PMC Lead

Contributors

Contributors

Committers

Project Code

Repository

TECHNICAL DEVELOPMENT STRUCTURE

1

4

Appoints

4

4

4

2

2

6

6

3

3

6

6

5

5

Relationships:

1 – Makes appointment recommendations

2 – Appoint initial committer(s)

3 – Elect additional committers

4 – Reports to

5 – Has write access to

6 – Elects Board reps

eclipse and open health tools relationship
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 platform
    • Web tooling
    • Integrated Development Environments
    • Embedded tooling and run time environments
    • Date Tooling
    • SOA Tooling
    • Life Cycle Management
    • Test and Performance
    • Reporting and Business Intelligence
    • Modeling
  • Open Health Tools Board joins the Eclipse Foundation and elects a representative to be a Strategic Consumer on the Eclipse Board.
critical success factors
CRITICAL SUCCESS FACTORS

The following must be achieved to be successful

  • Create, 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 Information
    • Work flow processes
    • Skills and training
    • Existing standards
  • Information 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.