Hi Tom Another very thoughtful document. I have been involved to some degree in the discussion of this area over the years as have many others prior to this draft release. http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/di st_dev_model.pdf
This document suggests approaches that need very careful consideration and at present I do not support the direction of this document - specifically in the changes proposed. It is important that the community consider the implications for clinical interoperability etc. This document has being released to the community prior to careful consideration by the ARB to gauge the views of implementers and clinicians. It will be difficult for many to understand the implications but I want to raise some of my concerns so people have an insight into the implications. Page 5: Current text: 1.4 Changes proposed in this document: augmented form of ARCHETYPE_ID to include organisational / package namespace, e.g. org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v1 . concept name section of archetype identifiers (middle part of ARCHETYPE_ID) now relaxed to no longer require structure based on specialisation parents, e.g. 'problem-diagnosis' can now just be 'diagnosis', or any name preferred by designers; . addition of commit_id sub-section archetype description section; . addition of id_history sub-section to description section, e.g. id_history = <"se.skl.epj::openEHR-EHR-EVALUATION.problem.v1"> This document when taken in combination with the distributed development model raise the stakes for participants. The outcome is the promise of the ability to interoperate from a knowledge artefact point of view but I have doubts whether the proposed changes will support clinical interoperability. I understand the wish of technical people to produce artefacts wherever and whenever they like (just as terminologists do) but I would propose that we have to manage complexity as well. In a world that is immensely complex already (clinical systems) we may have to sacrifice some possibilities to ensure we can perform the sort of functions people seek from a standard EHR architecture. I would like to add the requirements that are fundamental from my perspective so that the community can raise these: 1. Primacy of openEHR: I would propose that we need a hierarchy of authority. Although openEHR artefacts are presently managed within the Foundation it is possible that the governance will move to a more authoritative organisation in the near future. That said, I believe that archetypes released by the openEHR Foundation should not be identified specially (i.e. no name space). This means that openEHR becomes the default namespace for archetypes and begins to provide a hierarchy of authority that I think is so important in this space. One might argue that anyone can produce archetypes with no namespace - but really anyone can produce anything with any namespace so that is not sufficient. 2. Archetype IDs How archetypes are identified in the universe is of no great concern to me. I am happy to accept that people may want to give them arbitrary names and live with complexity from an archetype management point of view. What I am concerned about is how they are identified in data. And I do not want this to be any more complicated than is required to support the vision we have for openEHR. I am happy that we may need to extend this at some point but we have seen very successful extensions of many identifiers as systems grow (IP4->ip6, Ascii -> UTF-8). I understand the technical vision - anyone can do anything and we will be able to sort out what is going on - but I believe we have to keep pushing for things to be right for where we are up to. In data the model is known - therefore the openEHR-EHR is redundant in an EHR implementation. The namespace of the archetype is not. In data, in XML expression of openEHR data, the archetype iD Class name and concept part provide a means of returning the data without knowledge of the archetype. An openEHR repository can be fully implemented, use AQL etc without any knowledge of archetypes whatsoever. The reason for this is that the archetype Ids are used in queries, and specialisations can be found without reference to any archetypes based on the ID. This is a fundamental benefit for implementers and losing this will require a considerably more complex engine with, potentially, access to every archetype ID in the world. This is not useful. So my fundamental requirement is, in openEHR systems, to be able to query for specialisations without the need to go to an archetype knowledgebase (which will by definition be incomplete). Page 17: Current text: As a general principle, for a given archetype used to create data (e.g. an openEHR OBSERVATION object), the following archetypes could be used for querying: . the same archetype, i.e. Exact same version, revision & commit; . any previous revision of the same archetype; . any of the specialisation parents of the archetype; . any previous revision of any of the specialisation parents of the archetype. Comment: I would add a specialisation of this archetype to the list. It will be easy to determine in the query space whether the nodes sought are shared with parents and whether a query on the parent is iso-semantic, overlaps (to what extent) or is unique to the specialisation. Current text: To address this situation, it may be useful to include the configuration meta-data from the operational template(s) with the data when it is transferred outside of its normal environment, e.g. in an EHR Extract. Comment: Tom raises the issue of no longer being able to query on specialisations. This is one suggestion which I do not think appropriate as it creates massive complexity and allows huge holes for errors in automatic processing. He goes on to the other alternative: Current text: The other possibility is to include archetype lineage information in the data itself..... The simplest form of this would be as a list of operational identifiers, e.g. se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12, org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29, org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4 ... The above example could then become: se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12, org.openehr.ehr::~diagnosis.v1.29,~problem.v2.4 Comment: This is a large overhead for the query engine and the data but it is in essence what we have at the moment in the form of: openEHR-EHR-EVALUATION.problem-diagnosis-genetic_diagnosis.v1 We have obvious problems with our current approach in that there can be only one version of the specialisation. This has to be overcome. Within the data we know some things - which class, which reference model. If we accept the authority of openEHR we can accept a default namespace (as in current systems). We can then see that we could reduce Tom's in data string to: EVALUATION.problem.v2.4,diagnosis.v1.29,se.skl.epj::genetic_diagnosis.v1.12 Lets consider the revision information. If versions are entirely backwardly compatible, is it helpful to have the revision in the data? An optional element may or may not exist. If I have an old archetype (or the one that I use in my system) I can still use it to query data entered against future revisions. I think we need to consider carefully the revision information and whether it should be in the data. If we go in that direction the id becomes: Evaluation.problem.v2,diagnosis.v1,se.skl.epj::genetic_diagnosis.v1 Not so far away from: openEHR-EHR-EVALUATION.problem-diagnosis-genetic_diagnosis.v1 It may be better to take the syntax to: EVALUATION.problem.v2-diagnosis.v1-se.skl::genetic_diagnosis.v1 as this would be more backwardly compatible. In summary, I would like this to proceed in a manner that fits the clinical and technical vision. Is it a hierarchy of authorities for artefacts or not. Do we stay backwardly compatible with current implementation processes or not? I think you can understand where I am coming from. By accepting a hierarchy of authority it does mean that we have a lot less complexity. Namespaces in the longer term would be for specialisations and I would argue would probably be unique for a country in the foreseeable future. If another country wanted to use archetypes developed within a different country, I would argue that this specialisation should be promoted to the international set. I look forward to your responses. 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
