Collaborative Care Team, Medical Model and Informatics Object Model
in low resources and Free Software Environments

IWEEE-2012 / Granada, 11 January,  etienne@saliez.be

• Introduction:
• As a reflexion about approaches for next software versions. here 2 "models" from different points of view:
• Medical Model:
  
• Object-Model: 
  
• More in the Working Group "Collaborative Care Team in Open Source" of the ISfTeH, "International Society for Telemedicine and eHealth,
  http://www.isfteh.org/working_groups/category/collaborative_care_team_in_open_source .
   
  
• Medical Model:
  
• Approaches:
• Patient centric, integration:
• A patient may need several healthcare professionals, regardless of their locations across Internet.
  
• Rather than softwares exclusively targeted at specific clients, as GP, specialist, nurse, pharmacist, ....
• That said different professional groups may need different presentations from the common data base.
• Coordination of the patient health:
• ( 1 ) Start by the Global Coordination at Primary Care Level.
• ( 2 ) Then when necessary, request advices and technical procedures from specialists.
• Support of problems solving, Medical methodology:
• Look at the care process, rather than narrative reports from successive patient contacts.  
• Permanent maintenance of a global picture, intended for colleagues.
  
• Iterative model between 3 steps:
• Observed facts
• Identification of "problems", i.e. assessments about these facts.  A problem being as well an abnormal finding needing more analysis, as well a diagnose needing treatment.
  
• Activities decided in function of the identified problems.  The results of these activities provide new observations to be worked out during the next iteration.
• Iterative Care process , Iterations and Patient record presentation.
  
• Clinical information:
• Support for the necessary attributes or "clinical modifiers", degree of certainty, intensity, lateralization, .... rather than the exclusively black or white simplifications intended for epidemiological surveys.
  
• Contextual Training:
• Rather than textbooks, provide background medical information related to the encountered cases.
• Development issues anywhere:
• Although low resource regions have particularly severe needs, do not forget that similar issues also exist in developed countries, where hospitals are full of excellent very hight-tech people but where there may be relative poor coordination.
    
  
• Technical Model:
• Approaches:
• Sharing know-how in Open Source:
• Most medical requirements are similar everywhere and many software components are already freely available in open source.
• NGO and Health Ministries are non profit organizations and are normally happy when their resources benefit to as many people as possible. (as far as they understand to Open Source issues).  Why not call fot tenders including an openess condition ?
  
• Modularity:
• Although hundreds medical Open Source modules are available in MEDFLOSS, http://www.medfloss.org/ , many are independent very specialized applications.
• Different implementation sites may want slightly different sets of modules, as well choices between different variant of the same application module.
• Modularity ans standardization of interfaces are key issues in order to progress.  Modular Architecture . The focus in my current experimental work.
  
• An object model:
• A root class containing the most common properties. Object-Model:   (pdf)
  
• Several levels of derived classes adding specific properties.
• Views:
• Well a common Database, but different professional groups have different interests and need adapted presentations.
• A "View" as a selection of a sub-set of Items, to be sorted, and displayed maybe in a specific way.
• In principle click on object you see in order to zoom in the details.
  
• Possibility to navigate to related information, as a kind of semantic web.
  
• Data organization:
• Allow navigation in kinds of "semantic web" networks. Preference for nodes which can be linked in many ways, rather than rigid hierarchic structures.
• Semantic links can be useful in 2 ways:
  
• For individual patient data in order to show in a natural way an overview of the relations between the observations, the problems and the ordered activities:  Patient record presentation
  
• In order to navigate in the relations between concepts of generic medical knowledge.
  
• Network :
• Avoid unnecessary centralization:  A network of relatively small servers.  Any medical center should have his own local server, going on even if long distance communication are temporarily unavailable.
• Availability, where possible avoid single point of potential failure.
  
• Server:
• Preference for permanent user sessions at the server side, containing the persistence and the logic of the applications. Among other application will include display functions. 
  Rather than completely "stateless" web servers, handling sequences of visual web pages, containing each a little logic.
• Event based:  when needing something from an other computer in network, issue a request and expect an event back from the partner.  However if for any reason, no event is coming back, the user should not be blocked.
• Experimental Prototypes:
• Version 2011: http://localhost:6540 . For example small isolated medical centers may have a microscope and internet access but no pathology expert.  The experimental generic patient-centric record can open a sub-window interacting directly on the server of the specialized IPATH project based in Switserland, in order to get a second opinion from international experts.
  
• A new version is in preparations and will become available on the web.  Partners are very welcome to contribute to this experimental work in a  working group of the ISfTeH, mainly in Python.