Hello, One of the greatest challenges in front of the Care2x is adoption in different kinds of hospitals in different kinds of places in the world. The healthcare in different countries has different requirements. In some countries these requirements change year-by-year (or even more frequently). Even there are hospital that has their own requirements for the HIS system.
Care2x tries to be as generic as possible to fit the needs to the greatest extent of the hospitals. But it is not possible Care2x to fit the needs of all of the hospitals (or even to one of them) just out-of-the-box. For every solution Care2x has to be more or less customised. Let's take as example the solution for East Africa. The healthcare in USA and Tanzania has very significant differences. This led the developers to the idea of making separate branch (ELCT) for the East Africa solution. And they are right! The customisation of the original Care2x, however, is so big and specific, that it is hard to decide what of the features implemented in ELCT could be contributed back to the main branch. Sometimes it would need additional efforts to make new feature as general as to fit in the original Care2x branch. At the current state of the Care2x architecture branching for specific solutions is inevitable. On the other hand, keeping Care2x as generic as possible makes the process of merging features back to the main branch hardly possible. Customisation is necessity. What has to be changed in the Care2x architecture is that there should be a framework that defines strict rules how Care2x can be customised. This framework should give great flexibility for customisation and in the same time keep these customisations as closest as possible to the main branch. Actually, there should only one branch - the main branch. There is a solution for this at the moment, but for desktop applications - the Eclipse project [1]. This project defines a plugin framework where each plugin is a separate module that contributes features to the application as a whole. Plugins has dependencies between them and one plugin can customise a feature defined in its dependant plugin using the so called "extension points". I believe something similar can be done for php web applications as well. The generic HIS functionality can be implemented in basic plugins that define extension points for customising specific features. These extension point will be used by plugins for specific solutions. At the the solution for specific country or hospital will be distribution of a set of plugins. Let me visualise the idea in an example. Let's take the patient registration form. If we generalise the patient registration record it would include the following features: - system id - name - sex - date of birth - citizenship registration (citizenship id, country, address,..) - contact (phone, mail, fax, ..) - insurance info - blood group - etc. If we examine only the 'name' feature we will see that it has lots of attributes in different countries: title, first name, last name, middle name, maiden name, third name, ..., Nth name, tribe, caste, ..., whatever attributes I have never heard of. Each country uses different subset of these attributes to identify its citizens: - USA: title, first name, last name - Bulgaria: first name, middle name, last name - Tanzania: first name, fathers name, third name, tribe - India: I've heard there they have lots of names. Now let's have 'care2x_patient' plugin that defines the patient registration record model. In this plugin there will be an extension point defined for the 'name' feature. Attributes for the 'name' extension point will be contributed by other customisation plugins like: - care2x_patient_usa - contributes first name, last name, title - care2x_patient_bulgaria - first name, middle name, last name - care2x_patient_tanzania - first name, fathers name, third name, tribe At the end the solution for Tanzania will be set of plugins that include care2x_patient and care2x_patient_tanzania, but not care2x_patient_bulgaria and care2x_patient_usa. An assembler script will go through the set of plugins and will evaluate the dependencies, extension points and extension contributions. It will construct the solution-specific database schema that will be used by the installer. At runtime the extension points should be evaluated as well. For example a patient search form should lookup the attributes for the 'name' feature to decide what fields to generate in the search form. Such kind of plugins framework separates the application design from the basic code implementation. All of the Care2x design has to be migrated to models that describe each feature of the system and defines extension points for customisable ones. The basic code implementation - the framework - will actually exploit the model to provide the necessary functionality. Such separation is for good, because developers with stronger medical background can concentrate on the models, while those will stronger programming skills can work mainly on the framework. Upgrades to newer versions of Care2x will also be executed with much less problems, because the customisations are isolated in separate plugins. I want to here your opinion, suggestions and questions about this proposal. I realise that this is a major architectural change and is not achievable in short term. I am seeing it in a future major version of Care2x like 3.0. I am also planning to make a simple prototype (proof of concept) of this idea as diploma work. So, hopefully, I will be able to show you something in the near months. [1] http://www.eclipse.org/ Greetings Kaloyan Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Care2002-developers mailing list Care2002-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/care2002-developers
