The previous chapter did introduce ideas about what should be
provided in order to support healthcare. This chapter focus on how to
achieve solutions in production at large scale.
There are 2 challenges:
How to provide the necessary support on Open Source usage.
Medical organizations require a global service.
How to maintain and improve shared Open Source softwares.
All over the world healthcare organizations provide similar services
to their surrounding population. The resource level and the cultural
environment may be different but basically they do the same job.
Use medical informatics wherever it is more efficient than manual
procedures. There are actually no alternative when the resources are
limited. The first priority is to cope with the most important common
medical needs, knowing that all desirable care services can never be
met, even in developed countries.
Current problems
Many Open Source software are already available in the public domain.
The lack of appropriate support services limit their use.
Many health institutions develop their own software, making again and
again similar software. They do not talk to each other.
Large software packages are difficult to move at once to new
environments in other countries. Indeed there are always some minor
differences somewhere which prevent the reuse of the whole package in a
new environment.
Healthcare organization are reluctant to adopt Open Source solution,
because the approaches are not yet very well known, lack of marketing,
uncertainties about continuity and liablities. BTW in fact these issues
exist for both free and commercial softwares.
Current procurement rules focus on buying things, rather than on
service contracts and expected mean costs over 5 years.
Support Services
Professional support service are essential for operational objectives
with high availability.
Scope:
Support services must be available at regional level in every
country, by people knowing the local culture and able to go easily
on site if necessary.
Main tasks:
Helpdesk:
Like medical activities, 24 hours a day, 7 days a week.
In most cases by mean of phone and telecommunication, but
with the possibility to send people on site.
Consulting:
Help to evaluate local organization and IT requirement.
Procurement:
Focus on service contracts.
Installation:
Install and the system functional.
Quality control:
Check of the quality and the security.
Training:
Help beginners to start to use the system.
Software maintenance:
First line maintenance, for example adaptation of
configuration options.
Call to second level maintenance may sometimes be necessary.
See the next chapter.
However here no fundamental developments.
etc...
Recommendations:
In healthcare a high level of availability is critical.
New procurement rules, no licenses costs, but support services
contracts. Anyhow in a perspective of 5 to 10 years and of common
interests of large international communities.
Avoid any single point of failure. On-line synchronization
procedures. Basic services must remain available locally in case
the telecommunication failure.
Avoid dependency on any single provider.
Avoid unnecessary centralization. Keep patient record close to
the place he is living and most likely to come back. Keep patient
records at regional level under control of the responsible regional
Medical Councils. That said it must always be possible to authorize
occasional access from remote locations. In general this apply for
a relatively limited number of cases and it easier to control.
Economic model:
Support services imply recurrent costs per site and per year.
Support is traditional business, competing on quality of services
and prices.
As a protection against potential disruption of activities, most
medical organizations prefer to subcontract to professional
informatics support, when they do not have much informatics
know-how in house.
Remarks: Support services require qualified and motivated people,
but there are no risks about large development investments.
Software maintenance
Scope:
Shared software tools at international level. No direct
involvement in local installations.
Approaches:
Modularity is essential. The goal is to share at lest some
components. People must remain free to decide what free software
they want to reuse, knowing that their local own resource are
always limited.
A few competing alternatives for every component can make sense
and will continue to exist. However of course only a limited number
of alternatives, when really meaningful.
It should be possible to upgrade or renew every module one at a
time. Implementer should have choices between competing
alternatives. Keep in mind that the framework is on itself a
component and that more than choice could be meaningful.
Priority for the most
common components nearly everybody needs to start. Whenever
possible, also "additional components". 3 priority levels:
"Now": Keep the informatics services running with
indispensable functions.
"Tomorrow": What need to be done next as soon as
possible..
"Later": All other things to be done, well registered in a
central wishes list and with relative priority sores.
"Wishesforge" roadmap
Be aware that the life cycle of software code is no more than 5
to 15 years.
Open Source telemedicine project should be available on any
computer. Mostly a question of checking browsers
compatibillities.
Review of currently available Open Source software:
Evaluation of what can be used in function of the requirements of
the community of users.
Some examples:
Generic Open Source tools as Libre Office, Apache, Postgres,
etc...
See also the approach of the NHS HACKDAYS inviting people
to identify issues and and to make innovative prototypes.
and many more, etc .........
Identification of what is missing and to be developed:
Integration issues:
Although many Open Source software are already available,
good integration may require attention and development
efforts.
Legal constraints and obligations for national reporting may
change over time and need to be addressed.
In general the trend is that requirements are increasing year by
year, the users becoming more aware of all the possibilities of
informatics. New version of some components may become
necessary.
Adaptation in function of new technologies making the system
easier to maintain.
Main tasks:
Promotion of a meeting point for a community exchanging know-how
in Open Source.
The main issue is modularity and integration.
What most matter is a normalization of definition of functional
components and of their interfaces. When people begin to use common
components, their standards will naturally converge.
Quality Control by peers.
Agreements on the formulation of generic specifications, taking
account of the most common requirements of a majority of users.
Having that technical solutions will no more be major problems.
Documentation quality is critical in order to allow exchanges
between developers, as well to avoid dependencies from any
particular developer.
Task to be achieved by an international community of developers
who can be based anywhere in the world.
Economic model :
Software components require to be funded only once for a
potentially very large community of users and a period of several
years.
Public authorities responsible of the availability of healthcare
according to social and safety rules. When they use taxpayer
money to improve software adoption, the results should always
become available in the public domain. Simply a condition in
subvention contracts. Of course developers or companies making
these software need to be paid normally. It may be a little more
expensive at start but indirectly on long term a large return in
social security expenses. In fact sufficient budgets are available
for Open Source developments, but it is a question of allocation.
International exchanges of software copies do not cost anything and
can benefit from important contributions from partners.
At one side anybody can take advantage of all open source
software already available in the public domain. At the other
side when a medical organization needs urgently something more,
they can provide resources, limited to the cost of this extension.
In kind or as a budget, although no remaining owner of
licenses.
Donations from welfare foundations. The "return" is here to help
as many people as possible by means of their contribution.
As usual communities of Open Source volunteers will continue to
play an important role in innovations, being motivated by the
intellectual and societal challenges. However with a lot of good
will they cannot not be very reliable about deadlines in a
planning.
