Greetings, Minor point about one of the projects; Opereffa, and what it is trying to do. To serve the community spirit of the openEHR foundation, I've put a lot of functionality into Opereffa, which would not be necessary for the real purpose it was built for: my PhD work. Due to well known, and repeatedly expressed issues regarding resources, I can only provide examples of tackling key issues in Opereffa, but what is out there already provides food for thought for a lot of things. It has an Eclipse plugin to generate UI from ADL files, it has a persistence layer that uses Hibernate and postgresql with some db side tricks etc. It includes integration to an open source terminology server to save snomed ct items along with archetypes. I'm not claiming these are mature or best implementations of the explored concepts, but they are still useful starting points for anyone interested in the domain.
I don't think any of the projects or Thomas (personally or on behalf of openEHR foundation) "has to" provide more examples for anything, for no person/institution on the planet can tackle the task of implementing every major use case around openEHR, just to prove that the design can deliver what it claims, or for any other reason. Finally, my humble suggestion will repeat the comment from Thomas Beale: don't get trapped into wide spread definitions of "modern software development", since modern tools of a huge community may disappoint you when it comes to handling implementation requirements of openEHR. Most tools/frameworks will give you a fast route to implementation by cutting corners, but if you may end up with inserts/reads of 8-10 second.Focus on the concepts of implementation, not the specifics. regards S On Fri, May 6, 2011 at 4:17 PM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > > 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
