>> hope this clarifies Thanks, Thomas, it clarifies why archetypes do not suffice in application-context for data entry/presentation. For the moment, we can live without templates (leave it to form-developers to define where to use a specific archetype-item), or fabricate template-definition for internal use. In initial phase, it does not have to be very complicated.
> for UI:s. The problem is the there is no complete template > specification. I agree with Olof that there is a need for formal template-specification. I think that when there is, it will be possible to exchange templates, application forms, or even better, develop to exchangeable application-functionality. This would cause the openehr-kernel to become a supporting module which presents forms and stores data. But the real application will be defined in the templates. Is this the road-map we are looking at? Or are the goals different? My thoughts on a Sunday-morning: Medical-information-application-development will be a matter of writing templates and archetypes. This can than be done by people specialized in writing/defining GUI's and specialized in medical applications. I remember this to be one of the original goals of the openehr-kernel. The mix needed for software development, not only medical, is that an application-developer needs to have technical knowledge, but also domain-knowledge. Very often this prevents developers to be as good skilled as would be possible if they could concentrate on either. (no flame bait intended, there are many positive exceptions) Software-developers than can concentrate on writing a good kernel, writing good tooling. They can concentrate on the technical part of an application. For example: It would even be possible to write a OpenEHR-OS, highly optimized for this purpose. This could, for example, be based on the Linux-kernel which is available for this, because it is open source and therefore modifiable. It also fits in the idea of having a separate OS-instantiation for each separate service-application possible running in virtual environments. If for scalability-purpose needed, it can also run on separate servers, clusters, or even distributed. A matter of modularity. regards, Bert
