Karsten Hilbert wrote: > On Sun, Jan 01, 2006 at 10:06:56AM -0800, Jim Busser wrote: > > >>>The latest candidate openEHR specifications are at >>>http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/index.html >>><snip> >>>Should these form the basis of data structures in Gnumed? > > That isn't a useful question IMO. > > A useful question would rather be something like "Should > these be taken into account for the developement of GNUmed." > > OpenEHR does not simply define data structures. It defines > entire models (actually, two of them). Hence any software > being "based on" OpenEHR *is* OpenEHR. It would mean a > complete rewrite (middleware, backend).
My understanding is that openEHR Archetypes will act as intelligent, self-validating storage "objects", and thus an openEHR storage engine will be a lot like an object database. However, widely available openEHR storage/retreival engines just don't exist yet - there is one open source one in Java from Sweden I think, but last time I looked it was incomplete and lacked documentation. > However, that may be desirable in the future. In fact, if > any of the standards I know of are to be our future it's > OpenEHR as far as I am concerned. I have previously said so. I agree, but until there is an engine to play with, it is hard to tell how many of the theoretical advantages of the openEHR approach will carry over to the real world whne used in real information systems. Teh Australian trials of openEHR in Queensland relate to a shared community EHR and thus only involve secondary data col;ection, not the initial data capture or generation (as commonly occurs in GP information systems), It will be interesting to see how openEHR translates to the latter domain. I just wish they would bring out an open sourced engine. >>Potential Pros >>- a wider set of use cases has likely been factored into the design > > yes > > >>- they could assist interoperability > > possibly It depends how widely openEHR is taken up and what form the social infrastructure which faciltates the sharing and co-ordination of openEHR Archetypes takes. A lot more work needs to be done (and not just by the openEHR people) on the latter, elase it could end up as a big mess of incompatible Archetypes. >>- efforts under this framework could be better pooled > > potentially OK, that's the point I was making pre-emptively above - I must remember: should always read ahead... >>Potential Cons >>- the more expansive, the harder to imagine "whole" implementations > > definitely > > >>- have the specs been assembled with a view to being manageable to >>implement? > > not really as far as I know them, implementable yes, > manageable, no, not at our current scale of developers You'd have to write a storage/retreival engine from scratch. We thought about this in 2003 for NetEpi, but decided it would be about a person-year's of work, which we couldn't afford. It is now 2006 and still no open source openEHR stoage/retreival engine. >>- hard to code without reasonably fully "digesting, internalizing" >>the process that created the specifications? > > yes, hard to code, however, not impossibly hard to digest The basics are just regular expression wrangling on strings, relating to each other in fairly sterotypiocal and generalised ways. Perhaps our estimate of one person-year was too conservative, but a awful lot of time would need to be put into unit tests and higher-level functional tests, which means assembling comprehensive suites of test cases, and that could be very time consuming - the point being that if you write an engine fro scratch, you have to be sure it works. But doable in Python. If I won te lottery tomorrow, that is one of the projects I would fund.... >>- could the specs, if written to accommodate the widest possible >>audiences and use cases, limit their usability (on account of >>compromises) for any one audience, or use case? > > That shouldn't happen, actually. The idea of Archetypes is that they allow "principled" specialisation, so a group can start with a more general Archetype and then specilaise it for their more specific use, and still remain backwardly compatible - or at least, the compatibility issues should be automatically explicit. >>How much of the specifications define how data ought to be >>*stored/structured* > > hardly any, it gives tools for structuring, but does not > define how, it does not define how to store pretty much at > all Agree. I think teh openEHR approach is just store everything as strings in a BLOB or just in a file the filesystem. That's teh dumb "back-end" but all those files/BLOBs need to be addressed via an engine whcih implements al teh openEHR constraints when working with those files/strings/BLOBs. Some form of keyed indexing would be needed though to maintain look-up performance. >>If, on the whole, the pros would outweigh the cons, some thought >>could be given to a migration strategy, maybe to happen after v 0.4? > > v2.0 or so Separate project, perhaps GNUmed2 perhaps? >>Perhaps identifying how the openehr schema could be roadmapped >>against what will already have been done would be useful? And would >>this only happen if, among the gnumedders, there are individuals who >>would do *both* this legwork *and* code? There is a high likelihood >>of non-follow-through if the result of the exercise is simply someone >>who learns/digests the openehr "way" to just "advise" everyone it >>ought to be followed. > > OpenEHR is - AFAICT - an all-or-nothing approach. No > asymptotic approach from our side being possible. Agree - hence my suggestion of a separate project if anyone wants to follow the openEHR route. Could well be worth following. Tim C _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
