"Collaborations in Healthcare Open Source"
Technical Requirements

1. Introduction:
• Objectives of the projects:
• Support of collaborations in Open Source Healthcare, as explained in http://www.chos-wg.eu/ .  Integration of software components created and maintained by different groups in the scope of an international community.
  
• Improvement of patient care, by means of support of improved collaborative work between the care providers in charge of the same patient.  A summary of the Virtual Care Team project is at http://www.virtual-care-team.be/ .  Focus on a patient record in which several actors can read and write, depending on carefully designed access rules.
• This proposal is a provisional vision of what should be achieved in the coming years, although to be extended and adapted in an incremental way.
   
  
• Purpose of this document:
• Description of the technical requirements for the project.
   
  
• Summary:
• The main idea is the need of some kind of "glue" allowing to integrate existing software components in open source, as far as possible without too many adaptations.
  
• Information sharing:
• The project require to be able to share information between the healthcare professionals in charge of the same patient, across organizations boundaries.
• Focus on on-line network approaches, taking advantage of new technologies.  An approach no more limited to email-like messages exchanges.
• Context:
• The project is in the scope of international working groups intended to share informatics know-how in the healthcare domain, particularly in Open Source working groups of the EFMI and the AMIA , as well Open Source organizations, as OSOR.
• Prototypes:
• Prototypes are essential for the development of the project, for several reasons:
• Involvement of healthcare users, who want to see visual prototypes and are willing to discuss scenarios, but are in general not at all interested in written specifications.
• Involvement of informaticians, motivated by the technical challenges related to the implementation of up to date technologies, as necessary in healthcare.
• Credibility issues about the feasibility of the project.
• The next chapters below are a review of prototypes requirements and considered approaches. 
  
• At this prototype stage, the priorities focus on easy rapid development tools.  The machine load is very low and efficiency of processing is here not yet critical.
• Production version:
• A smooth evolution should be possible from experimental prototypes to more professional versions, without radical changes of technology.
   
  
2. Requirements and approaches:
• Flexibility:
• The main goal of the project being daily patient care, a great flexibility is required.  Tools making the representation easy for:
• Objects with very varying length and with many optional attributes. For example free text comments should be allowed everywhere.  
• Arrays of arrays of unpredictable length and nesting levels.  These objects have to be saved and retrieved.  
• Collections of objects seen from the application logic and which may be of different technical types, i.e. "polymorphic collections".
• Navigation in the patient record, like how you would talk to an assistant.  Any item of information should be accessible from several points of view, for example "give me all what is new since a week", or "all about blood pressure and related issues (measurements, related complications, medications, ...)", etc... i.e. not only a tree structure, but items which can be retrieved by mean of several keys and links, to some extend in a way similar to the philosophy of "semantic networks".
  
• Allowing extensive use of XML, since important healthcare standardizations are based on XML, for example HL7 one of the most known international standards, and KMHER, the Belgian medical data exchanges standard in XML, etc...
• Database interface compatible with object orientation.
• Remark: Although epidemiology and billing could still be done with more traditional relational DB approaches, the focus of the project is patient care.
   
• Modularity and integration capacity:
• Integration is a critical factor.  Many open source software are already available and should be reused as far as possible.
• The essential goal is that software will be shared as far as possible, at least some components of generic interest.  Since the local requirement of implementations in different contexts may be slightly different, it is very important to keep the freedom of choice of components.
  
• The purpose is not to reinvent everything.  The problem is that many existing softwares were not particularly designed to be modular.  Adaptations may be necessary. 
  Anyhow existing established softwares should be renovated from time to time.  Moreover there are always requests for extensions.
• Critical issues are:
• Clear encapsulation of functionalities:
• i.e. "Object Orientation"
• Multiple inheritance.
  
• "Services":
• As far as possible independence between the requesting module and modules providing the service.
• Services are represented by "Interfaces" and a request should not need to know details about how the service is build.
  
• A framework supporting these approaches and allowing adaptation of external modules.
   
• Open Source:
• A large set of healthcare requirements are common in every regions of the world, regardless of specializations, regardless of the degree of maturity of the local developments.
  This means that the reuse of common software components and knowhow is particularly efficient in the healthcare domain in a worldwide perspective.  This is why the project is developed with an open source approach.
• Multi platform compatibility is essential in order to create a community, of both medical users and developers.  
  Multiplatform is mandatory for the workstations at the user side. Therefore a preference for the standard of web technologies, available on all platforms.
• Open Source is expected to become an important factor of interoperability, much stronger than the previous efforts to standardize only the messages between closed proprietary systems.
• Sustainability by means of avoiding dependency from any single software provider.
   
• Interoperability and standards:
• Common tools:
• The main goal of the project is collaborative work between actors who are located in diverse organizations, having diverse informatics environments and where we having nothing to say.  This situation require technologies which must be already available everywhere, i.e. web technologies, XML, etc...
• Current standards:
• Compatibility with existing healthcare standards, although only as far as useful for communication with others, and not just because they have been ever declared "standards".
• Keep in mind that most existing standards focus only on message exchanges, not making the distinction between the content and the container.
  
• Many standards were developed for epidemiology purposes in large populations, i.e. the problem being how to group similar cases under a common label.  At the other side patient care require more accurate descriptions of individual cases.
• The use of codes intended for data compression is no more relevant as it has been earlier, because disk space and communication speed did become very cheap, with a factor of about 10000.
• New challenges about standards:
• Need of standardization of interfaces to "services", since we are now in an on-line environment.
• Semantic web approaches, need to be able to cope with multiple weighted links between concepts.
   
  
• Neutral Integration Environment:
• Introduction:
• Work philosophy:
• From now on the main philosophy is "on-line integration", although "message exchanges" will continue to be used too.
• Independence between the environment of the request and the one processing the response.
  
• Platform independence:
• Web technologies, because this is the most widely way to access information.  Indeed many intended partners of healthcare networks use different kinds of technical platforms and all these environments have already a compatibility with internet, today the de facto standard.
  Platform independence is very critical at the client side.
  
• Programming language independence:
• The project is intended to integrate software components coming from diverse technical environment with diverse programming languages and and which will continue to be maintained according to their local own preferences.
  Therefore as a whole the project should be perfectly neutral and completely language independent.
• Neutral data representation:
• Data sharing between different environment need to be based on common conventions.
   
  
• Processing:
• Integration:
• Tools suited for integration of existing software components from diverse origins. Moreover  The situation is that potential partner are working in Java, PHP, XML DB with Query, C++, Visual Basic, and a few with Python, etc... 
• Processing:
• Moreover There is a need for much more than just a CMS, Content Management System.  Years ago the first medical systems were intended only for reporting of facts.  This descriptive capacity remains necessary, but there is nowadays a critical demand for processing and management of activities.
• Work flow:
• a fast growing demand for the management of work flow of care activities,  In a working team many activities are ordered and need to be followed step by step.
• a begin of decision support procedures, or let say at least quality monitoring, providing advices and warnings.
• The requirements about flexibility, reuse of software and possibility of extensions, do necessitate an object oriented approach.
  
• Large libraries of software tools should be available and a framework should be available.
   
• "MVC" architecture:
• Introduction:
• Need of a clear distinction between the main layers of the system.  There is a need of many specific views to be extracted from a few common models.
• Model:
• A generic common model of patient record, with derived classes when necessary.  Neutral and standard interfaces to data storage.
• According to the proposed specifications, a very modular model is recommended, in order to make possible to reuse a selection of components.  
• View:  
• Although around the same common patient record model, different professionals like specific presentations according to their own points of interest.
  For example a doctor and a nurse look in different way to a common patient record, they have to share.  There is no need to continue to maintain completely separated and largely duplicated computer systems for doctors and for nurses !
• During experimental and incremental developments, the most frequent requests for adaptations are expected to be here at the presentation level. This means that the presentation layer should remain clearly independent from the other 2 layers.
• Requirements about adaptation are expected due to:
• different cultural environments as different spoken languages and traditions,
• different kind of human organizations,
• different focus on the same common patient information, because the users have different tasks (GP, specialist, nurse, ...)
• .....  
• Tools for the management of internationalization of the screens intended for local users.
• Control:
• Logical Control level, between model and view.
• Reusing many common functionalities, with the possibility to created derived classes providing additional functionalities.
   
• Ergonomics:
• The system is intended as well for intensive users as well for occasional users and beginners.  These users are not at all willing to go through training sessions nor user guides.  Therefore the man-machine dialog must be very self explanatory:
• Many contextual help functions.  This is particularly important for experimental prototypes.  Discussions about controversial issues in development should be accessible directly inside the proposed elements of prototypes.
• Navigation according on the zoom principle.  When looking at some thing one should go easily to more details and/or related information. Grasping an object, i.e; clicking is something very natural.
  Remark:  this approach is very natural.  An interesting comparison is here that 2 1/2 year old children can already use a mouse to play with some animals from Walt Disney, while absolutely not yet able to read.
• Response time is critical and should be < than 1 second in most transactions.  If the inherent "page-approach" of web technologies would become too slow in some situations, this could be alleviated by some pieces of local processing, as possible using AJAX.
   
• Security:
• Confidentiality:
• Tools allowing to implement "Role Based Access Rules":  the main requirement is that every patient must have a specific "Care Team", i.e. a kind of group of authorized users, in principle under the final control of the patient himself.
• Of course the confidentiality is very important for personal patient records.  This must certainly be at a higher level than in the traditional organization related to medical records, based on paper, a situation which is usually accepted as being "normal".  However the introduction of informatics should not become paranoid.
• Medical Responsibility and Quality of care:
• Even more critical than the confidentiality.
  
• The responsible author of any information must always be known.
  
• User authentication and control of user qualifications and affiliations. The "Care Team" as explained above is here also essential.  Who is allowed to do what in function of which role?
• The details of these access rules may depend on cultural difference in different countries.
• Technical reliability:
• Also very critical. Does the software always what it is expected to do, according tho the specifications?
  
• Automatic tests and redundant controls are strongly recommended.
• Certifications will become critical.  To be evaluated by independent experts.
  
• Moreover since the risks could never be reduced to an absolute zero, residual risks should be insured.
   
• Strategy of collaborations:
• International community:
• A large project require the creation of a community.
• Coordination:
• Problem:
• Too many projects are a kind personal projects of one person or a few people.  Doctors are very individualistic.  The natural dream of every doctor is to have a personal programmer at hand.
• Coordination is a critical requirement
• Coordination and distribution of tasks.
• Seeking support from dynamic communities.
• Incremental development:
• The users must follow the evolution step by step.
• Incremental development:
• Starting from a vision of the most common requirements for every user in every context:
• Start with basic versions of prototypes.
• Improvements and extensions step by step.
• Adding specific extensions, step by step, in function of specific contexts.
• Modularity:
• Modularity is very necessary for several reasons:
• In order to allow distributed developments of web services.
  
• From the Open Source viewpoint:
• The essential goal is to facilitate the reuse of the same software.  
• the strategy is:
• Not to try force large packages. A package excellent for a given initial environment is often not accepted in and other situation in an other countries, where the priorities may be different.
• But to propose components, made attractive:
• In existing projects providing new or better functionalities.
• In starting projects avoiding work when appropriate components are already available.  Or at least much less effort if only a few things need to be adapted or extended.  Moreover local team could like to be involved in these small extensions which is possible in open source and could benefit other partners.
  A trade off between less work and accepting things "not invented here" may not 100 % as one would have dream.
  However local resources are in general limited.
  The goal of the project is to provide a toolbox of generic minded components, based on past experience.
• Easy tools for prototyping:
• RAD, easy Rapid Development tools because many options will have to be proposed in a visual way although preliminary experimental version need to be simplified.
• Very necessary for 2 reasons:
• to discuss the functional approaches of the applications with the users, who like to discuss in front of visual examples rather than formal specifications too difficult to read.
• to demonstrating the feasibility of the proposed technical solutions.
• Although the requirements of prototypes and production version are not identical, as far as possible one should work with the same kinds of tools.  
• Later when the functional specifications will become more mature, the preliminary prototypes will need to by reviewed by informaticians, and in most cases more or less completely re-written in a more professional way, before going in production.
• Well planned development of the iterations:
• Documentation of proposals:
• Informal discussions may be useful, but written specifications must to be made before any development.
• Discussions, using a WIKI.
• Conclusion and approval of specifications
• Coding test procedures.
• Coding the real content.
• Evaluation of results.
• Iterations should be relatively short.
   
• Selection of technical tools:
• Software tools having the support of a reasonably large international community of people having know how about the programming language and approaches.  It should not be difficult to find people having the necessary experience to be able to participate in the project, without long training.
• Tools supported by a dynamic community, providing maintenance and new developments.
   
• Documentation:
• The quality of the documentation require special attention for several reasons:
• To make possible to share distributed development with partner in other regions, avoiding unnecessary duplications of development work.
• For the sustainability of the project, avoiding dependencies from any single software provider.
• And simply because good documentation is always a factor of quality and continuity.
• The default development language is English, but the users need to see everything in their own language.  In most situations only one language, but in some regions a few languages depending on the preferred language of the user and/or the patient.
• 
   
• .......