Tim Churches wrote: > Thomas Beale wrote: > >> oint... >> > > So archetype definitions confer no additional functionality beyond the > reference model? That's a rhetorical question - I know the answer. The > point is that in openEHR, the archetype definitions used to record and > query one's data is very important metadata, and thus it seems to be > that an inalienable legal right, conferred by an open source-style > license, to modify and share that archetype definition is a rather > important freedom with respect to one's data - a freedom which the > openEHR Foundation, not by design or malfeasance, merely by neglect, > currently fails to grant to all potential users of openEHR archetype > definitions obtained from their site. > I don't disagree at all - but we need to be clear here. If you want to compare an openEHR repository to other systems designed in the usual way (which you were), then you should compare them on the basis of the reference models. The standard approach is a database schema that always has to change to accommodate new concepts, or drifts away from its requirements by not being changed; the openEHR schema is extremely stable. But in the end, they are both database (or XML, or...) schemas. The openEHR data is just as open to inspection and use as the classic system's data, since (we assume) you have access to both schemas. So the data are never locked in.
Archetypes and templates provide a whole other layer of functionality - which you already know something about. To get this added value, of course the archetypes must be shareable (even the current license achieves this, although probably not in the best way, as you pointed out); creating derivative archetypes is actually a case of creating modifications on copies, with a new version number (i.e. technically speaking, a new archetype). The current license would probably also cover this, although as I have already agreed, it is no doubt not particularly clear that it is the intention. So some work has to be done on the licenses (as I have already agreed...) > > > It depends what is meant by "openness", but as I point out above, > openEHR archetype definitions are metadata which do have some importance > for data stored in an openEHR-based systems, and thus the legal right to > modify and share them is an important freedom. > > Is "openness", in the sense of merely being able to view something, > the same as "freedom" in the sense it is used in FOSS? . No, and > perhaps that is why we are talking at cross-purposes. > > Perhaps it is better to have openEHR archetype definitions centrally > controlled and to prevent or limit how they can be modified and shared > around, thus forcing users to always obtain the canonical version of an > archetype definition from a central facility? I don't know (although my > instinct says "no" to such a proposition. There is not enough of an > openEHR archetype ecosystem at this stage, but the manner in which > archetype definitions are managed seems like a sociological issue which > could have a major impact on the popularity and success of the openEHR > initiative. > actually, this is the approach the UK and Australian governments seem to favour, which doesn't prevent local authoring (e.g. in a hospital). My concern is to make sure sure that nothing prevents sharing of data or archetypes (hence my interest in taking into account points of view here to do with licensing). > But I have other things to worry about right now, so good luck and best > wishes with your openEHR work, Thomas and I look forward to future > announcements of openEHR developments. > there will be quite a few in the next few weeks. - thomas
