Virtual Care team Network Architecture

• Introduction

• This note summarize the architecture proposed by the project "Collaborative Care Team  in Open Source" of the ISfTeH, International Society for Telemedicine & eHealth.
• A patient centric approach.  Indeed the follow-up of any patient may need any kind of care, maybe having multiple problems at the same time.
  
• A very modular architecture intended to allow the integration of existing medical softwares available in open source, as well to allow distributed developements and maintenance at international level.
  
• A seamless approach, the ordinary user will just see an ergonomic human interface and will not mind of the architecture behind his/her browser.
• Architecture based on 4 levels, (1) User's browser, (2) Presentation, (3) Application Core Logic and many (4) Sevices, connected by means of formal interfaces. 
  These components may but do not need to be in the same machine.  For example the IPATH service would usually be located thousends kilometer away.  The users interface is in priciple always in web mode, regardless if the the other layers are located far away through Internet, in the same building, or even a subset of the services in the same laptop in case Internet would not at all be available.
   
  

• ( 1 )  User (red)

• Users need only a standard web browser, as Firefox, available on all usual operating system platforms.
  

• ( 2 )  Web Presentation layer (yellow)
  

• Objectives:
• A web server focusing on the presentation issues.
• 
  
• Approaches:
• Essentially the conversion of logical information into visual pages intended for the users, usually in XHTML format.
• A kind of "front end":
• Communicating with the core layer through formal interfaces:
• Calling application transactions in the "core" as explained below.
  
• Receiving information back, to be displayed back to the user.
• The presentation layer is expected to be the object of the most frequent requests for adaptations.
• Security dealing with encripted communications.
  
• Presentation issues in function of:
• The linguistic and cultural environment.
• The professional profile of the current user.  Indeed doctors and nurses require different presentations to be extracted from the common patient database.
• Specialized presentation requirements related to situation dealing with specific diseases as AIDS, tuberculose, malaria, cancer, etc...
  Remark: from an informatics point of view the goal is to avoid to make each time completely new softaware projects from zero, for particular professional profiles and deseases.
  
• Local preferences and existing procedures.
• The device type.  Usually the browser of a standard computer, but could also be a mobile phone, a voice machine, as well the representation of a message in a given format, as for example a HL7 messages.
• Current experimental prototype:
• Essentially the conversion of information coming back from the "core" layer, using a template system, currently Chameleon templates, http://chameleon.repoze.org/ .
• Some elements of experimental prototype are already available at http://vctdemo.gorfou.fr/ , although still very incomplete and containing errors. (user= "guest", password= "guest").
  

• ( 3 )  Core Logic layer (green)
  

• Objectives:
• The generic application logic of basic common services as required in most situations of patient care.
  
• Approaches:
• The core can be called by the front end.
  
• Management of generic functions as:
• User authentication, authorization profile, ...
  
• Patient identification;, "care team" management and "Role Based Access Control".
  
• The management of "Patient Items" of any kinds:
• Support of a "Problem Oriented" approach, an important factor intended to support education objectives.  Indeed the local user directly in contact with the patient should first formulate explicitely his/her current vision of the problems, before asking a second opinion to a remote expert.
  
• The main types of Patient-Items are here Observations, Problems, Actions, and  Contacts, each of these groups being subsequently derived into many more specialzed classes.
• Multipath navigation trough related patient Items and related medical knowledge.  Semantic web technologie are considered here, i.e. no more the limitations to strict hierarchical directories.
  
• A provisional model is available at http://www.chos-wg.eu/Software/Modules-Overview.html .  First the "common generic requirements" and then the "additional requirements" in function of particular situations.
  
• ....
• Databases:
• Access trough a formal interface, allowing to communicate with several types of databases as http://www.zodb.org/ , http://www.postgresql.org/ , ... (dark green on the schema)
  
• Call of external services:
• The core can call external "services" based on external open source components, developed and maintained by external organizations.
  
• 2 options:
• Send requests and receive information to be managed, i.e. showed in the prestation layer and stored in the patient data base.
• Possibility of temporary full delegation to an external service, the user interface from the service provider being simply tramitted in a frame of the front layer.
• Current experimental prototype:
• Written in Python, http://www.python.org/ , communication between the layers by means of  "XML-RPC" protocols, http://www.xmlrpc.com/ , a neutral approach allowing communication between modules written in different programming language, as PHP, Java, etc...  
• Every layer is accessible on a distinct network address, front-end, core and external services, regardless if in the same computer or somewhere else.
• The network philosophy is to avoid unnecessary centralization.  Most traffic is expected to be at regional level, but when necessary regional servers will have the possibility of exchange information with other servers in a larger international network perspective.
  

• ( 4 )  Services layer (blue)
  

• Objectives:
• Reuse of available medical software modules in open source.
  
• Approaches:
• External services will receive requests from the core and provide information.  A few adaptations will be necessary in order to accept theses requests and provides responses in a technical neutral way, as XML-RPC.
  
• Formal interfaces agreements will allow to delegate developements and maintenances of modules to groups based in other countries.
  
• Some considered services:
• IPATH lab:
• If a patient need pathology, the coordinating "core" will contain only a small link to the IPATH system and delegate this lab business until a final report will become available.
  
• Current applications in the Philippines:
• ..........
  
• Administration:
• Handling of administrative issues as declaration of services, tarification, billing, book keeping, human resources, stock management, etc...
• Could be processed by the comprehensive open source package "OpenERP", http://www.openerp.com/ , while only tables and parameters will need to be adapted. 
  
• Remarks:   a project also based on similar principles of front-end web server and a back-end core processing.
  
• Additional services as could be required by disease oriented projects.
  
• Medical images processing:
• Could be provided by OsiriX, an advanced open source package for radiology image processing, developed at the university of Geneva, http://www.osirix-viewer.com/ .
  
• Drug interaction database:
• ...
• Epidemiological packages:
  
• .......
• ....