I presume this was posted here to get a reaction from someone in openEHR, so I will briefly react...overall, Tim has given a pretty reasonable airing of some of the important points for the future. To my mind his claim of the possible lock-in of data is slightly exaggerated....but in any case, read on...
Tim Churches wrote: >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. > > This is about the right technical solution, and the one we describe in presentations on the topic. You need an archetype cache, or what we call a local archetype service, and local archetype repository anyway for various reasons: - any given site is likely to use only a small number of the total available archetypes, e.g. 50 of 2000 or whatever it might be. The local cache only needs this number not the 2000. - it is sensible to have archetypes converted from ADL to runtime-ready form, which will vary in each institution's case. - your system needs to run if you lose network connectivity with teh archetype library server (or it goes down). - you may not want archetypes in raw parse form such as ADL or XML, since there might not be any guarantee that they will all parse at runtime, e.g. due to mistaken changes to archetypes, introduction of non-parsing archetypes, or software changes. Pre-conversion to runtime form guards against this. Part of the story is that archetypes have to be governed properly. This is starting to be set up in Australia and openEHR has created an open Clinical Revoew Board for archetypes served from openEHR.org. Some of the features of good governance will be: - guaranteed public availability of any non-local archetype, in ADL form on one or more internet archetype library sites - quality assurance process which guarantees technical & clinical well-formedness, as well as compatibility with existing archetypes (i.e. minimise/avoid overlap). To get a feel for one possible interface to an archetype library server, see http://www.dualitysystems.com.au/archetypefinder/archetypefinder. This is basic but gives an idea of the functionality. Note that the GUI is not a static form, but is built dynamically from categories in a Protege ontology. >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). > > this is one of the reasons that archetype libraries have to enforce agreed lifecycle and version control, so that archetypes do not exist in the wild. Eventually the tools will be available so that institutions wanting to develop their own archetypes rather than just use the existing ones (e.g. defined by RACGP, NeHTA, or whomever) can actually implement such controls inside their own walls. > > >>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). >> >> correct. What is more, to guarantee that archetypes that you use in production - ones that claim to be certified - really are the same content that was certified, they will need a digital checksum of some kind. > >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. > > that is certainly the intention. openEHR currently has a number of licenses for various artefacts it makes available(see http://www.openehr.org/about_openehr/t_licensing.htm). It is developing a suitable license for archetypes. >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 > > you cannot modify the definition of a released archetype. Well obviously physically you could, but the checksum will no longer be correct, and the tools won't use it. Instead you have to create new version(s) and submit them to whatever is the appropriate level of QA process. (BTW - the tools and ADL don't yet support the checksum, but it is coming, and is technically relatively simple). >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. > > What is needed is the right to a) create new versions, and b) to create dependent specialisations. >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. > > well, I don't know that I would go that far. It is pretty hard to claim that data in a standardised, open format rather than a closed commercial format is more locked into vendors. I would see it instead as about the same problem as the re-usability of data that contains e.g. snomed-ct codes or similar - the use of which are licensed by the CAP (currently, but that should change in the future). >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. > > actually, we would argue that it is essential to have open source kernels (plural because you need one in each of the main languages it seems...) - otherwise the temptation will be for vendor orgs to produce slightly different "versions" of the standard, a la Microsoft HTML/functionality in Explorer. We just don't need that happening... - thomas beale
