CCTOS: 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 providers were not too much motivated for collaborative work.  Commercial companies were not at all interested in interoperability, unless forced to do something.
    • Subjective ego problems.
      
  • 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 all 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 in a distrinuted environment.
      
    • 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.  Interfaces should be very well documented and system neutral.
          
        • 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.
  • Mobility:
    • Users should be able to move easily to other location and other machine, and not too depending on internet access. USB memories containing both the system and the current data.