There is some ambiguity in the documents on archetype lifecycle (cf EHR content lifecycle, which is defined by the common.change_control and the mentioned terminology - see http://www.openehr.org/uml/Browsable/_9_0_76d0249_1109326589721_134411_997Report.html). Archetype lifecycle is in fact defined by the lifecycle_state attribute inherited from the class Authored_resource - see http://www.openehr.org/uml/Browsable/_9_0_76d0249_1108467924943_474004_589Report.html and http://www.openehr.org/uml/Browsable/_9_5_1_76d0249_1140013971401_826330_4871Report.html
This lifecycle state at the moment is defined as a string value within Resource_description (so it can have translations). This is probably the wrong model, and I would advocate a coded feature in Authored_resource itself (in the same way as there is a coded feature in the Version class). [For those wondering why such a model was chosen in the first place, I believe it was to mimic either CEN knowledge meta-data or HL7 template semantics]. The archetype System document definitely has to be updated to reflect whatever we do here. - thomas beale Mattias Forss wrote: > Hi David, > > The lifecycle field is optional in the archetype identifier, see > http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/archetype_system.pdf > > <http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/archetype_system.pdf>. > > However, this document is under re-development so I don't know more > about the identifier than what's in the document. Another thing worth > mentioning is that the Support terminology document is not in line > with Ocean's editor and that is why they have more life cycle states > than specified. This probably depends on shortage of specified states, > so I guess Ocean just added a couple of their own. The computable > Support Terminology in XML format should be updated to follow the > specifications... > > Regards, > > Mattias > > 2006/6/16, David Moner <damoca at gmail.com <mailto:damoca at gmail.com>>: > > Hello everybody, > > I have a question about the archetype lifecycle state. This may > not be a fundamental question, but it is important to formalize > all the aspects regarding to an archetype system. This is what I > have found about this topic reading through all the documentation. > > First, at the ADL2 document, the section related to the Archetype > Identifier references to the Archetype System document. There we > can find a clear description of the Multiaxial Archetype > Identifier. Well, clear except the life_cycle field. Reading the > provided examples we get two possible values: > * draft > * in_test > > Looking for a more formal definition I read the Version Lifecycle > State section at the Support Terminology document. Although it > seems that is referred to another question (the revision of an > archetype item), it is the only mention to the lifecycle in the > entire document. This is what appears there. > * complete: Item is complete at time of committal. > * incomplete: Item is incomplete at time of committal, in the view > of the author. Further editing or review needed before its status > is set to "finished". > * deleted: Item has been logically deleted. > * draft: DEPRECATED. > * active: DEPRECATED. > * inactive: DEPRECATED. > * awaiting approval: DEPRECATED. > > Finally, for my surprise, it is the case of the Ocean Archetype > Editor (Version 0.99.5c Alpha). We can define with it something > called "Authorship lifecycle" with these possible values: > * Not set(en) > * Initial(en) > * Author draft(en) > * Author draft(en) > * Committee draft(en) > * Organisation draft(en) > * Submitted(en) > * Candidate(en) > * Approved candidate(en) > * Published(en) > * Rejected(en) > * Obsolete(en) > > Furthermore, these values are recorded at the > description.lifecycle_state field of the ADL but make no change at > the archetype identifier (maybe a bug?). > > This is the situation that I have found when studying in depth > such a simple thing as the lifecycle state of an archetype. As I > said at the beginning, this may not seem a fundamental problem at > this stage of development, but it should be revised in order to > get a more coherent archetype system and really useful archetype > repositories (to assure that the archetype that they contain are > reliable). > > This takes me to a more interesting question. Is it defined any > policy for archetype management related to their lifecycle state? > I haven't found anything about this topic. For example, this could > be a very simple policy. > > * initial: The archetype is still in an embryonic stage. It makes > no sense to validate it because its definition is not finished. > > * draft: Syntactically correct (from a direct ADL editing point of > view or just with all the definition tree finished), but not > semantically correct according to the reference model or its > parent archetype (that is, the archetype doesn't respect the > reference model or parent archetype constraints). It may also lack > of terminology bindings. > > * test: Syntactically and semantically correct in the terms stated > before. State for testing whether the EHR extracts based on it are > what we want or need. In other words, at this state we are testing > if the archetype fulfils the clinical concept that it is being > defined. > > * final: Only an archetype in its final state should be stored at > a public archetype repository. It is a valid archetype approved by > a commission of experts and its ready to be used by any institution. > > > This would be an interesting point for a deeper study. > > > -- > David Moner Cano > ITACA - BET - Grupo de Inform?tica Biom?dica > http://gim.upv.es > > Universidad Polit?cnica de Valencia (UPV) > Camino de Vera, s/n, Edificio G-8, Acceso 3, 3? planta > Valencia ? 46022 (Espa?a) > > -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org)
