Open Source Software Market Place in Healthcare
Draft version 2.7, 2 April 2009, Etienne Saliez MD, email@example.com
- 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
are a little disappointed because they do not immediately find the
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
from one unique commercial providers.
- Large generic software tools like Linux, Apache,
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
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
- 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
- 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
- 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.
- 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
- 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
questions of relative
priorities, while at the end everybody need soon or later most
functionalities. At the end other partners will probably be happy
new extensions, they had seen as not on the top of their local
- Component require well formalized interfaces, maybe as "web
services", based on XML 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 :
- 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 firstname.lastname@example.org
with subject starting with "OSS-Market: ").
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.
- In Open Source informatics when talking with enthusiastic developers nearly everything is in principle
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
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
- 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 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,
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
- ( B ) Developers, informatics professionals:
- 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:
will look at the wishes of the users. Discussion will take
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
- Looking at required developments and delay constraints, developers may propose offers.
- ( C ) Coordinating third party, broker :
- 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:
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.
at one side what is considered the generic common reference and at the other
side possible local specific options.
- Interoperability with existing systems and
- Decision about priorities should be based:
- Mainly on
the number of users expecting the intended solutions on their own
- 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
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:
- 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
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
- 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 ?
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
(as WHO, WONCA, etc...), medical informatics (IMIA-OS-WG,
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:
- A few example of potential sponsors:
- The idea of a third party as mediator between donors and
not for profit volunteers is not new. Some examples are presented
- SHUTTLEWORTH FOUNDATION in South Africa : http://www.shuttleworthfoundation.org/ . Donation for developments of common interest were called "bounties".
- 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.
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.