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/1fb171df/attachment.html>
