The two-level modelling approach addresses a fundamental concern of information system building: the separation of concerns between knowledge representation (ontologies) and information processing. Archetypes are used to formally represent knowledge structures in machine processable form as applied to electronic health records. CEN is not an openEHR standard and thus it is not "cementing" it into a standard. What it does however is quite important: it defines an achievable target that can be implemented on local, regional, international scale, etc. with the support of the infrastructure and governance needed in all those cases. CEN standardisation, while taking into account company offerings is not constrained to existing technology and can transcend proprietary limitations. If industry-based efforts could produce a similar standard, they would have done it a long time ago. But as it turns out, industry is not particularly good at defining semantic interoperability. openEHR is an evolving target that conforms to the well-known open/closed principle of object-oriented programming: an architecture should be sufficiently complete (closed) in order to produce working systems today but it should also be open to future development. I am not sure CEN standards achieve this level of flexibility but it is built into the fabric of openEHR which produced the first complete set of implementable specifications about a year ago. Then it received feedback from multiple projects that implement it in the applications space. Thus at the end of this cycle, the openEHR specifications will be a lot better. This iterative mechanism will continue working beyond release 1.0.1 but with the added benefit of stability. The beauty of archetypes is that they transfer the control over clinical modelling to the clinician. No standard can decree in advance what real practice needs. The distributed nature of clinical knowledge in society is supported by an archetype infrastructure that will evolve over time and for this to happen we don't need to know all the answers in advance. In any business information system one needs to have the ability to write business rules and constraints on the business objects that system is dealing with. The archetype definition language is a formalism specifically design to produce models of concepts that pertain to the clinical domain. How this formalism will be used depends on the clinical practitioners.
Ogi Pishev Ocean Informatics P.S. I am puzzled as to when the author of the blog has discovered that the work that has been going on for 7-8 years is "archetypically stupid!" As usual in the case of such categorical statements one wants to find out what the alternatives are and what that authors proposes as a working solution to the issue of semantically interoperable shared record. Quoting Tim Churches <tchur at optushome.com.au>: > Andrew Patterson wrote: > > Does anyone want to respond to this? > > > > http://aushealthit.blogspot.com/2007/01/archetypically-stupid.html > > > > David More seems to be going on a bit of a crusade at the moment, > > firing shots at all current work in Australian e-health (NEHTA etc). > > Some of it is deserved no doubt, but I think he is a bit confused > > about exactly what the archetype approach is about. > > I agree that David does not have some of the technical details about > openEHR archetypes quite right (note that the qualifier "openEHR" is > necessary as there are many other uses of the term "archetypes" out > there in information management land, some of which predate openEHR/GEHR > work and many which are more widely known), although the fact that a > smart person like David with plenty of time on his hands hasn't grasped > everything about archetypes underlines the fact that they are presented > in a rather complex and mystifying manner to someone encountering them > for the first time. Not sure how to make it less complex (a really good > professional technical writer might be able to help, but they cost a lot > to hire) - nevertheless, perceived complexity is the enemy of > widespread acceptance, I suspect. > > However, I basically agree with David's main tenets that it is premature > to be pushing for finalised openEHR standards when there are so few > deployed examples of true openEHR systems in production (not research) > use out there, and when formal (or even informal) documented evaluations > of such systems (even of research systems) are so thin on the ground. > Pilot openEHR implementations funded by the Australian government may or > may not have been formally evaluated, but if they have, the reports have > not been published to my knowledge. A Medline/PubMed search for > independent peer-reviewed (i.e. not written by Ocean Informatics or UCL > staff) evaluations, even anecdotal mentions, of any aspect of openEHR > informations systems yields, well, exactly zero papers, when I last > looked a few months ago. Have I overlooked something? > > I suppose what I am saying is that elsewhere in medicine and health > care, standards tend to be evidence-based i.e. before a new treatment > method or protocol is promulgated as a standard approach, there needs to > be a reasonable (not necessarily extensive) set of formal evaluations of > that method or technique using scientific methods (typically statistical > or epidemiological methods in clinical trials or observational studies > for clinical medicine, but that may not be appropriate for evaluation of > all aspects of information management systems or methods). That evidence > base seems to be lacking for openEHR archetypes. One could say that it > is also lacking for other health information management approaches and > techniques, and where these are the subject of final standards, I would > level exactly the same criticism at them. > > I know that the openEHR/Ocean Informatics/UCL people, and perhaps some > other research groups, believe fervently in the adequacy and > practicality of the openEHR approach, but modern health care has just > about dispensed with fervent belief. Formal studies in peer-reviewed > journals are needed - and yes, those takes time - perhaps a large part > of a decade. But the openEHR project has been going form a decade or so > now, and the GEHR project for nearly a decade prior to that. What's a > few more years? > > I also agree with David that openEHR archetypes will only be a solution > (as opposed to yet another complicated headache, like HL7 already is) if > an adequate national or global "intellectual ecosystem" can be > established for the definition, sharing and evolution of openEHR > archetype and template definitions. David comes from the "centralist > control freak" era - I'm an open source person and so am not quite so > worried about the ability to impose openEHR Stalinism. However, some > form of co-ordination and sharing mechanisms are needed, and these do > not happen by accident - they need to be carefully grown and nurtured > and even then they may not be sustainable. Certainly, the business model > for openEHR repositories is unclear, as it is not in the interest of the > large health system providers (including the likes of Microsoft and IBM) > to promote such things as true openEHR-mediated interoperability will > mean than vendor lock-in will be undermined. Governments should fund > such repositories, but will they? Also there are, to my mind, unresolved > and rather critical issue with teh way in which openEHR archetypes are > licensed. I have raised these concerns repeatedly with the openEHR > developers but am happy to share them on this list if anyone is > interested. perhaps I am needlessly concerned but I think not. Or have I > posted these concerns to this list already? > > So, my view is: all power and godspeed to the openEHR project, but too > soon to be cementing openEHR stuff into final standards. Not too soon > for openEHR standards proposals, that will go through dozens of > revisions over the next decade, but definitely too soon to be pushing > through final standards for something which for the majority of health > professionals and health informatics people is largely unproven in a > documented fashion and/or through first-hand experience. > > Tim C > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
