Participants:

Evgueni Loukipoudis (til 11:49 am), Karsten Klein, Martin Krasser, Alexander Ihls

Agenda and minutes

• New Projects
  After some discussions about the common understanding of the transition rules the TAB decided to give following projects the "public" status:
  Open eHealth Development Tools Project
  Open eHealth Application Platform
  
   Two more projects can be changed to "public" status after they fulfil the requirements of the transition rules and a review through the President:
  
  Open eHealth Integration Platform Tools
  Open eHelath Integration Platform Lab
  
   
• Processes and Rules
  The Project categorization and transition rules shall become reviewed to ensure that they are still valid and represent the actual discussion level. Alexander will provide a proposal before the next TAB meeting.
   
• Contributors and Committers Agreements
  Alexander pointed out that the meaningful use of both agreements shall be reviewed. In the discussion the need was declared to enhance the agreements with an advice to the initial project of a new Contributor or Committer. The complete agreements are  conditional to the technical granting of the corresponding permissions in a project by it's project champion.
   
• OeHF Infrastucture
  The actual infrastructure shall be advanced by a new hosted server to host the Confluence Wiki that shall be moved from the existing server. With this action the usage of the wiki will no longer be disturbed by build processes.
  Alexander will discuss the conditional steps with Siegfried Erb and is responsible for this action.

TAB Meeting - 29.01.2009

Agenda

• Evgueni: going through the action items from last meeting
  
  • reviewing the changes applied to the Technical Architecture
  • reviewing the Blueprint from Evgueni
  • Martin suggest to make the Blueprint a private project until the content is reviewed
• Discussion Project Phases / Transition Rules
  • incubation is a category of the first four project statues. We will not use the term incubation towards the community
  • package name requirement for public transition discussed; we agreed to keep it for now
• IPF Review
  • IPF was accepted for production status
• Application Platform and Development Tools Projects
  • Contribution slides from ICW presented
  • Projects have been acknowledged for private/planning
• ASL Header reviewed and updated on TAB wiki.

Action Items

• Karsten: improve representation of develoment tools and application platform in blueprint
• Evgueni: approve the Application Platform and Development Tools
• Evgueni: TAB project should be made private as agreed above
• Karsten: Propose package name for the Application Platform and Development Tools contribution
• Martin: Add the PDF documentation as a separate document in the DOC area of the IPF project

TAB Meeting - 13.11.2008

Participants: Evgueni, Geert, Martin, Karsten, Lindsay

Update from the Board Meeting

• Discussion of License Discussion. Geert was not aware of the choice of ASL2.0 and raised some concens. Martin and Karsten vote for ASL. Geert wants to investigate. Should be resolved untim next board meeting. Current choice is ASL. Lindsay is also in fine with ASL and values the openess of the license.
• Legal issues to be tackled

Purpose of the Group

• Create and maintain a technology roadmap
• Review pending projects and classfiy them to fit into the roadmap
• Define the technical goals of the Foundation
• Define the conventions and rules to be followed.
• Enable and manage proposals for improvement (conventions, rules, goals)
• Periodically review of progress (in key projects)
• Post call for projects for missing functionality
• Review requests for transtions incubation/production private/public transitions

Technical Architecture

• Review of the current content on the wiki ([Technical Architecture])
• Identified action item to review the content.
• Geert and Evgueni question whether the Open eHealth Development Tools are essential for the Technical Architecture page.

Review of Current Project Proposals

• clarify dependency of the current projects (there are currently no runtime dependencies)
• positioning of the IPF; in relationship to Open ESB
• scope of the application platform (core, codesystem, security; scope of the first contribution) 

Review of Package Names

• org.openehealth is mandatory
• the third level should be controlled by the TAB and must be kept unique

Review of License Header

• Copyright issue
• Original ASL header
• Contact

Decisions

• IPF is approved to go into public incubation (no votes agains; approved)
• Aggrement on IPF package name (org.openehealth.ipf)
• Meeting will be on a bi-monthly basis; every second meeting should be face-to-face (so once a quarter)

Action Items

• All: review and comment on [Technical Architecture] & [Openehealth Blueprint]
• Evgueni: provide big picture: [Openehealth Blueprint]
• Geert: clarifty open source license (for Board meeting)
• Evgueni: Define Incubation/Production Rules. Here Karstens' Proposal:
  • Code Quality
    • Coding conventions
    • Enforce coding conventions by checkstyle
  • Project Quality
    • Test Coverage
    • License Compliance
  • Identify interfaces of central interest
  • Identify cross-cutting concerns
  • Open eHealth Compliance Criteria
    • Security
    • Fit to other existing projects
  • Presentation of the Project Owner
    • current status of the project
    • code review results (from indendependent peer)
• Evgueni: Define Private/Public Rules. Here Karstens' Proposal:
  
  • Project Definition (whitepaper or reference) is reviewed by the TAB
  • Project is validated to be in the scope of the Foundation
  • The project offers code under the Apache Software License
  • The project adheres to the foundation package convention (suffixed by org.openehealth)
  • Once the public request is accepted the project owner controlls the users that have access to the project
• Karsten: outline contribution strategy (next meeting); request for transition to public incubation (End of Q1 2009)
• Richard: make IPF public (project and code)
• Evgueni: suggest date for the next meeting (somewhen in January 2009)
• Martin: ensure clear documentation on project level of IPF
• Evgueni: change tracker to include improvements requests
• Evgueni: change tracker to include project requests
• Lindsay: contribut documentation from java.net and support license decision

This page keeps the links to the main activities in the openehealth TAB

• [Technical Architecture] (the general architectural guidelines and principles of openehealth)
• [Candidate Incubation Projects] (a list of projects that can be contributed to openehealth)

Principles, guidelines and recomendation for project lifecyle, strcuture and  style:

• [Project categorization and transition rules] explain the statuses of projects and the rule to be followed for changes
• [Coding Guidelines] for all openehealth projects

Additional information related to the technical archicture and the openehealth blueprint:

• [Demonstrator Blueprint] (the architectural blueprint and specification of the demonstrator)
• [Openehealth Actors] (a list of actor-level modules that openehealth expects to cover in the longrun

Meeting notes of TAB sessions are captured in the pages below:

• [TAB Meetings]

• What is a [Wiki]? A description of this plugin.
• Learn HowToUseWiki and learn about AddingPages.
• Use the SandBox page to experiment with Wiki pages.
• Please sign your name in RecentVisitors.
• Find out which pages are MostPopular.

In this space we evolve the technical architecture of the Open eHealth Foundation. In its present state this page focuses on the Open eHealth Framework.

Positioning 

We position the Open eHealth Framework (OeHF) as a Framework to support the Development of Applications and Complete solutions in the Health Care Domain”. We’d like to emphasis on the Framework idea with its two aspects

• Development Platforms allowing partners to either develop software with and on top of OeHF (e.g. ICW with LifeSensor, telemonitoring solutions, hospital integration solutions ...) or ensure that their products are leveraged (e.g. MPI from SUN, IDM from Sun) or integrated (AGFAs ORBIS) by the Framework.
• Infrastructure Components and Services (that might correspond to complete IHE Actors) that can be used as building blocks of larger solutions, e.g. Document Registry, Document Repository and Terminology Services provided by OeHF used in building a Regional eHealth Network.

Introduction

The Open eHealth Framework is an endavour of the Open eHealth Foundation to ease and support the development of both messaging-oriented integration solutions and data-centric web applications in the healthcare domain. Data-centric web-applications are developed on top of the Open eHealth Application Platform whereas messaging-oriented integration solutions are developed on top of the Open eHealth Integration Platform. In context of the Open eHealth Foundation the Open eHealth Framework will be mainly used to provide open-source implementations of IHE profiles and actors. However, the Open eHealth Framework is not limited to the IHE domain and may be also used as a general-purpose framework for the development of distributed or standalone enterprise applications.

IHE Context

This section outlines how Open eHealth Framework applications relate to IHE profiles. Core concepts of IHE profiles are:

The Open eHealth Framework is a development framework with special support for the implementation of IHE concepts (i.e. profiles). This is illustrated with the abstract IHE profile in Figure 1. The profile defines three actors and two transactions. Transaction 1 is between actor 1 and actor 2 whereas transaction 2 is between actor 1 and actor 3.

Figure 1: Abstract IHE profile

IHE actors are usually represented by a single application or application component i.e. the actor - component relationship is 1:1 (IHE actor - component relationships may also be 1:n or n:1). Hospital information systems often play the role of IHE actors. If you plan to develop an IHE actor from scratch the Open eHealth Application Platform is the development framework recommended by the Open eHealth Foundation.

Usually custom developed clinical information systems expose interfaces that are not aligned to IHE profiles. In order to play the role of an IHE actor in IHE transactions these interfaces must be translated to IHE-compliant interfaces. Here's where the Open eHealth Integration Platform comes into play. Integration components, developed on top of the Open eHealth Integration Platform, translate internal proprietary actor interfaces to external IHE-compliant interfaces. In addition to interface translations, integration components may also coordinate the message exchanges between other actors (e.g. using a process engine). Other integration components may also implement IHE cross-cutting concerns e.g. logging relevant message exchanges (transactions) between IHE actors to a central logging server (see IHE ATNA).

Deployment options

Figure 2 gives an overview of the most relevant deployment options of application and integration components. In this overview actor implementations always run in separate processes whereas the deployment of integration components vary:

• Embedded deplyoment: Integration components run within the same process as actor implementations
• Standalone deployment: Integration components run on a single standalone integration hub (EAI style)
• Federated deployment: Integration components run on a distributed/federeted integration platform (ESB style)

Deployment options can of course be combined for IHE profile implementations. The Open eHealth Integration Platform supports all of the above deployment options.

Figure 2: IHE Profile deployment options

/*
 * Copyright <year> the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *     
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

Two types of projects are hosted by openehealth: private and public

• private are projects that are only visible to the members of the project and are generally used when a prioject is still in its early phases (internally refered to as incubation) or for doing experiments that might not necessarily end in public domain
  
• public are projects that are visible to the entire community and are open to membership applications from the contributer community. It is the responsibility of the project owner to control the membership and the access to the project

Requirements for changing the type of a project from private to public

• Project Definition (whitepaper or reference) is reviewed by the TAB
• Project is validated to be in the scope of the Foundation
• The project offers code under the Apache Software License 2
• The project adheres to the foundation package convention (prefixed by org.openehealth)

Project Statuses

During its lifecylte a project goes through the following 6 phases:

• planning
  
• pre-alpha
• alpha
• beta
• production/stable
• mature

Requirements for promoting a project from "beta" to "production/stable" state

• Code Quality
  • Compliance to Coding conventions
  • Enforcement of coding conventions by checkstyle
• Project Quality
  • Sufficient Test Coverage (proposal is 70%)
  • ASL 2 License Compliance
• Documentation Quality
  • Design documentation
  • Code documentation
  • Usage tutorials or samples
• Identify interfaces of central interest
• Identify cross-cutting concerns
• Open eHealth Compliance Criteria
  • Security
  • Fit to other existing projects
• Presentation of the Project Owner
  • current status of the project
  • code review results (from indendependent peer)