Hi All > Tim Churches wrote: > Richard Hosking wrote: >> Reading the OpenEHR site again - they are progressing and seem to be >> the best candidates for an information model. There is 20 years of >> research behind the concepts. Unfortunately they are using Java, >> Eiffel, and C#, but the info is open (Mozilla license - is this a >> problem?)
There is a lot of openEHR development going on in a lot of different development environments. Indeed on the openEHR website you can find a mixture of Java, Eiffel and C# and some MySQL db schemas. openEHR is completely development environment agnostic and the only requirement is that all the software conforms to the open source specification. > The currenly available openEHR tools are all for creating and > validating Archetype definitions. The choice of languages is not > really a problem for such support tools. Mozilla license is fully open > source, and rather less restrictive than the GPL. No problem at all. There are now more than just archetype creation tools available. There is now an early Java reference openEHR engine which comprises a number of components, probably the most important of which is the kernel - "a small but sophisticated component which implements the reference model (RM) and archetype model (AM) in order to actually use archetypes at runtime to build and validate data. It is the key component in many openEHR services, and central to the archetype method." OceanInformatics have a C# based kernel is likely to be opensourced in the near future. >> How could we translate Archetypes into SQL tables in a database? >> I guess it could be done by hand - better would be some sort of parser. >> This is a separate issue to the user interface of course There are two parts to the openEHR specification - the archetype model and the reference model. The archetype model allows you to describe and constrain a clinical idea such as blood pressure. The reference model allows you to build concrete examples of these archetypes and in the openEHR world, a database is full of reference model components that are described by archetypes. One of the main advantages of this design is that the underlying database schema can be designed once and as long as the reference model doesn't change, ANY new archetyped data can be included even if it's a new concept or hasn't been seen before. The clinical concepts are completely separate from the database schema. This also makes it possible to exchange data much more easily i.e. a discharge summary can be received and a blood pressure contained in some part of that discharge summary can be understood and included in any list of blood pressures that the software provides. > The idea is that Archetypes are the storage mechanism - just text > files > - but this implies the existence of openEHR storage engines which can > make use of them. This is the missing part of the puzzle - not such > engines are generally available, either as open source or > commercially, althought there is a Swedish one which is very poorly > documented at present. A few companies have built their own engines > for use in specifica products, but openEHR Arcetypes won't fly until > there is a range of open source and commercial data storage and > retrieval engines for it. > Tim C There are a number of projects around the world that have built systems that utilise this structure and in Australia there are at least three working examples of openEHR kernels including a commercial offering that is being used by QLD Health. Its true that for openEHR to work, we will need some open source and commercial engines - this is happening now and support is growing all around the world. Hugh Leslie __________________________________ Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI Ocean Informatics Pty Ltd M: 0404 033 767 E: [EMAIL PROTECTED] _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
