# Archetype publication question - implications for implementers
**URL:** https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799
**Category:** Implementers (archive)
**Created:** [2 October 2015 03:55 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799 "2015-10-02T03:55:06Z")
**Posts on this page:** 14
**Page:** 3
### Author:  [@heather.leslie](https://discourse.openehr.org/u/heather.leslie)
#### Post date: [19 October 2015 12:10 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/41 "2015-10-19T12:10:08Z")
The versioning rules have been following. This is a use case that is testing them, testing our strategy. Excellent.
What does specialisation add to this? We still have a changed MD5, new archetype ID, etc… Aargh.
If we specialise, what happens when the next change comes along? Specialise the specialisation? Rinse, wash, repeat?
I don’t think this solves the broader issue that we need to accept and acknowledge - that archetypes WILL change as medicine changes, as our understanding changes and when we get things wrong! As a community of clinicians and implementers, we do need to develop strategies to minimise the flow on effects to implementers but ensure that we are heading towards high quality, correct archetypes. It is a tension that we need to balance.
There is no doubt that publication of a v2 would have had maximal impact on all implementers. We have successfully avoided that.
This v1 revision does have an impact, but I believe that we have corrected the issue while creating minimal change in the archetype. Note that most (maybe nearly all) implementers don’t use Tilt; so most won’t need to do anything to their local systems. Paths won’t change for querying etc. The query for specific units may need to be managed, but it is manageable and negotiable.
It will impact those who want to share Tilt data from different revisions of the archetype. But that was always going to be the case when anyone uses slightly different revisions of an archetype. The revision needs to be part of the info transfer and then the differences will need to be negotiated somehow.
Remember that the archetype revision number and build UID are now in the latest archetype metadata downloadable from CKM to facilitate implementers having a finer level of control over the versioning.
This may be the first time we discuss how to manage this kind of change in the list, but it won’t be the last and there will almost certainly be more with a lot more impact.
I know it will irritate some when I say that archetyping the actual clinical content that clinicians need and use in practice is often more art than science, but let me reassure you that we are ‘science-ing the hell’ out of the clinical knowledge governance process as much as we can. It is really complex, and the more we understand it, the more we realise how complex this area is.
This is our job. Implementers need strategies to align the mismatches that will occur. Publication per se is a very coarse way to manage interoperability and will not solve our problems. The alignment needs to be done at a finer level of control. This is not a new problem. It is one we are just realising as we implement and start to share – we were always going to have to have this conversation and solve this problem. It was just a matter of when.
Regards
Heather
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 October 2015 00:56 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/42 "2015-10-20T00:56:16Z")
Dear ckm lovers,
My preference is for your option 3. We have to make updates. Nobody is forced to change anything.
Best regards
Gunnar
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 October 2015 09:59 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/43 "2015-10-20T09:59:33Z")
the normal situation if these were software artefacts would be that you would recompile them all, and anything else that become invalid due to the changes in some changed archetype would then have to be changed as well; anything that still validates remains fine.
This specifically works based on the 'specialise' statement in an archetype that normally refers only to the interface ID, i.e. an id that includes only the major version.
This of course relies on the ADL2 differential representation of archetypes, and the ADL2 identification and referencing rules.
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [22 October 2015 20:53 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/44 "2015-10-22T20:53:56Z")
Hi All
I am in favour of a process that allows gentle change. The degree change (DEG) is minor and the choice of units would not have any implications for safety as they are alternatives and the numerical value would not change. I would suggest that this change is made to both archetypes (V1 and V2 draft).
I would suggest that the more considerable change be made to both archetypes as well but as an alternative, marking the location value as obsolete. You might ask all archetype users how many have any data that uses the location cluster? When and what are the implications?
I would then suggest that we have a major review of the version 2 draft and ensure it is fit for purpose in high intensity environments like ICU and anaesthesia. Are there any state variables that might be worth introducing for cardiac purposes? Is there standardisation of 24hr BP monitoring? And put out a version 2 archetype that has a long life.
The implications in systems of versioning archetypes are unknown at present but it is clearly a fundamental step. If we go through the process and no data is actually needing to be updated, then we have responded to a theoretical problem. If we go to version 2 of a very common archetype we are introducing complexity, increasing the likelihood of error and it will mean that all BP queries have to find and work with 2 different archetypes (when perhaps all data is the same!). According to the specs we will issue a transformation script (at least open source it) that updates all existing data to avoid different interpretations.
We need to use this as an opportunity for empirical learning around a step that we have planned for a long time ago.
Just my thoughts.
Cheers, Sam
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [23 October 2015 09:23 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/45 "2015-10-23T09:23:46Z")
Not sure that having two archetypes really complicates the systems. I’m pretty sure that systems are already using more than two archetypes. If they are versions of the same archetype is not different than supporting different archetypes.
If your system has dependencies on how a given archetype is defined, it is probably breaking the dual model principle IMHO
---
### Author:  [@Oystein\_Nytro](https://discourse.openehr.org/u/Oystein_Nytro)
#### Post date: [23 October 2015 13:06 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/46 "2015-10-23T13:06:54Z")
I am reviewing the rise and development of domain specific OO models. There are many...
Just a question of maintenance of OpenEHR: Versioning is fine. Forking is already happening
(cfr. ISO-standardized units or not).
Every fork is a bad thing - it requires double work, fosters arguments, diverted objectives - from a standardization point of view
Every fork is a good thing, because it increases effort spent, robustness, death-rate, and thus evolution.
OpenEHR is challenged on many fronts, since it has few constraints from other SE ecosystems:
OpenEHR has "home-grown" tools, modelling languages, archetype repositories, implementations etc. They
are all likely to fragment, both independently and with complex dependencies.
And the effort will not be shared with anyone outside the OpenEHR sphere.
How to tackle future needs of consolidation, deprecation, pruning and - possible refactoring?
Maintenance has been the bane of many FLOSS software initiatives, as well as OO domain models.
Would anyone care to comment on how OpenEHR should keep tools, models and implementations
fresh, sparkling, consistent and usable?
Please correct me if the question is wrong: In that case, what are the right questions about OpenEHR future viability?
Best regards,
--- Øystein Nytrø
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 October 2015 16:48 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/47 "2015-10-23T16:48:59Z")
HI Øystein,
OpenEHR is a specification, although there is some sourcecode, regard that as an extra service, developed by some contributors, a lot from Ocean Informatics, but also others.
But OpenEHR should be regarded as a specification, and there are more and more implementations coming worldwide.
I believe there is somewhere a business-page, with companies, and I know a few companies to with commercial success.
In the Netherlands is Code24, and most international mentioned is ThinkEHR, but there are more, mostly small companies.
I think it is a viable specification with great power regarding future use of information systems in healthcare.
If you have more specific questions, please ask, the lists are very responsive.
Best regards
Bert Verhees
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 October 2015 18:09 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/48 "2015-10-23T18:09:26Z")
As a reminder, the current [draft spec on versioning and lifecycle](http://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html)is here, and as usual, [comments are welcome](https://openehr.atlassian.net/issues/?jql=project%20%3D%20SPECPR%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC).
- thomas
---
### Author:  [@Oystein\_Nytro](https://discourse.openehr.org/u/Oystein_Nytro)
#### Post date: [26 October 2015 13:28 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/49 "2015-10-26T13:28:59Z")
I regarded OpenEHR as a specification language (environment). Not a specification by itself?
Ok, I´ll try to be more specific, using Bert Verhees' terminology of OpenEHR as a specification:
What are the governance processes and procedures related to: versioning, forking, refactoring etc for:
\* "specifications" (- no I do not belive that there will be only one, final, specification... 🙂
\* tools used to design and validate the "specification"
\* implementations based on a distinct "specification"
And since OpenEHR as "specification" was mentioned, - is it possible to control consistency
of additions and changes? Maybe inconsistency is impossible.
I may be asking for much, but governance procedures or test/validation
framework seem to be a decisive factor in ensuring a longevity of domain models.
Best regards,
--- Øystein Nytrø
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [26 October 2015 14:05 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/50 "2015-10-26T14:05:26Z")
Hi Øystein,
There seems to be a misunderstanding:
OpenEHR is a specification of a reference model and archetypes, etc, it is not software, but there is some software to download.
I was trying to be helpful, but it turns out that I was confusing instead.
I am sorry for that.
In the OpenEHR specification, there is versioning specified, this is versioning of data-entries.
I think now you are referring to that, so I explain that part. If I am wrong again, please rephrase your question.
Thanks
According tho theOpenEHR specification, entered data are for ever to keep, they cannot be changed, overwritten or deleted.
They are saved with references to audit-records (describing who entered the data, when they are entered, why ,etc)
All this is saved for ever.
But in the case when there is an error in entered data, it is possible to enter changed data .
Those changed data, however, do not overwrite the erroneous data, but create a new version of the same data-entry.
Together with new audit-data,.
So that both, the data-entry with the error, and the changed data are saved, but the changed data have the latest version-number, and are the one the system normally refers to.
How this is happening from technical point of view, is, according to my last reading of the specs, not specified.
The software-architecture must take care that previous versions, together with according audit data, can be retrieved.
There are more ways to do this.
I hope I explained it clear
Excuse again for being confusing.
Best regards
Bert Verhees
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [26 October 2015 14:16 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/51 "2015-10-26T14:16:26Z")
There is certainly forking going on; how much we don’t really know. Most needed local changes can be taken care of by specialisation and templating, which are conformant changes; I assume that this is in fact how much ‘forking’ changes are done - so this isn’t really forking in the technical sense of ‘creating an incompatible variant of something’. I can’t prove this - but if people doing clinical modelling could help report the actual nature of their changes we would have a better idea.
How will openEHR keep the tools going? I think it will be by:
- being agile - using places like Github to build and maintain them as public projects with live issue trackers
- making sure the tools solve real problems - which means communicating with users
- getting resources - if the openEHR tools solve certain problems better than some other approach, then resources will be put on to them, e.g. by companies and health authorities. There is evidence of this for the last few years, although more would be better.
I like your point about consolidation, deprecation, pruning, refactoring etc - I think that’s spot-on. The we we can specifically do this is
- to ensure that the underlying formalisms, languages and models ‘are lean and mean’ - not bloated with unneeded complexity, and
- continual review
A blackbird stays shiny by continually preening the feathers. We need to do the same 😉
Recent positive signs:
- I published a set of Antlr4 grammars on Github just over a week ago, and already people I don’t know have helped solve [a number of problems](https://github.com/openEHR/adl-antlr/issues) and provided excellent feedback.
- The openEHR/adl-designer project is also starting to receive [issue reports](https://github.com/openEHR/adl-designer/issues?utf8=%E2%9C%93&q=) and solve bugs.
- Release-1.0.3 of the Reference Model is [close to being finished](https://openehr.atlassian.net/projects/SPECRM/versions/10860)
- the archetype [industry sprint is very active](https://openehr.atlassian.net/wiki/display/healthmod/Proposed+archetypes+for+%27Industry+Sprint%27+Publication)
- more industry members have joined (will be announced soon)
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [26 October 2015 14:27 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/52 "2015-10-26T14:27:10Z")
governance procedures for the specifications are described pretty clearly [here](http://www.openehr.org/programs/specification/). The Specifications Editorial Committee is [here](http://www.openehr.org/programs/specification/editorialcommittee). We are likely to get more people onto this over time. The documenting and tracking of specifications changes over time is on Jira - see this [overview page](https://openehr.atlassian.net/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all), and look at the SPECXX and SPECPR projects.
Validation of specifications is done by some level of implementation prior to the specification being issued. For example with the [AOM / ADL specifications](http://www.openehr.org/programs/specification/releases/currentbaseline#ADL2), this is always at least done in the [ADL Workbench, and usually a lot of other tools](http://www.openehr.org/downloads/modellingtools). We are working on a consolidated project plan for all tools, that will become visible on Jira.
For specific open implementations that you see on [Github](https://github.com/openEHR), or [openEHRgen](https://code.google.com/p/open-ehr-gen-framework/), we are using typical open source meritocratic kinds of processes (undoubtedly these should be managed better).
For vendor implementations, the processes are up to those companies, but we do know that the ones that have production openEHR systems running adhere pretty well to he specifications, because various data interchange tests have been done in the past. Much more on conformance needs to be done of course, and [this is recognised](https://openehr.atlassian.net/wiki/display/oecom/openEHR+2014+Roadmap+-+Product+and+Market).
We can always do better, and critique and involvement from current and potential users is always the key.
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [29 October 2015 15:57 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/53 "2015-10-29T15:57:00Z")
Hi Øystein!
What worries me a bit more regarding forking is on the archetype level where some local and national projects have not always understood the point of contributing changes back and trying to stay aligned to global development. You can find a discussion regarding this for example in my thesis, [http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702](http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702) section 4.3 and specifically section 4.3.1 “Technical debt in archetype management”
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [29 October 2015 16:54 UTC](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799/54 "2015-10-29T16:54:29Z")
Hi Ølstein,
Great questions and good answers.
I agree with Erik, forking of the specification is not problematic as long as the forks do not purport to be openEHR i.e a trademarking issue. This is is purely so that people know exactly what they are working with.
Similarly it would actually to have been beneficial to have more forking and innovation in the software/tooling space. Just because this is a small market, it is preferable for people to contribute back to the core resources but this has been difficult because the current tools have not made this so attractive. I am hopeful that the newly announced java/ javascript tools will provide a more solid basis for collaboration and helpful forking. So again I am comfortable that we are going in the right direction.
> Theoretically I agree with Erik about the clinical modelling space being one area where it has been difficult to get a coherent approach, and it might appear that there is a large amount of pointless forking by companies and national standards organisations. I agree that at one level this is frustrating but at another, I think it just reflects the state of maturity of the ‘market’ and that national bodies, in particular like to feel ownership and need to build local trust - even the most ‘well-behaved’ national body, in Norway, has felt the need to go local to some extent - @Silje’s view here would be interesting.
I am increasingly of the view that it is the community of vendors and implementors who will force rationalisation in this space. It is very much in their interest not to have to develop their applications against n versions of Medication etc. We are not quite there yet but as the publication process of the Industry sprint rolls on, I think we will find that systems increasingly use the international archetypes internally and regard local national variants as definitional, using specialisation, local clusters to bridge the gaps.
It has not been easy to get to this point but increasingly I am confident that we are getting sufficient momentum in the international space to keep the vendors onside. National programs will take much longer, and whatever we do there will be forking, for both good and bad reasons. That is for me, what makes archetypes interesting - it brings the power of the ‘open source market’ to the solution of wrangling commonality out of a complex, and at time chaotic problem space. It was always going to be ugly but bit-by-bit, I see commonality emerging.
Ian
[Previous page](https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799.md?page=2)