distributed development, governance and artefact identification for openEHR
Tom and Sam, 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). [HKF: ] The example that exist at present is INSTRUCTION.medication, ACTION.medication and ITEM_TREE.medication. This happens for procedure as well.
distributed development, governance and artefact identification for openEHR
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
distributed development, governance and artefact identification for openEHR
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
distributed development, governance and artefact identification for openEHR
Sam Heard wrote: 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. Hi Sam, The primacy of openEHR sounds good, but wouldn't it be better to stamp the archetypes with the openEHR seal of approval? Your proposal above means that all of the home-grown local archetypes sitting on people's own computers at the moment are indistinguishable from the authoritative openEHR archetypes. I don't buy the argument that producing an archetype with no namespace is equivalent to producing an archetype with any namespace: * Archetypes with no namespace can (and will!) be produced frequently, innocently and by accident. * Producing an archetype with the openehr namespace would be a deliberate act, a conscious choice. - Peter
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
