> > An ideal scenario would be to have a record of the archetypes someone is > using, and when a new revision is published, run the diff between that and > the revision the implementer is using, and notify of possible > incompatibilities, that way we can know exactly what's wrong and fix > accordingly.
User can have an option to maintain this list in their CKM account and use it for comparison regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Tue, May 28, 2019 at 11:27 AM Pablo Pazos <pablo.pa...@cabolabs.com> wrote: > Adding to what was commented, there is a gap between implementers and the > CKM/modeling process. > > + implementers will use any archetype, even drafts, that are published on > the CKM, because those might match the requirements, so for that > implementer the archetype might be OK. > + implementers can't approve archetypes to move from draft to published, > can make suggestions to improve them, but not change their status. > + the modeling process allows those draft archetypes to change anytime in > any way, generating potential incompatibilities with the revisions > downloaded by implementers, and that can only be checked manually, by each > implementer, for each modified archetype. I did this and could take a whole > day to review an archetype and analyze incompatibilities. > + for implementers is difficult to track archetypes they (we) are using, > to see when an archetype that we use changes and compare to find potential > incompatibilities. Current tools allow to follow an archetype and be > notified by email when changes are done, and the CKM has a compare tool, > but is all a manual process. An ideal scenario would be to have a record of > the archetypes someone is using, and when a new revision is published, run > the diff between that and the revision the implementer is using, and notify > of possible incompatibilities, that way we can know exactly what's wrong > and fix accordingly. > > Another point is that AFAIK current clinical modelers are voluntary, which > I think the Foundation should consider funding to have more archetypes > reviewed and published, than having most in draft. There is some money on > the Foundation, let's use it to help the community, and also give something > back to our core clinical modelers. We need a dedicated team for these > things. > > On Tue, May 28, 2019 at 2:11 AM Dileep V S <dil...@healthelife.in> wrote: > >> Hi, >> >> Thank you for all the responses. It has helped me clear a couple of of >> things that need to be keep in mind while using resources from OpenEHR CKM. >> Just to summarize, >> >> 1. Archetypes in v0 are to be treated as initial suggestions and can >> change anytime and without any pattern. Published ones from v1 are more >> stable and the changes managed better. >> 2. Using V0 is at one's own risk and so keeping a local copy would be >> advisable >> 3. CKM allows viewing and comparing version history using archetype >> history >> >> The above raises some additional questions >> >> 1. What are the specific steps/links to download older version of >> archetypes from the CKM. The archetype history allows comparison between >> versions. But I could not find any link to view/download older versions. >> 2. Majority of the archetypes in CKM are unpublished v0 versions. So >> it is difficult to build any meaningful CDR currently using only published >> archetypes. What will be the best strategy to keep moving forward with >> creating real solutions while keeping the spirit of OpenEHR relevant. >> 3. Managing copies of the archetypes that are used separately by >> different users is bound to create fragmented schema across openEHR >> compliant CDRs, thereby defeating the fundamental premise of interoperable >> schema among OpenEHR CDRs. >> >> regards >> Dileep V S >> *Founder* >> HealtheLife Ventures LLP >> m: +91 9632888113 >> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 >> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com >> <http://ayushehr.com> e: dil...@healthelife.in >> >> >> On Tue, May 28, 2019 at 2:15 AM Sebastian Garde < >> sebastian.ga...@oceaninformatics.com> wrote: >> >>> Hi >>> >>> >>> >>> The v1 to v0 migration was a once off thing that was decided to be the >>> best for never before published archetypes. >>> >>> I’ve never been a big fan of v0 because of the all the complications it >>> has, but at least it tells you clearly that all bets are off regarding this >>> archetype because it is under development and anything goes, including >>> changes to its archetype id, if required. >>> >>> V0 is also consistent with SemVer (although you could do it differently >>> as well, e.g. 1.0.0-alpha). >>> >>> After publication to v1, the governance is more formal and follows >>> semantic versioning of patch, minor and major versions. >>> >>> >>> >>> It may not always be nice, but unless someone can provide a >>> comprehensive, clean and perfect set of archetypes, that’s what life will >>> be for a while. CKM aims to support the processes around the development, >>> review and publication of the archetypes etc. as much as possible. >>> >>> In CKM, the revision history of an archetype links back to any previous >>> (or next) major version of the archetype. See e.g. the Blood pressure v2 >>> archetype. You can get any (trunk) revision of the archetype that was ever >>> uploaded to CKM from there and compare any two revisions. Archetypes that >>> were updated in the last couple of years will have the SemVer version in it >>> as well, and there is always the canonical hash (the one used in the >>> template) you can use to determine the right version of the archetype if >>> required. >>> >>> >>> >>> I hope this answer your questions below and provides a bit of context in >>> between. >>> >>> >>> >>> Regards, >>> >>> Sebastian >>> >>> >>> >>> *From:* openEHR-clinical <openehr-clinical-boun...@lists.openehr.org> *On >>> Behalf Of *Pablo Pazos >>> *Sent:* Montag, 27. Mai 2019 20:37 >>> *To:* For openEHR clinical discussions < >>> openehr-clinical@lists.openehr.org> >>> *Subject:* Re: Downloading previous versions of archetypes from CKM >>> >>> >>> >>> You might also have problems with some archetypes that went from .v1 to >>> .v0 >>> >>> >>> >>> In the archetype history you can see the previous versions, but some >>> will have a broken history, for instance some archetypes changed name and >>> archetype id but serve the same purpose as the old archetypes, which broke >>> any implementation of the previous archetype. Also there is no clear >>> history of archetypes changing ID or merging archetypes. >>> >>> >>> >>> Because of those issues is difficult to trust what is on the CKM in the >>> long term. I decided to work with older archetypes to keep my baseline >>> clean and stable, do modifications on those if required, and create our own >>> archetypes when required. >>> >>> >>> >>> I'm not sure if this is because how the CKM manages archetypes, or >>> because the modeling process have flaws in the version management. >>> >>> >>> >>> On Mon, May 27, 2019 at 5:01 AM Dileep V S <dil...@healthelife.in> >>> wrote: >>> >>> Hi, >>> >>> I had used some archetypes from CKM in my templates some time back. Now >>> when I am revising & reviewing them I notice that some of the archetypes >>> have newer versions an so my templates give error as they are unable to >>> locate the older versions that they use. So I have a few questions on the >>> best practices for using CMK resources >>> >>> 1. Can I access older versions of archetypes from CKM? and how? >>> 2. Should I maintain a copy of the archetype versions that are used >>> in my templates separately? >>> 3. Are archetype versions incremental improvements? If yes should >>> the AQL not support multiple versions to maintain backward compatibility >>> as >>> the templates evolve? >>> >>> regards >>> >>> Dileep V S >>> >>> *Founder* >>> >>> *HealtheLife Ventures LLP* >>> >>> m: >>> >>> +91 9632888113 >>> >>> a: >>> >>> 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 >>> >>> w: >>> >>> ehr.network, <http://ehr.network>ayushehr.com e: dil...@healthelife.in >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>> >>> >>> >>> -- >>> >>> *Ing. Pablo Pazos Gutiérrez* >>> pablo.pa...@cabolabs.com >>> +598 99 043 145 >>> skype: cabolabs >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> >>> <https://cabolabs.com/> >>> http://www.cabolabs.com >>> https://cloudehrserver.com >>> >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > > > -- > *Ing. Pablo Pazos Gutiérrez* > pablo.pa...@cabolabs.com > +598 99 043 145 > skype: cabolabs > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > <https://cabolabs.com/> > http://www.cabolabs.com > https://cloudehrserver.com > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
