Open Source Software Market Place in Healthcare

Draft version 2.7,  2 April 2009, Etienne Saliez /

• Introduction:
  • The question is how we could better share know how in informatics applications.
  • The main objective is to share knowledge and know-how about softwares, not as private property but as "commons" shared in the international public domain.
    By the way informaticians working on the development of new Open Source software components should have right to normal incomes.  The idea is that many small donations can support great projects.
    
  • Current limiting factors of Open Source collaborations ?  
    • Many potential users have demands which could efficiently be resolved with an Open Source approach.  They are a little disappointed because they do not immediately find the software they would like, on the shelf and ready for use immediately.  No vendors are coming at the door trying to sell what they have and b.t.w. which is not necessarily what the users need.
    • Many developers are very motivated, but do not see enough perspectives where to go and what to do first.  It is no normal that Open Source developments receive nearly no incomes.
    • Sustainability should be better managed.
    • The importance of "Open Standards" and "Free-Open Source" is not yet largely understood.  Many users have problems due to dependencies from one unique commercial providers.  
      
  • Evolution:
    • Large generic software tools like Linux, Apache, OpenOffice, etc... are already success stories, 
    • The situation is not yet obvious at the application level, in domains like health care, education, city administration, etc... i.e. domains in which users need similar software of common public interest and where organizations are in general not directly competing between different regions.
      The initial effort of this project focus on the requirements of healthcare applications.  However healthcare informatics is simply a group of applications focusing on healthcare context, but using many software tools shared with other application domains.
      
  • This page is a draft intended to become available on " http://www.oss-market.eu " and  " http://www.oss-market.org ". (reserved name but not yet implemented).
    
    
• Objectives:
  • Vision on an economic model for Healthcare Informatics based on Open Source.
  • Management of a market place where users having dreams and Open Source developers can meet and negotiate agreements, bridging the current gap between these 2 groups.
    
    
• Development issues:
  • Pure developments issues:
    • The main idea is to promote the reuse of software, i.e. Open Source software.
      Open Source means to share knowledge and know how, including the sources codes and the complete documentation.
    • More information about the Open Source approach can be found at ( http://www.opensource.org/ ) and many other site as the FSF, the Free Software Foundation ( http://www.gnu.org/ ).  
      Remark :  this note make use of the colloquial English expression "Open Source", but the full name is normally "Free and Open Source Software" ("FLOSS"), meaning that both the use and the content of the source are free.
      
    • Sharing knowledge is of particular importance in health care, a social domain obviously of common interest worldwide.
    • Software development is a continuous process.  New requirements become on the priority lists and improved new versions should become available every few months.  There fore the strategy is based on incremental developments.
    • Sharing healthcare developments is something that need to operate at international level.
       
  • Object oriented methodology:
    • First a model starting from generic root classes and trying to cover the most common properties, as expected to be necessary to any healthcare applications.
    • Derived classes will extend the common software in function of the specific additional requirements of medical specialties and of local requirements due to cultural differences.
       
  • Modularity:
    • Today several software medical packages are already available in Open Source, but the problems are that large software packages do not necessarily fit exactly the need of an other environments in other countries.  Moreover groups of Open Source developers may have difficult to collaborate, due to human factors.
    • The essential goal is not to claim to be Open Source, but to achieve reutilization of shared developments, at least the reuse of some components:
      • Therefore solutions need to be based on a great modularity.  It is indeed much easier to share components than packages.  New sites should remain free about the choice to reuse or to make components according to their own feelings and ego.  However in practice there is too much to be done for any isolated local team.  
        
      • To be pragmatic if you think that a module covers 90 % of your needs, it would not be reasonable nor possible to reinvent everything just in a little different way.  The solution is to take it temporarily as it is, and to propose some improvements for the next versions, with explanations why you need extension and how it would be more generic for everybody.  
      • Experience show that differences between implementation sites in different countries are often essentially a questions of relative priorities, while at the end everybody need soon or later most functionalities.  At the end other partners will probably be happy with new extensions, they had seen as not on the top of their local priorities.
    • Component require well formalized interfaces, maybe as "web services", based on XML standards.
       
  • Standards:
    • The purpose is to find solutions focusing on the difficult issues of interoperability, and taking account with existing situations.
    • Solutions must be based on open standards, rather than proprietary ones.  This should be done in contact with informatics coordinating bodies (as the W3C, http://www.w3.org/ , http://www.cen.eu/ ), as well healthcare standardization bodies, (as http://www.centc251.org/ , ... ).
    • Standards will be used as far as useful solutions for interoperability, not just because they have been published.  
       
  • The 3 types of partners:
    • The organization of the OSS Marketplace project is based on 3 types of partners, (A) users, (B) Open Source developers and (C) coordinators, as explained in the next sections.
      
      
      
• ( A )   Users having dreams :
  • Specifications: 
    • User seeking solutions should look first at existing repositories of open source software components, as in http://sourceforge.net/ and other resources depositories, containing thousands of softwares.
       
    • If the users do not yet find what they want, they should provide specifications on "http://www.whishesforge.eu" or ".org" (to be implemented soon, otherwise Email to etienne@saliez.be with subject starting with "OSS-Market: ").
      The users should write explicitly their dreams.
      Good formulated specifications are one of the necessary conditions to have a chance to get the desired solutions.  
      If no specifications, certainly no chance to get solutions!  Anyhow writing specifications is always a good exercise.
       
  • Timing:
    • In Open Source informatics when talking with enthusiastic developers nearly everything is in principle possible, but the critical question is always " when ".  Users who need a development can agree to propose a donation of money, but only on condition that a deadline will be respected.
       
  • Groups of users:
    • Moreover users should try to find agreements with other groups of users having the similar needs.  The advantage is that many relatively small pledges can be added in order to make a realistic budget.
      This is particularly obvious in the healthcare domain, because most requirements are similar in every region of the world.
    • These requirements should be formulated in a generic way.  A few regional difference should be identified, due to cultural and economic contexts.
      
  • Resources:
    • Users can also ask support from diverse sponsors.  Contributions may be in money and/or in kind.
    • Welfare organizations:
      • The effectiveness of their donations will be multiplied by the fact that Open Source is important for a larger diffusion.
    • Public authorities:
      • When public money is used, all the results of the development work should normally become available in the public domain.   Otherwise the citizen would pay twice, the tax and again the licenses of softwares developed by means tax money.
      • In Europe governments are aware of the need for improvements of the healthcare system and large budgets are available every year.  Actually more than enough resources are available for common Open Source developments, if the public calls for tender would include the condition that the results need to be public.
    • Universities:
      • Universities could allow their informatics staff to participate in development of OSS projects, at the same time confronting their staff ans students with real world challenges.
    • Commercial sponsors:
      • A fraction of the budget spent for advertising could be used as donations in order to improve the companies image, like banks sponsoring artists or sport events.  This is welcome, but only in absence of any further commercial dependencies.
         
  • Recognition and transparency:
    • Donors and Sponsors will not keep any property rights, but they are entitled to recognition, i.e. mention of acknowledgments in the modules they did sponsor.
    • Open Source project must be able to explain where their resources are coming from, as well their independence from commercial pressures.
      
      
      
• ( B )   Developers, informatics professionals:
  • Introduction:
    • We have here first to thank many individual volunteers who did achieve a lot of free software up to now.  These volunteers are willing to continue, but it is absolutely not normal that Open Source developers would receive no income at all.
    • The Open Source Market Place project focus here exclusively on software development activities.  
      As defined earlier here above, all other activities related to exploitation and recurrent support services are here out of scope and remain traditional businesses.
       
  • Dialog between developers and users:
    • Developers will look at the wishes of the users.  Discussion will take place in order to make sure that the goals of the requirements are well understood. 
    • Developers will propose technical solutions.  
       
  • Collaborations between developers:
    • Whenever possible and meaningful new implementations will be based on extensions of already existing Open Source software, sharing software with other groups.  
    • New developments will take place only when some requirements can not yet be covered by public domain software in a sufficient way.
       
  • Open Source developers have rights to recognition:
    • Intellectual property, i.e. references to their level of know how.
    • Although not the primary motivation of Open Source developers, realistic incomes are of course very welcome.  This is necessary in order to make more time available, in the normal working hours.
    • Looking at required developments and delay constraints, developers may propose offers. 
      
      
      
• ( C )   Coordinating third party, broker :
  • Introduction:
    • There is a need for coordination between the user and the informatics professionals.
       
  • Coordination and consultancy about the specifications.  
    • Helping users to define their requirements in a way informaticians can understand it:
      • Management of the web site " www.wishesforge.eu ".
      • Relations with other Open Source web sites, as " www.sourceforge.org ".
    • Focus on reuse and interoperability:
      • Generic and reusable character of the specifications:
        • Proposal of an inventory of generic modules:
          • Identification of topics and generic definition:
            • (see specific documents, in preparation).
          • Proposals how interfaces could look like.
          • Contacts with several existing Open Source projects, with the question how interfaces could be implemented.
      • Clear identification of at one side what is considered the generic common reference and at the other side possible local specific options.
      • Interoperability with existing systems and standards.
    • Decision about priorities should be based:
      • Mainly on the number of users expecting the intended solutions on their own priority lists.
      • On the estimated amount of work.
      • Taking account of resources provided by sponsors and their motivation for specific developments.
    • Mediation of contracts to be negotiated between users and developers, about specifications, price and delay, trying to match pools of pledges and expectations of developers.
       
  • Third party financial role:
    • The developers like to know that the money exist and is reserved on a bank account or by a notary.
    • The users like to know that their donations will be transferred after successful achievement of the developments.
         
  • Legal issues:
    • Licenses :
      • All software components must have a clear license in name of sponsors and/or developers.  All the documents and source files must mention their license status.  
      • The most typical license is the "GPL" but many other related licenses ( http://www.opensource.org/licenses/ ) could be used too.  The essential question is ensuring that the results will be freely available in the public domain, particularly in the case of the healthcare domain.
      • Discussions remain open about how far Open Source projects would or would not be allowed to be integrated with commercial software ?  as well which kind of integration ?  The preference for the pure GPL with the "copyleft" option.
      • Licenses must be registered and could be important in case other people who try to patent copies of free softwares.  This is why they must be registered with a date having a legal status.
    • Responsibilities issues :
      • Open Source Software is proposed "as it is" and assumed to be well known by the user, because the users can check the content of the source codes, or ask a third party to make to control the reliability of that code.
      • In Europe  the philosophy of the legal systems have some specifics aspects:
        • The EUPL, European Union Public License,
        • In France the CeCiLL ( http://www.cecill.info/ ) .
      • Independent certifications of reliability need nevertheless to be organized.  
        By the way, certifications are normally necessary for both open and proprietary software.  
        The main question is here an assessment how far the developments have been made according the "rule of the art".  Reliability should include redundancy checks at run time.
      • Having taken all the reasonably possible measures to limit the risk of errors related to the use of informatics procedures, it would never be possible to exclude completely all potential risks.  Independent doctors and  medical organizations have normally a global insurance contract covering all their professional activities.  
        The question is to check that the use of informatics is well foreseen in the existing insurances contracts.
        In general as a mean, much more risks of errors are expected when using handwritten documents, than when using computers, but the nature of the potential risk is a little different.
    • Legal advices:
      • The project need legal advices.  The project start from the healthcare service consumer point of view, while big commercial actors looking at healthcare only as a potential field of profits.
         
  • Considered organization of the Open Source Market Place project:
    • Call to permanent non profit and independent bodies, who could support and manage the role of third party as defined here above ?
    • This organization need some resources in order to manage sustainable activities as a third party".  
      • Support could be asked from international organizations, foundations supporting projects in developing countries, medical organizations, (as WHO, WONCA, etc...), medical informatics (IMIA-OS-WG,  etc...), as well scientific informatics associations (IFIP, IEEE, etc...).
      • A small percentage of the donated budgets would need to be reserved in order to sustain the management of the "Open Source Market Place", as a kind of fee for expertise and overhead costs.
    • Promotion of distributed developments:
      • Development around a "Version Control System", as BAZAAR, http://bazaar-vcs.org/ , or SVN, http://en.wikipedia.org/wiki/Subversion_(software) , http://subversion.tigris.org/ , 
         
  • A few example of potential sponsors:
    • Introduction:
      • The idea of a third party as mediator between donors and not for profit volunteers is not new.  Some examples are presented below.
    • SHUTTLEWORTH FOUNDATION in South Africa : http://www.shuttleworthfoundation.org/ .  Donation for developments of common interest were called "bounties".
    • GOOGLE:
      • Google did already organize sponsored projects.
      • See the ANDROID project in OpenGL, and particularly look at the end of the video :  a public call for users to develop innovative applications and rewards seems foreseen with a budget of 10 millions US$.
    • See the US Senator SANDERS proposal for "Medical Innovation Prize Fund" rather than monopolies,
    • ( OPENBUILD in US : http://www.openbuild.net/  ),
      
    • FUNDABLE in US :  http://www.fundable.org , the latest 2 illustrate the idea of collaborative projects adding donations, although not directly in the software domain.
    • Maybe also on a small scale TAGTRADE in Germany : http://www.tagtrade.org/ ,
    • ........
       
  • Initial setup building trust:
    • Contracts implies to build trusted relations.  Let start experimental exercises with simple "Micropayments for Micro tasks",  maybe initially only some simple " plug ins", but larger projects should follow.
    • Contracts will focus on 2 aspects:
      • the pure development of new Open Source Software,
      • the sustainability of systems in production.