CHOS-WG : Software Development Issues

• Introduction:
• This chapter is dealing with sharing software at international level, while a separate chapter will look at the necessary support services.
• There are here 3 types of actions:
1. Definition of the desired specifications.
2. Inventory of currently available software in Open Source.
3. Strategies of implementations
    
   
• ( 1 )  Desired Specifications:
• Introduction:
• This chapter is intended to try to define common visions about where we believe we should go.  This exercise is a kind of brain storming not too much taking account of what is immediately achievable .  Relative priorities should be well given. 
• To write specifications is necessary but does not provide a warranty to get it done soon, but if no precise description would be written, there would be no chance to get it ever !
• This track will be mainly based on scenarios and on experimental prototypes.
  
• Levels of requirements:
• ( A ) Basic common requirements:
• Since the goal is to share software, the idea is to begin by seeking the most common requirements between the above projects.  This strategy will require a very modular approach.
  For example most projects need common concepts dealing with user authentication, authorization profiles, access rules protecting the confidentiality, multimedia content, synthesis of problem list, care plan management, access to medical knowledge, epidemiology, .............. as well kinds of generic frameworks providing some glue between these modules.
• First priority for this generic level A, because there is here the greatest potential for collaborations, based on shared developments and maintenances.
• ( B ) Additional specialized requirements:
• At a later stage, having agreements on basic common modules, we will look at specific "additional requirements" necessary for the diverse contexts of implementation, if GP, if home care, if emergency unit, if specialist, if nurse, if lab, if pathology, if epidemiology, if .. . , if ....... , if .........  , open source and documentation toolsIdentification of common requirements inside each of these groups.
• Possible agreements inside these specialized groups.
• ( C ) Additional regional requirements:
• Cultural requirements, spoken language, currencies, legal rules, economic constraint in emerging countries, etc...
• Agreement at regional level.
• ( D ) Arbitrary specifications:
• At the end the project should pay attention to maintain the freedom of the local users, in the case none of the above proposals would be accepted or only partially accepted at component level.  Of course this could not be shared and should be supported by means of local resources.  Some early version of advanced new development could begin in this way, and become shared and more widely used at a later stage.
• Scenarios:
• Review of typical scenarios
• Experimental prototypes:
• Experimental prototypes are expected to be very useful in order to stimulate critics and suggestions.  The users like a visual representation of the projects.
• Considered technical requirements:
• The framework itself is a critical component intended as a kind of "glue" between the diverse components.
• The main requirements are flexibility, integration capacity, MVC architecture, ergonomics, security, open source and documentation tools, .... and more at ../Tech/CHOS-Tech-Requirements.html .
   
  
• ( 2 )  Inventory of currently available open source software:
• Introduction:
• The first step is here to maintain an inventory of what is already available in Open Source.
  
• The next question is as far as possible how to reuse  software components in a more integrated perspective.
• Review of available Open Source softwares:
• Introduction:
• The objective is to maintain an inventory of available open source software with evaluations according to a set of criteria, including:
• modularity, 
• maturity,
• type of technology,
  
• .....
  
• Currently available packages:
• Medical softwares:
  
• ApfelKraut ,
  
• http://en.wikipedia.org/wiki/List_of_open_source_healthcare_software , ...
• Top 50 according to American colleagues., copy on 2 Apr 2009.
• Some projects represented in the Working Group, as for example  OSCAR, ..... (to be extended).
• When possible links to demo versions of these projects.
  
• .....
  
• General open source softwares:
• OSOR.EU, European Open Source Repository,
  
• ....
  
• ...
• Problems with the current open source softwares:
• Most medical softwares are designed as packages and not as modular components as we would need.  In general a package would be difficult to move to a new environment in a new country.
  
• Most are intended to specific target groups of healthcare professionals (e.g. GP, nurses, cardiologist, epidemiologists, ...), while what we would need is a more patient centric approach.
• Interoperability remain relatively poor, because collaborations are difficult as well between medical actors and as well as well between informatics developers.
   
  
• ( 3 )  Implementation Strategies:
• Introduction:
• Taking account of the 2 previous tracks, the question is here how to implement solutions.
• There will be of course some gaps between the ideal dreams and the currently available software.  Adaptations will be necessary to some extend, but since the resources for development are always limited, choices will have to be made.
   
  
• Modularity:
• Since collaborations between comprehensive packages are difficult, we need an evolution to a much more modular strategy.
• Principle of  components and projects .  What matter most is that at least some software component will be shared, and this is less difficult when dealing with smaller units of software.
• This approach will provide a choice to local implementations:
• If one can find suited modules covering at least 90 % of the requirements, take it as such, in a shared way with other international partners.
• If not, make what you are missing in your own way, but with your own resources as before.
• Repositories:
• New software component will be published in open source repositories.
  
• Open Source databases should be extended not only as packages as above, but with more focus on smaller software components, which could plugged yes or no into local implementations.  Even in some cases a choice could exist between more than one variant of a component intended for a given purpose.
• Technical framework:
• Everything will be seen as a component, including the framework itself, i.e. the technical environment allowing to integrate components.  This means agreements on interfaces between the components.  A difficult issue from the technical side, requiring the advices of experts in informatics.  The purpose of medical project is not to try to invent new technologies, but well to use up to date ones.
  For example, it looks now that new tools like the Python "Zope Component Architecture" could make flexible solutions less difficult.
• Today nearly every project has his own type of technical framework, i.e. far too many frameworks.  This number must be reduced although always keeping openness to a few significant innovations.
   
  
• Models:
• A large project need a reference model.
• See in annex a global healthcare model proposed for discussions .
   
  
• Communities sharing developments:
• Identification of an international community having similar needs.  The Open Source approach lower the barriers between different groups and make collaboration possible.
  
• Common components are made available for everybody.  If sufficiently valuable, common component can be reused.
  
• The development of new components can be distributed in an international community.  Normally partners are responsible each of a set of tasks.  However if necessary this could be changed, since open source projects avoid dependencies from any single provider.
  
• Shared collaborative developements using a versioning like http://bazaar-vcs.org/en/ and http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html .
  
• To some extend, elements from the experimental prototypes could be reused, but in general  they will need to be renewed or rewritten in a more professional way.  Their role was to facilitate the discussions and to provide validation of the specifications by the users.
  
• At the end shared developments are better affordable for every participant.
   
  
• "To do list":
• The working group will maintain a list of things to be done, about both adaptations of existing software as well creation of new components.
• More difficult is to find agreements on relative priorities is a such a long list.  Available development resources would be allocated to the highest common priorities.
• Maintenance issues are part of this list.  Indeed every software need an active maintenance, because soon or later additional requirements could appear, or because new technologies would work better, or sometimes because a bug could be discovered.
   
  
• Economic model related to pure development issues:
• At international level.
• Resources should be provided by government using taxpayer money and by foundations
• (an annex is coming soon ......... ).