Collaborative Care Team in Open Source,
Issues and Approaches

• Summary:
• In the scope of the ISfTeH, what are the specific issues of telemedicine, out of the large domain of medical informatics? 
  
• A review of issues and considered approaches, with the following questions:
  
• How far are the issues well identified ? Which issues are still missing ? 
  
• Assuming agreements on an issues, which approaches should be considered ?
  
• Identified Issues:
• Main_issues
• Care Team Concept
• Problem Solving 
• Information Flexibility and Navigation
  
• Education 
• Integration Platform
  
• Communication strategy 
• Confidentiality
  
• Trust and responsibilities
  
• Technical collaborations, FLOSS
  
• Software architecture
  
• Network installations 
• Network security 
• Information Interoperability
• Data collection for statistics
• Economics of medical activities
• Developments management
• Exploitation management
    
  
• Main issues:
• Issues:
• The trend is that many specialised actors become necessary for the care of the same patient and the needed expertise is not available everywhere.  Since 50 years many excellent specialities have been developed, but the coordination has been relatively neglected.
• Telecommunications could help more, but are still underused.
• Too many custom softwares.  Up to now most softwares did focus on only one target group of users at a time, one professional specialisation, or one disease, or one context.
• Good healthcare is not yet enough available nor affordable in developing regions. A critical concern in the scope of the ISFTeH, the members coming from about 50 countries, including many developing regions.
• A more detailed analysis of the issues is presented in the next chapters of this overview of issues.
  
• Approaches:
  
• Objectives:
• Improved care by means of better support of collaborations between the professional actors in charge of the care of a patient, by means of telemedicine and sharing know-how in the scope of the ISfTeH, International Society of Telemedcine, http://www.isft.net/ and http://www.isft.net/cms/index.php?collaborative-care-team-in-open-source .
  The essential concept of telemedicine is seen 2 or more healthcare partners having to collaborate, even when there are not at the same location.
  The project focus on a "patient-centric multidisciplinary record".  A record belonging to the patient in which the involved care providers can share information.
• Sustainability by means of education, seen here as contextual training.
  
• A kind of health coordination platform, beginning by the most common features for the care process, as it may be necessary for any kind of diseases, for any kind of healthcare professionals, in any kind of context.  This common platform is intended to integrate additional specialised software modules.
• To share know-how, including full documentation in Open Source.
  
• Experimental prototypes in order to:
• Stimulate constructive discussions with the intended users, in front of visual examples.
• Check the feasibility of the considered up to date technologies.
   
  
• Care Team Concept:
• Issues:
• The traditional organisation was based on many independent and individualistic practices and independent hospital departments.  These organisations did more and more specialise, looking each at only one or a few aspects of the patient problems.
  
• Since the development of very much larger medical knowledge bases, no one is any more able to cover in depth all the aspect of medicine.
• A patient could always have more than one problem at a time.
  
• Up to now many commercial softwares have been designed to make life easier to a specific target group of customers, either GP, or nurses, or cardiologists, or hospital administrators, or.... or .... with limited motivations about interoperability.
• Initially when internet was not yet available, most medical record softwares have been designed as "personal computers".  The consequence is that these different groups of professional users have still today completely independent software designs, with poor compatibility.
• Approaches:
  
• In the scope of the ISfTeH, a new reflexion about how to improve healthcare, taking advantage of telecommunications tools.
  
• The start point is the generic concept of "Multidisciplinary Collaborative Care team", i.e. all the care providers involved in the care of a common patient. An overview of the patient situation should always be shared by all members of the care team.  Next depending on their professional profiles care team members may have different roles, going deeper in their specific domains.
  
• Care Team members are expected to share information in a way intended to be easily understood by care team colleagues.  This is why a problem list must be maintained.  Indeed any new member of the Care Team, for example in an emergency unit, should always find an up to date overview of the problems as the first page.
  
• Care Team coordination:
• Normally the long term coordination is expected to be achieved at the Primary Care level, by the GP.  He is motivated for follow-up and he should normally receive reports from the diverse specialists.
  
• When necessary the GP may delegate a problem to a specialist, as well temporarily the coordination during admissions in hospitals.
• The concept of care team can be implemented in many ways, as long as several partners have to collaborate for the same patient. A few examples in case of:
  
• Oncology:  GP discovering the problem, organ specialist analyzing the exact situation, surgery, radiotherapy, chemotherapy, home care, ....
• Diabetes:  GP, diabetologist, vascular diseases, ophtalmologist, ...
  
• Developing region: nurse in the village, regional hospital, center of excellence, international experts.
• Elderly care: follow-up by the GP, multiple disabilities which may need specialists, care at home.
  
• Pathology lab:  local surgery taking a sample, lab technician preparing images and providing a provisional conclusion, remote expert providing a second opinion.
  
• ....
   
  
• Problem solving:
• Issues:
• Up to now many medical archives, as well on paper as well on electronic media, contain essentially descriptive and narrative data.  Events, like consultations and admissions, are described as separate reports.  Many medical records systems contain a lot of raw data, but often lack any synthesis of the problems.
  
• Many regions have a great shortage of experienced healthcare staff, particularly in developing regions.  Remote small health centers must relay on persons having relatively short nursing education.
  
• Some advanced decision support system already exist, but are not yet largely available. Standardization of the observations remains a major issue.
  
• Approaches:
• Since the essential healthcare goal is to contribute to solve problems, we should go beyond simple narrative documentation.  Today informatics technology makes a more rigorous information management possible.
  
• Medical "work methodology":
• Collaborations in a Care Team require agreements about how to manage and to share patient information. 
  
• Clear guidelines are particularly important for beginners.
• Orderly managed patient information is a prerequisite before access to medical knowledge bases would become useful.
• Orderly managed information is always a factor of care quality.  It prevent that some issues would be forgotten and neglected.
  
• Also a prerequisite before advanced decision support could be implemented in the future.
  
• The recommended approach is to make at least clear distinctions between Observations, Problems and Activities and to pay attention to the links between these 3 types of informations.
  
• Observations:
• Record the facts, as what the patient did say, what you did see, what has been measured, etc...  Take notes about what is obvious and should initially be token without any assumptions.  Beginners can learn relatively quickly how to take notes about observations.
  
• Health Issues assessments:
• Given the available observations, assessments will be made about one or more health issues.  Heath Issues may be preliminary concerns about a set of abnormal finding.  May later become a diagnose.  Health Issue include also risk factors.
• All care provider whatever they roles, should have a minimum of overview of the problem list.  Of course depending on their specialised roles, will go deeper in the details of their domain.
  
• Activities:
• Decision about activities are based on the current understanding of the Health Issues by the doctor, often not yet any obvious diagnose but just provisional hypothesis. 
  In the future some Activities will become automatically proposed on the basis of the current Health Issues so far identified.  For example which next questions to the patient, or which test seems to have the highest priority, on the basis of what is already known as possible Health Issues.
  
• Activities include a wide range of possible procedures, as well intended for more explorations, as well for treatments. 
  
• Since Activities necessitate resources, they have to be declared to the administration who need to make invoices.
• In principle all activities will result in some kind of conclusion, as e.g. a lab report or a note about the effect of a treatment.  These results will increment the above set of Observations and may introduce a next iteration of assessments and new activities.
• Schemas:
  
• Semantic web technologies will be here very useful in order to represent:
• Inside the patient record, the links between Observed facts, identified Health Issues and ordered Activities.
• Links fro the patient problems to external medical knowledge bases.
  
• A basic example: Obs-Problems-Actions.png,
   
  
• Information Flexibility and Navigation:
• Issues:
• Up to now many software applications are not going deeper than handling "documents" and forms, regardless of the meaning of their content.  For example discharge letters are archived as a 2 or 3 pages document in free text.  Structured information are limited to patient ID, date, author, ICD diagnose code.
• Like paper charts most electronic archives are organized as trees.  Typical main usual branches are consultation notes, discharge letters, general lab, bacteriology lab, pathology lab, XRays, ...  A given document, or leave in hte tree, has only one access path.
  
• Approaches:
• Items:
• No more large documents nor rigid  "forms", but much more granularity in smaller entities of information.  An Item is in general the minimal entity of information making sense, technically speaking an "object" with several "attributes".
  
• A much more granular approach become necessary. The basic unit of information can be defined as an item, .i.e. an object with a few attributes as
• Item Header:
• Item ID, and version, Date, Time, Subject of care, Responsible author, Link to the Context (e.g. during a given consultation at a given location and time).
  
• Item Type (Observation, Issue, Activity) and subtypes.
• Optional Clinical Modifiers, as degree of belief, intensity, optional comments.
• Item content:
• Depending on the type.
• Moreover a collection of Items may be represented by means of an Item.
  
• Different types of content may have different methods of display.
  
• Navigation:
• No more a tree structure, but possible access by multiple "paths".
• The use of "Semantic Web" technologies is considered, in order to manage navigation between
• The Items of medical information inside the patient record.
• Links to medical knowledge bases.
• Graphical representation of the links between knowledge nodes.
• Clicking on a node in order to provide the details of the underlying information.
• The links themselves should be qualified too, with author, date, degree of belief, etc... i.e. the links themselves could be seen as Items.
• "Views":
• Polymorphic collections, list of medical Items relevant for a given objective, but regardless of their technical formats.
  
• Frequent search strategies should be facilitated by means of sets of rules recorded as preferences, in general as well as individual preferences.
   
  
• Education:
• Issues:
• Helping a few individual patients is of course an urgent need, but the main challenge of emerging countries is to provide sustainability.
• Approaches:
• Beginners need above all to learn how to manage medical information.  This is why the above method of explicit recording of "Observations-Problems-Activities" is particularly recommended for beginners.
  
• Access to textbooks of theoretical knowledge must be available, however it is not enough because the lecture of textbooks is arduous.
• Education is to learn how to solve problems.  As far as possible a transparency of the decision steps is very important, as explained above.  Semantic schemas will be probably more easy to understand than long explanations in text.
  
• Scenario of "Contextual training":
• Ask local staff to record what they have observed,
• Ask them to document their current understanding of the patient problems,
• On their request provide a second opinion:
• If in agreement, a motivating acknowledgement for the local staff.
• If suggestions to proceed in a different way, a factor of training, when providing some background information related to the current Health Issues.   Maybe just one page of explantions.  Next time a similar situation will arise, the local staff is expected to know better how to proceed.
• User guide of the system itself:
• Also by means of contextual explanations, when clicking on help buttons included in most pages.  The user guides may depend on the user preferences in function of the level of training.
   
  
• Applications Integration Platform:
• Issues:
• In the past many custom softwares have been developed independently, due to the following factors:
• The members of care teams have different roles, different professional interests and different preferences.
• Internet was not yet easily available.
• Healthcare professionals were not too much motivated for collaborative work.
• Software commercial companies were not at all interested in interoperability, unless forced to do something.
  
• Many specialized medical application softwares are already available as FLOSS, as can be seen on http://www.medfloss.org/ , but there is not much coordination between these initiatives.
• Approaches:
• An integration platform is seen as a critical need.
• Modularity:
• Modularity is critical in order to allow distributed developments.  A key issue in order to take advantage of distributed development in an international community in open source.  Partners should take care of development and maintenance of components.
  
• There are 2 main types of software components:
• ( A )  Availability of the common functionalities, as expected necessary in most care contexts:
• Most critical as the "Core" of the network and implying agreements.
  
• Main components:
• User authentication and authorizations
• Patient identification
• Role Based Access control
• A generic structure of Observations - Health Issues - Activities,
• "View" steering objects,
• Normalized interface to knowledge sources
  
• ... more information at http://www.chos-wg.eu/Software/Comp-Common-Platform.html .
• ( B )  Interfaces to many specialized services:
• Interface definitions is here particularly important.
  
• Beside the interface itself, there should be as few dependencies as possible, between the platform and the external modules. 
  
• Since these components could be available in different programming languages, the interfaces should be neutral as far as possible, sharing information in XML.
  
• The integration platform will:
• Call external "services"
• Could also be called by external process, particularly be notified of the occurrence of external events.
• User preferences:
• User preferences are important in order to take account of the different role of user roles in the care team.  Keep in mind that an important goal of the project is to avoid multiplications of custom softwares.
  
• Users may need specific screen presentations and behaviours, depending on professional profile, specializations, cultural context, spoken language, computer experience level (beginners learning basic skills or seasoned users wanting to work as fast as possible), etc...  as well in function of individual preferences. 
  
• User preference should be associated with user accounts, allowing users to move to several workstations. 
  
• To keep it easy many preferences should be proposed automatically when a user account is created with the main information classes as professional status, specialization, role in organization, membership in a care units, etc... 
  
• There are 2 types of user attributes:
• Mandatory attributes, to be managed by the network administrator in function of legal and organisational requirements.  In read-only mode for the user.
  
• Optional preferences to be managed by the user.
  
  
• Communication strategy:
• Issues:
• Electronic messages did replace traditional postal services.  The improvement is that it works faster, but it remains depending on the good will of a sender.  Moreover the sender cannot exactly know who would need which information in the future. 
• A message is a kind of picture at a given point in time and become quickly obsolete.  What if the patient would need care by a new Care Team member, as an emergency department ?  and what if the treatment has just been modified one day ago?
• Approaches:
• On-line access to shared information is considered to provide the best support for collaborations between the Care Team members. 
  
• Any new information should be recorded directly in the patient record.  In that way any authorized member of the Care Team can get it immediately.  Even a new member who has just been added in the Care Team.
• That said the possibility to receive and to send messages must remain available.  However the trend will be to reduce message to "notifications".  A notification is a kind of short message warning the addressee to pay attention at some new information relevant for him and already located in a given patient record in the database.  Such notifications will contain just a pointer and no more any medical content.
  For example when the result of a bacteriology test become available after about a day, the lab will at the same time make the result available in the patient record and send a notification to the author of the request.
   
  
• Confidentiality:
• Issues:
• Confidentiality is critical for the patient.  Although in principle all care providers have always an obligation of confidentiality, the question is to avoid unnecessary risks.
• Confidentiality between doctors may sometimes be an issue too.
  
• Approaches:
• Role Based Access Control principle, i.e. access to the patient record must be limited to the actors who are currently really necessary for his care and who have the agreement of the patient. 
  
• Explicit care Team management, i.e. a short list of who exactly in charge of the patient.  At one side new Care Team members can be invited by persons who are already Care Team members, as well by the patient himself.  At the other side the patient could occasionally let remove a member.  Anyhow Care Team memberships are of limited duration, only during a meaningful delay after the latest contact.
• The new vision implies much more transparency between the healthcare professionals.  For the benefit of the patient, care providers, when in charge of the same patient, should share all relevant information.  However when there is no common patient, information do not need to be shared except for scientific purposes and then in an anonymous way. This is good for both the patient privacy, as well for potential competition issues between care providers.
   
  
• Trust and responsibilities:
• Issues:
• Information of unknown origin could not be trusted.
  
• Different actors could have sometimes different valuable opinions about the same set of observations.
• Legal requirement of traceability.
  
• Approaches:
• In order to add new information, the user must be be qualified and accredited as a member of the care team of the patient.  For example a prescription depend on 2 conditions: be given by a doctor who is currently member of the Care Team.  For example the pharmacist chosen by the patient is considered as a temporary member of the Care Team.
• Any member of the Care Team may introduce comments, but the responsible author must always remain visible.
  
• The computer network is neutral and different medical opinions are allowed to be recorded alongside, always mentioning the responsible author.
  
• Someone else than the original author should be able to express his opinion, approving or disagreeing.  The system must be able to record this kind of "co-signature" of the original document.  The point is here to prevent Care Team colleagues to create unnecessary new copies of the same documents.
• Versioning:
• Update of Items are normally never allowed, but only new versions.  This should be true for all Items, even including the patient identification.
• For medical reason it may be important to be able to go back to a previous step.
• Also a mandatory legal requirement.  A decision is acceptable according the "rules of the arts" in function of all what was known at the time of that decision.
   
  
• Technical collaborations, FLOSS:
• Issues:
• Many specialized medical services are available as FLOSS, but integration is still far from obvious.
• Keep in mind that informatics is an evolutive process with request for new versions and new applications, as well with the discovery of new tools.
  
• Approaches:
• Remark: the full name is normally "Free Libre and Open Source Software", but is often abbreviated as "FLOSS" or "Open Source".
• Promotion of technical collaborations based on FLOSS principles, sharing software know-how according to the principle of the GPL, http://www.gnu.org/licenses/gpl.html . or related licences as the EUPL, http://www.osor.eu/eupl , taking account of the European context and legally available in 22 languages.
  
• An international community of informaticians supported by not for profit organizations.
• In order to make developments possible across such distributed centers, modularity is a critical issue.
• Incremental developments makes possible to start early with a minimum, to learn from field experience and to improve one component at at time.  A complete planning in advance would take too much time and would become soon obsolete. Trying to anticipate a little, an initial vision is proposed, but many details will have to be worked out, and the main vision itself will have probably to be adapted in the future.
• Maintenance:
• As for any softwares, open source softwares need long term maintenance, which need to be managed.  While in general never licences costs, support services may need to be charged.
   
  
• Software architecture:
• Issues:
• The main objective of the project is patient care.  A patient may need care from a very large panel of specialized services, requiring an integration platform.
• To make distributed developments possible.
  
• The logic of the intended medical applications require a relatively large set of temporary persistent information. More information than just a few data about the next HTML page to be displayed, as usual in many web frameworks.
• The general philosophy should be real time and measures should be foreseen in order to prevent conflicts in case that 2 users would be working on the same record.
  
• Approaches:
• A very modular approach:
• A "Core" intended as a generic integration platform.
• As far as possible reuse of software components available in Open Source and adapted as "services".  Interfaces allowing that these external component may be in different programming languages.
• The Core itself is also a component to be upgraded step by step, although particularly critical.  The Core of the experimental prototype is in Python.  A choice in function of a good level of abstraction, a great flexibility, availability of large libraries and a growing and a mostly open source minded community.
  
• Incremental development beginning by relatively simple components, to be upgraded one at a time.
  
• A compromise between a traditional application logic and a stateless web framework.  This can be seen as 2 levels:
• Core Patient Record Coordination Logic.  A multi-user setup, but during a user session, maintenance of a Session object containing temporary session data related to the current user.  Every user should have such a session object.  Session objects should be maintained on a fast type of memory.
• Front-end web interface dealing with all the external communications, in principle called "views".  The most frequent views are intended for a web browser, but other types of "views" should also foreseen in the front-end, as smart phones, HL7 messages exchanges, etc...
• .... more information at http://www.chos-wg.eu/Tech/VCT-Network-Architecture.html .
   
  
• Network installations:
• Problem:
• In telemedicine it would be very difficult to go to visit all users on site for installation and maintenance purposes. This is particularly critical in the case of developing regions.  
• Phones are already largely available in developing regions, where budgets for more complete workstations are very limited.
• In developing regions power supply and internet are not always continuously available 24 hours a day.
• Large centralized servers rise potential problems from ethical and political points of views.
  
• Approaches:
• "Thin client":
• The user workstation should be as simple as possible.
• The essential requirement is to be limited to a standard browser as available on most usual OS platforms.  A browser based on full open W3C standards should be required, if possible.
  
• Although a standard web browser is currently seen as the main technology, we will also have to take account of other devices, as phone devices.
• In general no options should depend on the client machine, but well on hte user account at the server side.
  
• Servers:
• Servers are intended to do all the work.
• Network configuration:
• Decentralization:
• Avoid unnecessary centralization of data bases.  Preference for relatively small regional servers, while a possibility of long distances inter-connexions must be available.  This can be better controlled since it applies to only a small percentage of the patients. Server should be decentralized at regional level in the region were the patients are living.  The degree of decentralization may depend on several factors as where are cluster of frequent transactions expected, where is basic technical maintenance and protection possible.
• Servers need to be interconnected, in order to get access to remote medical expertise and in case a patient would need care at an other location than his usual region where he is normally living. 
  
• Confidentiality control is easier when the number of transaction is relatively limited.
  
• Autonomy:
• Workstations and servers should include a battery maintaining a stable power for at least some time.
  
• Server and client could be in the same machine, although this kind of extreme decentralization is only intended for back-up or emergency situations when no communications at all are available.
• Access to the international Internet is mandatory, even if it use need to be limited due to high costs and porr continuity:
• Necessary to get support from remote medical expertise, otherwise not available locally. 
  
• Mandatory for occasional software maintenance.
   
  
• Network security:
• Issues:
• Security:
• Security is a major concern for confidentiality, but above all for the reliability of the applications. Indeed orders for treatments need to be safely transmitted.
• Security require attention at both sides of the communication, server and client.  A problem is that it is relatively difficult to control the security at the client side. For example passwords should not be saved.
  
• Remark:  the possible goal is only a high degree of security, higher than what was possible with papers and manual signatures.
• Reliability:
• Integrity of the information.
  
• Data availability:
• Medical emergencies can arise at any time 24 hours a day, and access to the patient record could be important.
  
• Telecommunications could be interrupted at any time for some time up to several hour or a few days, particularly in developing regions.
• Any machine could fail at any time.
• Approaches:
• All communications must be encrypted.  Current technologies are based on HTTPS.
  
• In principle only a minimum of information should go through the communication channel.
  
• Identification of the user session, by means of a kind of cookies, moreover very temporary and if possible somehow encrypted.
  
• Of course the requested data to be displayed and new input as which button has been pressed and new input data.
• Communications must be encrypted.  Moreover the traffic on the line should be limited to what is really essential, i.e. identification of the client (maybe a kind cookie) and what is new.  For security reasons, systems based on steering information in long URLs should be avoided.
• Sensitive information should not unnecessary depend on slow and potentially unreliable telecommunications between server and workstation.  Session information should be maintained at the server side.
• Checksums or signatures should be included in critical information.
• Automated backup must be foreseen, not depending on the attention of local users:
• Backup on several devices.
• Incremental backups.
• In situations where communication are very difficult, it could even be considered to keep backup at the workstation level, regarding the most critical information for the surrounding patients.
   
  
• Information Interoperability:
• Issues:
• Official "standards" did contribute to alleviate the interoperability problems.  However only to a limited extend since proprietary softwares companies  are always trying to avoid to expose how they work internally.
• Historically standard have been designed mainly for epidemiological purposes.  Clinical modifiers, which are mandatory in care practice, are not yet well standardized.
• Standards defined many years ago in very different contexts are not necessarily a panacea for our current purposes.
• Approaches:
• Of course when useful, use official standards, but we may need more.
  
• Open Source is expected to become a major factor of interoperability.
• References to dictionaries should be systematically prefixed, with worldwide unique prefix.
• While classifications of academic diagnoses are very well standardised, as for example the ICD from the WHO, more should be developed in the domain of "Heath Issues" concepts and links to related knowledge.
   
  
• Data collection for statistics:
• Issues:
• Misunderstandings are frequent.  There are 2 very valuable groups of objectives, but be aware that they may require different strategies:
• ( A ) Surveys for scientific and management goals: 
  
• Historically the first application did focus more or less exclusively on this type of objectives.
• ( B ) Patient care:
• Individual patient care application were developed at a later stage.
  
• Approaches:
• ( A ) Surveys:
• Information must here be made anonymous as far as possible.
• Detailed information from groups of more or less similar cases need to be reduced and summarised in classes, by means of standard codes as the "IDC" from the WHO.  What matter here here is conclusions about large populations, within acceptable error margins.
  
• The current classifications focus on final academic diagnoses, but more attention should be devoted to "Health Issues".  From a management point of view "Health Issues" may require resources, even when a suspected diagnose has been eventually excluded.
  
• Many healthcare professionals are not motivated for surveys and would need incentives before participating seriously in surveys.
• The registration of classifications and codes should be made very easy.  As far as possible the information should be automatically derived from the clinical practice. In many obvious cases the user would only have to give one validation click on the proposed classification.
• Anonymous information could also be used for quality control purposes.
• ( B ) Patient care:
• Reliable patient identifications are here critical.
• Detailed information is here absolutely necessary in order to arrive at meaningful decisions.  "Clinical Modifiers" are essential, as degree of belief, acquisition reliability, intensity, frequency, duration, laterality, etc...  In clinical practice these important aspects are usually communicated in free text, or even by means of movements and voice tones. 
  
• In telemedicine the challenge is now to make all these important information available to partners in the Care Team, who may be at remote locations.  The challenge is to achieve more reliable clinical information sharing, while keeping the system easy to use.  The most important clinical modifiers should begin to be normalized, while free text comment should remain possible everywhere.
   
  
• Economics of medical activities:
• Issues:
• In general the tradition is that doctors are paid when they encounter patients, face to face. Historically Social Security systems have been build on that principle.
  
• Developing regions have a major "brain drain" problem.  Even in regions where national doctors could be available, there are 2 problems:
• Attraction to migrate to countries where incomes are higher.
• Isolation from continued learning opportunities.
  
• Approaches:
• Seek agreements about fees, based on services and responsibilities through internet, making the face to face contact no more mandatory.
• Telecommunications and access to knowledge can alleviate the isolation in remote areas.
  
• To a limited extend experts are available and agreeing to give advices as volunteers, but:
• Take care that the questions should be well prepared and documented.
• Volunteers should have no out of pocket expenses about equipment and internet access.
  
• Beside pure medical applications, provide software tools helping to manage the related administrative issues including invoices.
   
  
• Developments management:
• Issues:
• Too many local software projects are reinventing more or less the same things.
  
• Approaches:
• An international collaborating community.
• Official status:
• Currently a Working Group of the ISfTeH:
• http://www.isft.net/cms/index.php?collaborative-care-team-in-open-source .
• The ISfTeH is a neutral not for profit organization, international with member in more than 50 countries and promoting Telemedicine/eHealth, http://www.isft.net/cms/index.php?_jgv.
  
• The ISfTeH itself cannot provide funding, but could help to get resources and control the activities on a dedicated account.
  
• In the future an independent legal status could become necessary:
• A kind on international not for profit association:
• Could be a Belgium based AISBL-IVZW, "Association Internationale Sans But Lucratif" or "Internationale Vereniging Zonder Winstoogmerk", http://www.ejustice.just.fgov.be/cgi_vzw/vzw.pl :
  
• Like an ordinary ASBL-VZW, Belgian not for profit Association, but adapted for an international context:
  
• Members do not need to be Belgian nationals.
• Basic obligations include a postal address in Belgium, publication of the statutes, a yearly report showing that the association remain really non profit.
• More in the book http://www.uga.be/uitgeverij/detail_fr.phtml?id=678 .
• ...
  
• Still remaining an affiliated member of the ISfTeH.
  
• Version control systems:
• A decentralized version control system, like Mercurial, http://mercurial.selenic.com/, or Bazaar, http://bazaar.canonical.com/en/ .
• Every partner get locally a full documentation of the projects.
• Temporary local branches are allowed and may include any local initiatives.  However of course integration in one or a few main version branches are strongly recommended, in the interest of everybody.
• Discussion tools:
• Voice, text, images,
  
• Preference for using Open Source tools as: .....
  
• Documentation:
• A web site and a forum keeping the reports from the discussions.
  
• ....
   
  
• Exploitation management:
• Issues:
• Making software available is not enough.
  
• Users need support services for installation, initial training, help desk in case of problem.
• As any software, open source software need evolutive maintenance.
  
• Approaches:
• Management of maintenance for the projects in production:
• IPATH:
• ........
  
• .....................
• ......
  
• Support service of Open Source softwares are seen as a traditional business.
   
  
• More issues should be covered ........