Hi Thomas, "No data is stored in archetypes or templates". You mean no data entry is stored I suppose because you store semantics for generating a UI form (i.e. name of the fields on the form, descriptions, term bindings, language, etc). The view of the template as HTML tree or the archetype interface tab do demonstrate the appearance of a user interface based on the values the fields can accept. Are you mixing schema (data definitions) with data content here (e.g. term bindings) ? Normally they try to keep separate the two e.g. XSD, XML instance.....
About database schema The way I view it is that it can be designed to capture XML data, etc... see reply on the other email I sent. The difference is that you see RDBMS as only "a dumb but high performance data blob manager". And of course term bindings, domain constraints, descriptions can be very well part of the database schema. But you mentioned changes in the schema, well isn't there going to be some agreement on higher lever conceptual entities (archetypes), meaning that they will be standardized up to a certain level (e.g. symptom) ? Why can't you do the same with a class at the conceptual level (application object oriented programming level) ? If not aren't you experiencing the versioning problem of archetype, or what about in some cases many different archetypes for the same entity ! Or what about business logic when you use these higher lever conceptual entities, e.g. address, person name, etc. and you change their structure ? Moreover how about specialization of certain entities, clearly one might decide to go at a greater detail of describing features depending on the application. Regarding clarification on your software projects, I would have demonstrated the simplest case of openEHR data instances and how they are related to openEHR archetypes. The minimal software application to create an openEHR data form for entering data, the data instance that is produced, how to view it, and the related archetype that is used. If there is such an isolated example please do point me at the right direction so that I can study the code provided there is also explanation on how to build the application. Thank you Athanassios From: [email protected] [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, May 06, 2011 6:17 PM To: openehr-clinical at openehr.org Cc: Openehr-Technical Subject: Re: One model vs One framework in e-health ..... A few comments on a few misconceptions... On 06/05/2011 15:48, Athanassios I. Hatzis, PhD wrote: Hi Ian, you have certainly managed to isolate the clinical complexity from this technical layer up to a certain point and this is great. You offer clinicians software tools to design clinical care, administrative forms and prototypes using familiar terminology. you are missing the point of what a template is about. It is not a form; it is a structured data set (which main leave certain constraints open at runtime if desired). A UI form is one thing that can potentially be generated from a template, but today this is still in development. What is routinely generated from templates is XML schemas for messages, and APIs for programmers. But database schema is NOT irrelevant because it is the physical location of your data that are collected from your forms, that is the final/original destination. it may be the final destination, but it is rarely strongly related in its design to the data, unless you are using a classical relational model approach. This simply won't work in any complex domain, because your schemas and data will always be directly captive to today's requirements. As soon as the requirements change (they are constantly changing), your schemas will need to be changed, and your data will now require 'migration' of one sort or another. This approach is accordingly not particularly useful in health, or indeed in other complex domains. Instead, the physical way data are represented in any realistic system has to be at least one degree of 'model indirection' from the domain data models. In openEHR, one degree of model indirection this would mean dropping the idea of having tables and columns for 'patient', 'lab test result', and the other 1000s of clinical concepts, and engineering instead a relational table schema based only on the reference model. However, this has drawbacks as well: attributes can be added in a backward-compatible way to the reference model, but if the RM is implemented directly in a relational schema, now you have to go and change the schema, potentially breaking all kinds of things that depend on it. Performance is the other reason not to literally convert a realistic object model to a classical relational schema. Hence, 2 degrees of separation is most commonly used. In numerous products for probably nearly 20 years, one approach has been the indexed blob store. In openEHR, the typical blob is at the versioned Composition level; in other products the 'document' is the equivalent. Different grains of blobbing can be used. Regardless, the result is that the database is impervious to changes in the RM and in clinical content. Other solutions are available, and may turn out to be the most optimum, including path-based storage (Informix pioneered this over a decade ago), many variants on the object database, and all kinds of more esoteric web 2.0 solutions. Moreover a framework that is handling the database schema, the mapping of conceptual schema, and the management of objects at programming level is very popular in modern software development environments. my strong advice is not to get trapped in this area for any realistic system; the solutions you want probably won't be realisable. In your case, you are storing clinical content, business logic, vocabulary terminology and user interface fields among other things in your ADL archetypes, templates in order to be standalone, in order to be transferable. actually, no data is stored in archetypes or templates. Data are represented at the object level as RM instances; these are then typically either stored in direct object form (e.g. Tim Cook's SOHIP platform, using Zope), or if the persistence is relational, serialised into blobs of some kind. In such approaches, you can think of the relational database as a dumb but high performance data blob manager. I can appreciate that and the fact that there can be similar poorer approaches that other followed with tools such as Infopath to store/retrieve/exchange XML data. But as a developer/architect I am not aware and I cannot comment on the complexities you face when you need to read the structure, data content and relate them with other data collected from other sources (databases, documents, etc), or interoperate with other systems and clinical document formats that require a different serialization or store the data from multiple openEHR forms. actually it is pretty easy: all openEHR data are just instances of the reference model, and there is only one reference model. I believe that you have to provide more examples apart from openEHR Java and Opereffa projects of simple processes (data entry, data storage, data retrieval, data reporting, data serialization (CDA,CCR), data view, etc) that are based on openEHR and implemented in popular DBMS, RAD environments and other open software tools. that is what these projects are doing. Perhaps some more explanation is needed to clarify how they function. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110506/f976854f/attachment.html>
