On 28/04/2011 02:07, Heather Leslie wrote:
> Hi everyone,
>
> I think you are missing some of the further complexity here. There is
> a definite need for differentiation between draft and published
> archetypes for which a version number alone is not enough.
> Currently we are talking only about v1 archetypes and how to manage
> them, and to a degree it makes sense. We certainly considered using
> v0.x for drafts but it doesn't solve the downstream problems - once a
> v1 archetype is published, the non-breaking revisions will become
> v1.1, 1.2 etc. No problem
> But when we make a breaking change it becomes v2 (or v3 or v4 or 125),
> but it needs to be clear that it is v2 *draft* initially and not v2
> *published* until we have completed the neccessary collaborative reviews.
There are two ways to look at this:
* A - 'draft' is only possible at the notional v0 or first version
stage; after initial publication, it can't be used, since the
archetype is now 'in the open'
* B - it is possible to go back to 'draft' status when the major
version number is incremented on the basis that a new major
version is a new archetype, and authors need to be able to go back
into 'initial development' mode
I can see arguments for both. What we need to decide on as a community
is what rule we want here, and to stick to it. If we can decide that, we
can document it and post it in a new draft of the identification
specification
<http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf>.
Diego's problem of knowing what archetype one is actually using is real
and needs to be solved. CKM does track revision numbers, but they are
not part of the version id, and you have to go into the revision history
view to see them. However the above-mentioned identification draft spec
indicates a system of referencing to do this such that an archetype
whose id is currently shown as openEHR-EHR-EVALUATION.diagnosis.v1 would
be referenced from data and / or software (i.e. in any operational
context) as openEHR-EHR-EVALUATION.diagnosis.v1.29.0, or in the future
with a namespace as well, i.e.
org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29.0
Note that in this system of identification, if the final part of the
revision number is a '0', i.e. the '0' above in '1.29.0', it means that
the archetype is published; if it is anything else it is draft or some
other pre-release state (this corresponds with view B above). Changes in
the lifecycle state of the archetype are assumed to always cause an
increment in final number of the extended version id.
A fuller idea of referencing archetypes from from data is described in
this spec, exemplified by the following:
se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12, -- some
Swedish archetype
org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29, -- its
parent, the CKM diagnosis archetype
org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4 -- the
ultimate parent, the CKM problem archetype
here the whole specialisation lineage has been included. The reason for
doing this are a) if the archetype lineage information is not shared
between sender and receiver (maybe the receiver can't see the Swedish
CKM) and b) to enable the receiver to know what archetypes could be used
for querying the data, assuming it was not going to use the most
specialised one (e.g. the data might have been sent from Sweden to
Denmark, and the Danish system doesn't use the Swedish genetic diagnosis
archetype, but does use the other two).
Note that the version ids above only have 2 parts, because the final
part is always '0' for published archetypes (but it could be included
for better consistency).
Assuming this kind of system was used, then supporting it requires some
changes in CKM to a) make the full version + revision id visible.
Note that the 'identifiers' above are just strings. Even in a future
where Oids were used for identifying artefacts, you still need to
generate the above strings, or the equivalent, from meta-data -
essentially as composite keys (in the relational sense) so that
comparisons can be made between artefacts. (Or they might also be
obtainable from some Oid-keyed meta-data repository). In other words,
embedding such strings in data isn't making a statement about how
archetypes are identified, it is just one useful means of *referencing*
archetypes.
Finally, to be sure that the archetype you have in your environment is
indeed what you think it is, digital signing, or at least hashing, is
needed such that published archetypes are posted with their signatures
alongside for verification by accessing systems. MD5-based hashing is
already in use in some openEHR-based products, but it has not been
properly described (an initial idea is in section 8 of the
identification spec doc).
It seems that there is enough use of archetypes now to finalise many of
these issues, and describe them in a new issue of the identification
specification. We then need to work out an implementation plan, mostly
to do with changes to CKM to support the decisions.
There are two ways to go about this:
* interested parties review the identification spec, and provide
feedback
* we work out the details on the technical list + wiki via
discussion and then update the spec.
Key things that need decisions:
* do we go with starting at v0 or v1 (I still like v0 because it
implies 'you will most likely get burnt by using this archetype in
a real system, but have fun and tell us your experience')?
* can we agree on the archetype life-cycle states and the idea that
a change in state always causes an increment in minor revision number?
* how should archetypes be referenced from data?
* what system of hashing and signing should be used?
- thomas*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/6eacdbf4/attachment.html>
