Hi David,

The lifecycle field is optional in the archetype identifier, see
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>:
>
> 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_statefield 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060619/f3562b13/attachment.html>

Reply via email to