Tim Churches wrote: > David More <davidgm at optusnet.com.au> 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. 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. 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? Tim C
