Software Component : Introduction

Version 7.5, 15 Nov 2009, Etienne Saliez,

Objectives:
The central idea of the project is the improvement of collaborative work in 2 ways:

Care collaboration:
The project focus on a patient centric record, in which the diverse professional care providers in charge of the same patient can read and write, according to a set of authorization rules. The group of professional having the trust of the patient and working for him is called the "VIRTUAL CARE TEAM".
The patient record is intended to be used in various contexts where the patient may need care and where specific presentations and extension may be necessary.
The essential objectives focus on patient care, based on the concept of the "Iterative Medical Model".
Informatics collaboration:
Collaborations between informaticians in order to share knowhow and to reuse software modules in Open Source. Management of distributed developments.
Medical activities are similar everywhere in the world, taking account of a few exceptions which represent maybe less than 1/4 of the total development efforts.
Open source make here much sense as far as software can be reused in different implementation sites and settings.

Patient centric:
Users working in very different environments need to share information about their common patients.

The traditional way was to exchanges paper copies of some reports and documents, by means of postal services, or nowadays by means of electronic messages. This traditional approach can still be used, but it is far from practical, due to delays and poor availability of complete information.
The trend is that the care of patient require usually several specialized professionals, who should share information.
This implies a new philosophy and methodology of medical work.
Current technologies provide now the possibility to share information in real time, directly on common servers, using broadly available technologies, i.e. web technologies.
Maintenance of evolutive documents providing an overview of the current situation, rather than formal reports freezed at a given points in the past.
At any time a comprehensive overview of the situation of the patient should be available. Old versions remain available, but only on demand.
The challenge is the standardization of interfaces, i.e. services. Open source is a great factor of interoperability, much greater than just some standardization of message exchanges, between very closed softwares.

In general as far as possible the strategy is to define commons properties only once in a parent class.
Derived classes will provide specializations as explained below in this document.

( A ) Fist look at the most generic common requirements which are anyway necessary for all care providers.
( B ) Having a common trunk of applications, look at the additional aspects required by specialized professional profiles, GP, diverse specialists, nurses, pharmacist, etc....
( C ) Adaptations in function of cultural differences and national legal requirements.
( D ) Arbitrary local requirements without justification and probably not useful to anyone else. However this level has to be developed and maintained using own local resources.

An usual approach would be to start with big surveys by potential users, in a neutral way as if nothing would be known. This would take a lot of time and provide a vision of the past. Many users are expected to ask to do the same as in the paper era, but on screen.
A more effective approach is to take the risk to try to anticipate and to propose a vision of the situations expected within 3 to 5 years. Experimental prototypes will then be discussed with the users. At the end proposed hypothesis will be submitted to the validation of the users.

Let begin in a simple way with a model of the most fundamental aspects. Define first the outline of the most essential components.
New versions of these components will be improved later on step by step. Every module will go go through several versions, each time more elaborated.

To be realistic, the different partners in different organizations, have their own software and will continue to use them, for many local reasons. The strategy is to propose additional modules as new options facilitating the work. In such context it very important to make interfaces with existing software, as far as possible.
Modularity facilitate distributed developments, by informaticians living in different countries.
Modularity is important for incremental development, improving one component at a time.
Modularity allows implementation sites to chose what they like to reuse, or what they want to make themselves in an other way, in case where no agreement could be found by means of "options" or even replacement of a module.