Tim Churches wrote: > Yes, fair enough. But the issue I was hinting at is that although the > >openEHR technological developments aim to make systems which are >"future-proof" or at least more readily upgradable to meet future needs, >that promise will only be realised if end users have the necessary >freedoms to do so, and those freedoms depend crucially on the >appropriate licensing of archetype definitions. Perhaps this is obvious, >but it had not fully dawned on me. > > well it is reasonable to bring it up. We have not talked about it previously in any great details because a) we don't have nay fantasy of private ownership of clinical archetypes and b) all the bodies and people currently talking about archetype governance have been talking in a government / public mode. But there is no getting out of the fact that legal impediments on use of archetypes (just like on say snomed or ICD10) could seriously limit the ability to achieve the collective goal of open, future-proof data and systems. We live with that all the time, and simply have to keep it in mind.
>>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). >> >> > >Yes, I would agree with that. As I have opined before, SNOMED CT concept >IDs should not be adopted as a lingua franca unless there is a perpetual >license to use it freely available to everyone (at at least a national >level). > > from our point of view, they cannot be adopted as a lingua-franca for openEHR anyway, since they are a) not all there (we have never designed a single archetype where snomed had suitable codes for all, or even most nodes) and b) to get meanings of certain words correctly related to the area of interest (e.g. perinatology, public health etc), snomed has to either find a meaning which seems to roughly fit all users' needs, or else use precoordination to separate out shades of meaning. The encapsulation effect of archetypes gets around this (just like class as encapsulations for groups of properties in an OO model). So from our point of view, snomed has to be kept at one jump away from archetypes, which is where the archetype binding semantics come in. Of course, if Australia, or even the whole world decides to "go snomed-ct" (whatever that means), we will have the ability to connect to it. It is just that we don't want to be locked into it semantically, and we want to be able to go elsewhere at the same time or later. - thomas
