Hi Tom, This is a good document - thanks. I have posted this to the clinical list as well. http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/di st_dev_model.pdf
My comments: Page 11: Current text: Archetypes based on different classes from the same information model to have the same name, e.g. An archetype for 'vital signs' headings based on the SECTION class, and a 'vital signs' archetype based on OBSERVATION. Comment: I believe there will be archetypes for sections and entry that have the same name but this is not a good example. The entries for vital signs are BP, Pulse etc. I think it would be better to just raise the problem or get an example. The nearest one I can think of is a plural form - e.g: Problems (Section) and Problem (Entry). Page 16: Current text: Also in common with software, there is a strong interest among archetype and template users in one or a few high-level shared libraries of high-quality artefacts rather than scattered development with poor quality control. In an ideal world, there might be only a single repository, or a purely hierarchical set of repositories. However, we know from experience with software development that this is extremely unlikely. Each organisation initially starts out with its own point of view, timelines and priorities. If a coherent ecosystem of cooperating repositories, or a single international repository were ever to exist, it would be as an emergent result of collaboration among initially separate authoring groups, rather than being established at the outset. Comment: With my software hat on I concur with your sentiment. The reality is that it is likely to be the clinical colleges and other stakeholders outside the software domain that produce the authoritative archetypes that are sought after. I have no doubt that there will be both entropic and negentropic forces. I believe that the lowest energy state is so profoundly associated with collaborative work in this area that we are unlikely to see many competing efforts. This is for many reasons including: * There are many choices involved in developing archetypes - each has implications for other archetypes that have to be developed and maintained, translated etc * Clinicians are interested in alignment of recording around best practice and providing suitable flexibility - this is best done within one or a very small number of archetypes for a given clinical concept * Interoperability will be maximised with collaboration around the development of archetypes and vendors will have a much smaller footprint to manage * The cost of creating competing sets of archetypes is massive and probably not sustainable * The number of clinicians and technical people in a position to contribute is not high considering the work required * Structuring clinical information is more fractal than orthogonal in nature. Consensus provides a means of getting to grips with the issues and managing complexity In essence I am counselling everyone to see the centralised hierarchy of repositories as infinitely more useful than the software model of go and do, try, build and lets sort the differences in the future. I guess I am proposing that archetypes are a lot closer to terminology than software from a clinical perspective. Current text: Other national and institutional repositories are likely to come online from 2009 onward. This trend appears to be similar to the emergence of large-scale open source projects. The collaborative nature is similar. I hope that the national repositories will be used more to organise comments and development of archetypes for the collective effort in these early days than starting out on their own. In the end I hope the national repositories will be where the releases of largely international artefacts (with local specialisations) will be managed. Some archetypes for national or local use will also be developed but these will be edge cases. I guess I would see archetypes as the operating system of clinical interoperability if I were to use the technical analogy. Current text: Based on the above considerations, the 'modern' model of software development is assumed to provide a suitable paradigm for openEHR knowledge artefact development, with emphasis on collaborative development of one or a small number of well-known artefact repositories. I therefore do not agree with this statement. It may appear realistic but I do not think it is sustainable nor to be encouraged. I am interested in what other people think. It is really an important consideration. Terminology also could be organised primarily by country (or even regionally) and then at the core when people agree on things. If the clinical leaders in the openEHR community agree with me that we should really work with the centralised model it does not greatly influence the technical issues in this paper but it does mean we can work with the assumption that everyone will see a central authoritative source and then a hierarchy of repositories rather than a flat set of repositories competing for dominance. Cheers, Sam > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Thomas Beale > Sent: Friday, 5 June 2009 10:28 AM > To: Openehr-Technical > Subject: distributed development, governance and artefact > identification for openEHR > > > I have completed drafts of two documents I believe will come to be > important in openEHR in the near future. The first describes a model of > distributed development and governance of knowledge artefacts, > including > archetypes and templates. The second defines an identification system > for these artefacts. The first document is a rewrite of a document > called the 'Archetype System' from previous releases of openEHR, the > second is new. A detailed description of a governance structure and > also > quality assurance will come in later documents, but key aspects of both > subjects are summarised in the first of the above-mentioned documents. > > These are both development phase documents and are available for > community review at > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/ > am/dist_dev_model.pdf > and > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/ > am/knowledge_id_system.pdf > > A wiki page is available at > http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+ > Knowledge+Artefacts > for discussion purposes. > > All feedback welcome. > > - thomas beale > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
