[GPCG_TALK] Archetype Maintenance
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 exaggeratedbut 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
[GPCG_TALK] Archetype Maintenance
Thomas Beale wrote: Tim Churches wrote: 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. Yes, by modify I meant create new versions of archetype definitions which are owned by someone else. 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. 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. 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). Tim C
[GPCG_TALK] Archetype Maintenance
- The following is an automated response - to your message generated on behalf of rnardi at tin.it Sono in Vacanza sino al 7 Gennaio 2006. Risponder? al mio ritorno. I'm on Holiday until Jan, 07th 2006. I will answer to your message afterwards.
[GPCG_TALK] Archetype Maintenance
- The following is an automated response - to your message generated on behalf of rnardi at tin.it Sono in Vacanza sino al 7 Gennaio 2006. Risponder? al mio ritorno. I'm on Holiday until Jan, 07th 2006. I will answer to your message afterwards.
[GPCG_TALK] Archetype Maintenance
David More wrote: See short comments below. On Sun, 08 Jan 2006 20:17:31 +1100, Tim Churches wrote: 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.. No, David, I never mentioned governance in my post, and although I agree that careful governance is needed, I do think it is doable. Rather, I'm worried that people will use archetype definitions which are licensed in a way that restrict their freedom to manipulate or transfer their own data (or that of their patients) to others. 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 As I said, I agreee that management of archetype definitions is important, but I think that open source-style licensing of archetype definitions will prevent lock-in/control problems. - but the openEHR people seem to be in denial about establishing the infrastructure to do itUntil this ongoing Governance is nailed, certain and ongoing over decades this idea won't work IMVHO. We'll have to disagree - the openEHR people do seem to be thinking carefully about governance, but not in a heavy-handed way. Show me the governance of anything which is certain and nailed decades into the future - that's an unrealistic expectation. Personally I am much more concerned about the possibility of totalitarian lock-in of data and/or complete dependence on proprietary archetype definitions than I am about an anarchistic confusion of incompatible archetype definitions (although both scenarios are undesirable). Tim C ___ Gpcg_talk mailing list Gpcg_talk at ozdocit.org http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
[GPCG_TALK] Archetype Maintenance
David More wrote: See short comments below. On Sun, 08 Jan 2006 20:17:31 +1100, Tim Churches wrote: 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.. No, David, I never mentioned governance in my post, and although I agree that careful governance is needed, I do think it is doable. Rather, I'm worried that people will use archetype definitions which are licensed in a way that restrict their freedom to manipulate or transfer their own data (or that of their patients) to others. 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 As I said, I agreee that management of archetype definitions is important, but I think that open source-style licensing of archetype definitions will prevent lock-in/control problems. - but the openEHR people seem to be in denial about establishing the infrastructure to do itUntil this ongoing Governance is nailed, certain and ongoing over decades this idea won't work IMVHO. We'll have to disagree - the openEHR people do seem to be thinking carefully about governance, but not in a heavy-handed way. Show me the governance of anything which is certain and nailed decades into the future - that's an unrealistic expectation. Personally I am much more concerned about the possibility of totalitarian lock-in of data and/or complete dependence on proprietary archetype definitions than I am about an anarchistic confusion of incompatible archetype definitions (although both scenarios are undesirable). Tim C ___ Gpcg_talk mailing list Gpcg_talk at ozdocit.org http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
[GPCG_TALK] Archetype Maintenance
What XML DTD's or XML-schema's are for characters/text are Archetypes for Information. Therefore both Information and the Archetype much be stored locally. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO Quality of Life Wassenaarseweg 56 Leiden PostBox 2215 22301CE Leiden The Netherlands T: +31 71 5181388 M: +31 654 792800 On 8-jan-2006, at 10:17, Tim Churches wrote: 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/bf91731e/attachment.html
[GPCG_TALK] Archetype Maintenance
Information is exchanged in communities. All clinical information belongs to the healthcare domain. When clinical concept models (Archetypes) are expressed using an Open International Standard like the CEN/tc251 Archetypes, both the Archetype expression and the constituting clinical concept models are not owned in a commercial sense. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 8-jan-2006, at 10:17, Tim Churches wrote: 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/845bb6ed/attachment.html
[GPCG_TALK] Archetype Maintenance
- The following is an automated response - to your message generated on behalf of rnardi at tin.it Sono in Vacanza sino al 7 Gennaio 2006. Risponder? al mio ritorno. I'm on Holiday until Jan, 07th 2006. I will answer to your message afterwards.
[GPCG_TALK] Archetype Maintenance
If enough Archetypes are produced by scientific communities and associations and published IP free, then what is the problem? Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 8-jan-2006, at 21:49, Tim Churches wrote: Gerard Freriks wrote: Information is exchanged in communities. All clinical information belongs to the healthcare domain. When clinical concept models (Archetypes) are expressed using an Open International Standard like the CEN/tc251 Archetypes, both the Archetype expression and the constituting clinical concept models are not owned in a commercial sense. Certainly most of us would like that to be true. I was just wondering aloud whether it was true in a strict legal sense. I suspect that it is an issue which requires expert legal advice, and the situation may be subtely different in each country due to differences in copyright law. It just seems like a good idea to investigate such issues when adopting a new paradigm for storing and communicating data. Tim C On 8-jan-2006, at 10:17, Tim Churches wrote: 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/d4c18933/attachment.html
[GPCG_TALK] Archetype Maintenance
On Mon, 2006-01-09 at 10:16 +1100, Tim Churches wrote: Gerard Freriks gfrer at luna.nl wrote: If enough Archetypes are produced by scientific communities and associations and published IP free, then what is the problem? By IP free I assume that you mean published under a suitably permissive open source license. If that is the case, then I agree, no problem. The issue is that there needs to be strong end user awareness of this issue, and thus an insistence by end users that archetype definitions are licensed in such a way, and a refusal to use ones that aren't. Tim C I agree as I believe Tim is simply saying that it is prudent to be explicit instead of implicit regarding the legal status of the archetypes, from the very beginning. Cheers, -- Tim Cook -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/a97a5faa/attachment.asc
