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 On 8 January 2013 17:36, William Goossen <wgoossen at results4care.nl> wrote: > 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 > > -----Original Message----- > From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] > On Behalf Of openehr-clinical-request at lists.openehr.org > Sent: dinsdag 8 januari 2013 17:57 > To: openehr-clinical at lists.openehr.org > Subject: openEHR-clinical Digest, Vol 11, Issue 18 > > Send openEHR-clinical mailing list submissions to > openehr-clinical at lists.openehr.org > > To subscribe or unsubscribe via the World Wide Web, visit > > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > or, via email, send a message with subject or body 'help' to > openehr-clinical-request at lists.openehr.org > > You can reach the person managing the list at > openehr-clinical-owner at lists.openehr.org > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of openEHR-clinical digest..." > > > Today's Topics: > > 1. Re: openEHR-clinical Digest, Vol 11, Issue 3 (Bert Verhees) > 2. Re: openEHR-clinical Digest, Vol 11, Issue 3 (Stefan Sauermann) > 3. Re: openEHR-clinical Digest, Vol 11, Issue 3 (Ian McNicoll) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 08 Jan 2013 08:48:16 +0100 > From: Bert Verhees <bert.verhees at rosa.nl> > To: openehr-clinical at lists.openehr.org > Subject: Re: openEHR-clinical Digest, Vol 11, Issue 3 > Message-ID: <50EBCF40.4070403 at rosa.nl> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > On 01/08/2013 08:05 AM, Sam Heard wrote: > > > > The publication status is a complex thing as well. Stand alone > > publication of an archetype is one thing, but most important is being > > part of a release set for a particular jurisdiction. Clearly all > > archetypes in a release set will be published. But the same archetype > > can be published over and over with more translations, additional > > features etc, all the while being backwardly compatible. > > > Because I partially initiated this discussion, I want to summarize my view > on it again, but I did not think it over very well. I am too busy with > other > things to follow these discussions. I am sorry for that. > So regard it is as my two cents while make a good and wise decision about > how it will be. > > My idea is to furnish archetypes with more MD5 keys, one for the > definition, > and one for each language-section in the ontology. > > Now a locatable stores the ArchetypeDetails to indicate which archetype is > used, then ArchetypeDetails should store these keys. It is of course the > responsibility of a system-owner to save the archetypes belonging to a > specific keys. > > Backwards-compatibility can not be defined in keys, if that needs to be > defined, there must be a metadata-section for that. > > Regarding to the archetypeID, the term "ID" suggest that it can be used to > identify something. If one wants to use the term ID, it must contain > information to identify the archetype, in that case, it should contain a > key, MD5 f.e., which is verifiable and uniquely connected with that > archetype. > > The information (RM-model, domain, concept, etc) that is now hidden in the > archetype-ID must be provided in metadata-sections, so that the ID will not > be longer need to contain any necessary information. I think the ID will be > superfluous. It should not be part of the ArchetypeDetails. > > The archetypeID will not be needed anymore in the information-structure, > users are free to assign any name to an archetype. > And we also need a humanly expressable name for an archetype, for that > purpose, a name-design can be provided, as long as it is clear that the > name > does not verifiable and uniquely identifies an archetype. > > I don't think we need to worry about MD5 weaknesses, because archetypes > need > so many other characteristics that it will be very hard to find a collision > which is also a valid archetype. > > Bert > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attac > hments/20130108/25c509a4/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Tue, 08 Jan 2013 14:08:09 +0100 > From: Stefan Sauermann <sauermann at technikum-wien.at> > To: For openEHR clinical discussions > <openehr-clinical at lists.openehr.org> > Subject: Re: openEHR-clinical Digest, Vol 11, Issue 3 > Message-ID: <50EC1A39.4050800 at technikum-wien.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > I think distributed governance is the only realistic possibility. > Fully agree. > > Greetings from Vienna, > > Stefan Sauermann > > Program Director > Biomedical Engineering Sciences (Master) > > University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 > Vienna, Austria > P: +43 1 333 40 77 - 988 > M: +43 664 6192555 > E: stefan.sauermann at technikum-wien.at > > I: www.technikum-wien.at/mbe > I: www.technikum-wien.at/ibmt > I: www.healthy-interoperability.at > > > On 07.01.2013 19:21, Thomas Beale wrote: > > I think distributed governance is the only realistic possibility. > > > > ------------------------------ > > Message: 3 > Date: Tue, 8 Jan 2013 16:55:57 +0000 > From: Ian McNicoll <Ian.McNicoll at oceaninformatics.com> > To: For openEHR clinical discussions > <openehr-clinical at lists.openehr.org> > Subject: Re: openEHR-clinical Digest, Vol 11, Issue 3 > Message-ID: > <CAG-n1KwTSqx4NoGQL77qvA3_=+ > HZGgKRSwDnuZYF3OZkADX21Q at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Bert, > > Whilst I understand and agree with the need for very precise identification > of a particular archetype via MD5 or some other 'meaningless > identifier/locator', it is also necessary to clearly identify the version, > revision and build of an archetype for authoring and governance purposes, > as > well as in early stages of development and testing. > > During the authoring phase, where archetypes and templates can be very > fluid, and have multiple dependencies, our experience has been that MD5 > hashing is very difficult to manage since it forces very strict > dependencies, where in practice we perhaps only want to ensure that the > archetype Version is correct, and temporarily ignore Revision changes or > minor 'Build' changes, until publication/deployment. In terms of regular > software development, imagine the consequences if all of your source code > files were MD5 hashed, and each dependency MD5 tagged, resulting in a > compile failure if there is a mismatch between the dependent files. > > I am not convinced that abandoning the existing archetypeID mechanism is > the > right approach but even if it were I think we would still need to support > it > for legacy purposes. Let's also leave aside the OID vs ReverseURI issue for > now (there is a possible case for supporting both). > > As I said in a previous post, I am working on some proposals I am working > on, based on earlier discussions, Thomas's wiki material, the suggestions > for Semantic Versioning at semver.org and experience from both CKM and > non-CKM repository governance. > > The suggestion will be to introduce an extendedArchtypeID, composed of ... > > OriginalDomain: The originating Domain namespace where the archetype was > first governed e.g. org.openehr but could be an OID. This never changes > even > when the archetype is transferred to a different repository. > > ArchetypeID: The current archetypeID (including Version) e.g. > openEHR-EHR-OBSERVATION.blood_pressure.v1 > > RevisionNumber: The revision number e.g '2' starting from base 0 with each > new Version > > NonOperationalModifier: A state suffix e.g. (initial, draft, rc, > inactive). > > BuildID: This is repository-defined. In the case of CKM it might be the > 'citeable-ID' e.g. 1031.1.1296_2 but it could equally be an MD5 Hash for a > non-CKM repository. The only stipulation is that any archetype made visible > by the repository must increment the BuildID, whenever ANY change is made > to > the archetype. > > > So the full ID for a published archetype might look something like > > org.openEHR::openEHR-EHR-OBSERVATION.blood_pressure.v1.0+build1031.1.1296_2 > > or for the same archetype taken back into review > > > org.openEHR::openEHR-EHR-OBSERVATION.blood_pressure.v1.1-draft+build1031.1.1 > 296_7 > > The nomenclature is closely based on semver.org with some modifications > > The metadata should also carry : > > AuthoringLifeCyle: (Initial, Draft, Team Review, Suspended Review, > Published, Rejected, Superseded, Moved). This is effectively a superset of > the operational states to account for authoring and governance requirements > which do not affect the operational status of the archetype. i.e an > archetype which moves from Draft to Team Review and then Review Suspended, > remains a 'beta' archetype from an operational perspective.There is a > direct > mapping between the operational states and one or more Author lifecycle > states. > > CurrentDomain: identifier for the current controlling domain, to allow for > situations where control/governance of the archetype is transferred. > > We can probably carry all of the necessary extra metadata within the > current > ADL1.4 specification under other_details. > > In general I would expect archetypes and templates to refer to dependent > archetypes or templates using the full extended identifier, but associated > tools could choose to ignore e.g build or even revision incompatibilities > where appropriate, and update the references automatically to point to the > currently used artifacts, if modelling is still at a stage where loose > coupling is necessary. > > In terms of the original discussion, I think my main concern is that not > that the state of understanding of how DCMs/archetypes should be > managed.governed and versioned is still very much in the early phases of > understanding, particularly in the very distributed governance environment > that I think we all agree will be required. openEHR archetypes (? also FHIR > resources) are a bit of a special case since we expect these to form the > basis of persisted, queryable data, not just as messaging definitions. This > makes the challenge of versioning / governance rules much harder but I > think > we are pretty close to having an implementable solution. > > More soon ... and would be interested in others thoughts about the BuildID, > particularly in the context of Git or Subversion-based repositories. > > Ian > > > > > > > > > > On 8 January 2013 07:48, Bert Verhees <bert.verhees at rosa.nl> wrote: > > > On 01/08/2013 08:05 AM, Sam Heard wrote: > > > > The publication status is a complex thing as well. Stand alone > > publication of an archetype is one thing, but most important is being > > part of a release set for a particular jurisdiction. Clearly all > > archetypes in a release set will be published. But the same archetype > > can be published over and over with more translations, additional > > features etc, all the while being backwardly compatible.**** > > > > **** > > > > Because I partially initiated this discussion, I want to summarize my > > view on it again, but I did not think it over very well. I am too busy > > with other things to follow these discussions. I am sorry for that. > > So regard it is as my two cents while make a good and wise decision > > about how it will be. > > > > My idea is to furnish archetypes with more MD5 keys, one for the > > definition, and one for each language-section in the ontology. > > > > Now a locatable stores the ArchetypeDetails to indicate which > > archetype is used, then ArchetypeDetails should store these keys. It > > is of course the responsibility of a system-owner to save the > > archetypes belonging to a specific keys. > > > > Backwards-compatibility can not be defined in keys, if that needs to > > be defined, there must be a metadata-section for that. > > > > Regarding to the archetypeID, the term "ID" suggest that it can be > > used to identify something. If one wants to use the term ID, it must > > contain information to identify the archetype, in that case, it should > > contain a key, MD5 f.e., which is verifiable and uniquely connected > > with that archetype. > > > > The information (RM-model, domain, concept, etc) that is now hidden in > > the archetype-ID must be provided in metadata-sections, so that the ID > > will not be longer need to contain any necessary information. I think > > the ID will be superfluous. It should not be part of the > ArchetypeDetails. > > > > The archetypeID will not be needed anymore in the > > information-structure, users are free to assign any name to an archetype. > > And we also need a humanly expressable name for an archetype, for that > > purpose, a name-design can be provided, as long as it is clear that > > the name does not verifiable and uniquely identifies an archetype. > > > > I don't think we need to worry about MD5 weaknesses, because > > archetypes need so many other characteristics that it will be very > > hard to find a collision which is also a valid archetype. > > > > Bert > > > > _______________________________________________ > > openEHR-clinical mailing list > > openEHR-clinical at lists.openehr.org > > > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene > > hr.org > > > > > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR > Foundation www.openehr.org/knowledge Honorary Senior Research Associate, > CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care > www.phcsg.org > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attac > hments/20130108/53b167e5/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > ------------------------------ > > End of openEHR-clinical Digest, Vol 11, Issue 18 > ************************************************ > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130108/4ff7670f/attachment-0001.html>
