It is interesting to see the discussion evolve from Heather's original post
that the DCM TS 13972 was imposing impossible requirements on archetypes,
into a solution for one of the problems that moved me away from archetypes,
because I could not version them, differentiate them and ID them.
Well I think that OE archetypes can become compliant to this statement in
the ISO DCM spec. 
Great.
William
Hi William,
and Happy New Year
I think Heather’s point, which I agree with, is that whilst the emerging ideas on openEHR archetype governance/ naming/ versioning etc could be made compliant with an ISO standard, that trying define a standard at this point is premature, and that the value in doing so, may not yet outweigh the loss of flexibility to innovate and adapt while we are still feeling our way through to best practice through implementation.
Perhaps part of the problem is that by being EHR-based, openEHR archetypes present
particularly acute dependency and versioning challenges, which are less acute in a conceptual or message-based model, where backwards compatibility and controlling change is less of an issue. It has taken us some time to understand and address the complexities of controlling multiply dependent artefacts, and the consequences of use of identifiers, version numbering etc within systems and tooling.
I think we will have considerable debate about how these openEHR proposals work with non-CKM repositories and expect that there may be significant changes before they are adopted - some may be aligned to 13792, others not. I would certainly not want to arbitrarily differ from 13792 but nor would I want to be constrained by such a requirement, if the ‘standard’ does not fit what is needed by the openEHR community.
Of course there is considerable commonality between the lifecycles of DCM authoring, archetype authoring, HL7 Template authoring and SNOMED term authoring but there are some quite specific differences, some arbitrary, but some clearly necessary because of the subtly differing scope and requirements of each approach.
I do appreciate the very, considerable effort you have put into 13792 and many aspects embodied serve as helpful documentation of good, current practice, which I think we all largely aspire to, but I am unclear that setting this in terms of an ISO standard is helpful at this stage, particularly when many current eHealth standards developments have had little impact, at least in terms of the rigorous adherence that would be required to support broad interoperability.
I have no doubt that we are on a trajectory where a common, tightly aligned approach to DCM publication backed by a formal standard, will be helpful and demanded by the market. I am just not sure we are there yet.
Regards,
Ian
William, it would need to be the other way around. Think about it. If it has taken 5 years of continuous experience in archetype modelling around the world, to develop proposals for:
William,
My point was not that 13972 was imposing impossible requirements on archetypes but that a mandatory SHALL statement was possibly inappropriate for all situations and is not clear in its intent.
In openEHR we don’t use any of these statements: Not For Use (i.e. teaching); Approved for testing; Approved for Production Use. We don’t state a fitness for use, rather we express the state of the content of the model within the authoring/publication process and allow users to make their own mind up - draft, in team review, review suspended, published, reassess etc. In addition, archetypes that do not make it to publication can be rejected and those that are published can then be deprecated and replaced by another. There are other states if the archetype is not being managed within the governed space too!
And this is merely reflecting the content authoring/publication process for archetypes (which is also used for other primary assets such as templates and ref sets).
Translations and terminology binding are key attributes of the archetype specifications that also require similar indicators of maturity, independent of the content publication status. In a published archetype (ie content is stable and has successfully completed domain expert verification) the terminology binding may not be finalised and translations may have been submitted but not verified as correct. So let’s add to the mix: the authoring lifecycle states for other attributes such as terminology binding (ie draft, team review and published); identical issues for every language translation to ensure that these are verified as correct; and anticipate that we will probably find a need for transformation statuses in the future as well.
While the normative statement clearly works in your environment and maybe other simpler types of DCM environments, in the openEHR situation we have found a need to develop a formal governance process tool to manage many of the governance issues that have arisen. This is not just an archetype issue. This is the result of the complex distributed implementation environment we find ourselves in, with models being shared between different repositories as well as directly between vendors/organisations/jurisdictions; and requirements for localised variations; multiple attributes needing governance etc.
The 13972 statement I used as an example is too simplistic and too rigid to cater for the openEHR implementation environment requirements. Other DCM approaches will likely experience the same thing as they get further down the governance track. There are potentially a number of DCM attributes that could be ‘draft’ or ‘published’.
As you can see by the emails flying around, despite years teasing this out, openEHR has progressed a long way but hasn’t finalised it. We are seeking to formalise a proposal soon - Ian, Thomas and Sebastian are spearheading it at present.
We may indeed end up putting statements about various attribute’s statuses into the archetypes in the future. Or we may devise an alternative. Jury is out. Perhaps our conclusion might be a useful contribution to 13972?
So please consider loosening the normative statement and clarifying the intent, maybe supporting it with some associated informative content outlining some of the complexity that we have described.
If you choose not to, then I’m afraid it is very likely that openEHR will continue to operate as it is, non-compliant though it may be. Our goal will always be to solve practical issues for the community and progress semantic interoperability, not be compliant with a specification that is not inclusive of current knowledge and practice, even before it is published.
However our preferred position is that we would like to ensure that the learnings from the openEHR environment could be included in DTS 13972, and benefit the broader DCM community, in a mutually acceptable way.
Regards
Heather