Hi Tim
See short comments below.
David
---- Dr David G More MB, PhD, FACHI Phone +61-2-9438-2851 Fax +61-2-9906-7038 Skype Username : davidgmore E-mail: [EMAIL PROTECTED] On Sun, 08 Jan 2006 20:17:31 +1100, Tim Churches wrote: > Tim Churches wrote: >> David More <[EMAIL PROTECTED]> wrote: >> >>>There is another issue buried here - and that is what happens when a >>>supplier of a >>>commercial EHR goes 'belly up' etc and stops serving the requisite >>>information for a >>>stored archetype to be interpreted from. > >> Yes, and copies of the archetypes managed by this "reference source" >> need to be automatically replicated or mirrored to dozens of other >> sites run by independent entities, so that the world doesn't end if >> the host of "reference source" goes down the gurgler - someone else >> can take over. > > Thinking about this a bit more, it occurs to me that simply having > archetype definitions mirrrored at lots of sites is a start, but it > isn't really enough. An archetype (and the reference model it relies > upon) is essential metadata without which the data stored in the > database back-end of an openEHR system is meaningless, or at best rather > hard to interpret. > > Thus, archetypes need to be stored, permanently, with the data. This > implies that each and every openEHR/archetypes storage system must be > able to permanently cache (that is, archive) each version of every > archetype definition it has ever used to store any data. You have now got what I have been worried about - and the issue is amplified by every variation that is permitted. Governance of all this I am not sure is actually do-able - what do you think with say 5 different GP systems, 1000 different path and radiology tests etc etc..
> > Caching of archetype definitions is only sensible anyway, as it would be > too slow to have to look them up in a remote repository every time they > needed to be used - but the cache must be permanent, and older versions > must never be overwritten (no matter what the stated version in the > actual archetype definition says - one cannot rely on the archetype > authors to update the version information correctly). > >> Of course, such replication or mirroring implies that all the >> archetypes in that "reference source" are licensed in a way that >> makes such automatic copying legal. The openEHR ones all are >> (although they need to state that in the body of the archetype >> definition). > > If the argument above - that there is a need to permanent cache or > archive copies of archetype definitions with the data which relies on > them - then all archetype definitions need to be licensed in a manner > which permits users to keep permanent copies of them. My (limited) > understanding of copyright law is that such rights are not automatically > or implicitly granted - thus an explicit license to keep permanent > copies of archetype definitions will always be needed on every archetype > definition. Furthermore, if an end user wants to transfer > his/her data which happens to be stored using an archetype definition > for which the copyright is held by someone else (which will usually be > the case, since end users will rarely author their own archetype > definitions, especially de novo ones), then the archetype definition > used to store the end user's data must be licensed in a way that permits > the end user to redistribute that archetype definition to third parties, > without the need to ask permission from the copyright holder of that > archetype definition. > > Furthermore, if you want to add to your data, you will need to be able > to modify the archetype definition used to store it. Thus, you will need > that right granted to you from the outset, in an explicit license, by > the copyright holder of the archetype definition - otherwise you will > need to beg their permission just to be able to modify how you store > your data. Just gets more complex and harder!
> > Sorry for the long-winded exposition, but these are the implications of > moving most of the metadata and other "smarts" out from where it > traditionally lies, which is in the back-end database schema and in > middleware software layer, into archetype definition files. Note that > even if the back-end database and the openEHR kernel/engine software are > open source, if the data stored by them is done so using an archetype > definition which does not have a suitable license, then your data is > well and truly locked in to that archetype definition - whomsoever holds > the copyright to the archetype definition will have your data by the > short and curlies - just as much, if not more so, than traditional > closed-source software does. > > So to re-iterate, the moral is never, ever use an archetype definition > which was not made available under a perpetual, inalienable license > which permits you to both modify the archetype and to freely distribute > it to others, without needing the copyright holder's permission to do so > - in other words, a free, open source-style license. > > Interestingly, whether the openEHR engine/kernel (that is, the > middleware software layer which interprets and enforces the archetype > definitions), or the back-end database, are open source or not doesn't > matter nearly so much as it does with traditional software. Certainly > open source openEHR engines/kernels and other sofwtare components are > highly desirable, but it is the open source licensing of the archetype > definitions which really matters. > > Am I correct or is my logic or understanding flawed? I think you have got it quite close - and open-source does not save the day - its the information management of the archetypes that may save it - but the openEHR people seem to be in denial about establishing the infrastructure to do it....Until this ongoing Governance is nailed, certain and ongoing over decades this idea won't work IMVHO.
If I am wrong and these mechanisms are not needed to make openEHR work let us hear how the content of archetypes is going to be maintained over the years?
I am happy to be convinced I have lost it - often have before.
Cheers
David
> > Tim C > > > _______________________________________________ > Gpcg_talk mailing list >[EMAIL PROTECTED] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > __________ NOD32 1.1355 (20060106) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com |
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
