Dear all of the technical mailing list,
I made a new message tothis list (specialized ;-), so it will be discussed separately.
I do that because in the other message, I describe a real problem which needs a solution, and this message is about thinking about a solution in the archetype-framework, which will takes for years to come (if it will come, maybe I am wrong in my proposal).
Only in older ADL 1.4 tools. In ADL2, and implemented in the ADL Workbench, and more recently in the . it works just like an OO programming language. There are dozens of examples in the , and also in the CKM archetypes, which when they are read into ADL Workbench, are re-engineered into differential form. This has been the case for over 5 years, with the implementation in ADL Workbench being available for around 4. (You can see the of the AOM2 spec). Using this technology is just a case of moving to ADL/AOM2. - thomas
Hi all,
when will this be available in the openEHR CKM?
Cheers,
Birger
Imagine combining all of this with GDL (http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html) and a specialised
version of a similar DSL to describe archetype / template aware GUIs.
Good news Thomas, but don't bring it with disdain.
which when they are read into ADL Workbench, are re-engineered into differential form
I think the ADL Workbench is a cryptic piece of software which could use some GUI-specialists to redesign it, so it will become understandable for non-software-specialists.
Using this technology is just a case of moving to ADL/AOM2.
I wouldn't call it "just a case", ADL2 is not yet fully defined.
See the open cases in the specifications (128):
https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-168?filter=allopenissues
The tooling is not yet ready, and even when there will be a frozen standard, it will take years for institutions to migrate. They want a stable version, before shifting their core-information to a new information-structure.
It is good news, but don't bring it as it is like a breathe, then you disregard the hard work of people working on the technical information side of institutions.
Sorry to be harsh on this, but so was your reply,
Best regards
Bert
I don’t know what the words means 
well, the point is that the ADL Workbench fully implements the differential specialisation semantics you are talking about. Whether it has a cryptic UI is apparently a subjective matter that appears to be a PR about GDL? Well the tooling that is there now is:
we may be able to re-use ideas from the Intermountain Healthcare Activity-Based Design (ABD) project I am working on in the US, which includes presentation specification in its archetypes (they are not ADL archetypes, but something similar).
Good news Thomas, but don't bring it with disdain.
I don't know what the words means
I got it from google translate, in French it is dedain.
that appears to be a PR about GDL?
I meant a current list of Open Issues, I don't know why the 168 is on top, it seems to have the highest priority, I don't understand why.
That is not my discussion point.
So it's not perfect, but it's far from non-existent. I'd say your best bet is to use the new version of ADL-designer.
As said, institutions will want a stable release. I will never advise an organization to move to ADL2 as long as it is not stable.
Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4. There must be many archetype, and many data-storages based on ADL 1.4
And there is another point, companies don't tend to change when they do not feel the pain.
I had my first IP6 course in 1998, I worked for DEC (Digital) at that time, and still the computer I work on is configured using IP4, so is my Internet-router.
But the discussion on this technical list can be closed as the point I wanted to make is planned to be solved (and maybe soon).
Best regard
Bert
Hi Bert,
Marand are about to release a major interim update to their ADL-2 Archetype tooling. I am told sometime in March).
One of the major design criteria is to be able to create ADL1.4 artefacts and, critically, ADL 1.4 .opts so we can use the new tools with existing systems, but take advantage of better handling of specialisations etc. @Birger - This will also help with transition in tooling like CKM, where we should be able to create ADL 1.4 flat forms for review purposes.
We expect this first release to need a bit of work and user-feedback. We (freshEHR) have committed to give it a good workout on real-world project so that we can rapidly iterate and get it ready for proper release.
This is the year we make the jump, at least in the design space!! I expect back-end CDRs and other tooling to be working with ADL1.4 artefacts for some time. The impact on CDRs is not actually very significant if we mange the transition carefully.
I would be delighted to hear from any developers or companies who might be prepared to make a contribution to this project (open-source of course). We have had a couple of interesting offers of support already. Good tooling is essential to openEHR, and if we get a good set of baseline tools, there are all sorts of interesting extensions that could be developed.
Ian
c’était une blague… ah - probably you wanted to show . There are issues (always), but not with the specialisation representation. well, it has a . As noted above, there are issues, but there are issues outstanding on everything - they get worked on and the results get added to later releases. I’m not sure of what the alternative to that is. well CKM is a problem in one sense, but people could work with ADL2 tools and save the results as ADL 1.4, which you can do in the ADL-designer, for upload to CKM. That’s not ideal, I agree - it would be better if CKM upgraded to ADL2. Data storage is generally based on OPT 1.4, and I think that is also a save format of the ADL-designer. well you are pointing out some pain, and I am pointing out the solution. If you are not in enough pain, you may not want the solution - thomas
Hi Thomas / Bert,
I think you will find a significant pain point in the modelling community. Agree that for now 1.4 .opt is going to be best for implementers but as I understand things a 2.0 .opt and related RM changes would not be radically different, in any case.
The big difference, and gain (once we get over the line) is much easier handling of design-time artefacts, and potential extensibility.
Ian
We’re looking forward to the new ADL-designer. We’re currently building an ADL-2 based openEHR implementation and currently doing parts of the archetype design by hand until we have better tools.
If you want to use ADL-2 and you’re looking for a java library for your EHR or authoring tools, Archie implements ADL-2 and the reference model, plus a lot of tools for working with them.
Important for specialization: It include a flattener and operational template creator that converts specialized archetypes and templates to an operational template. Those make working with specialized archetypes much easier. They combine the archetypes, templates, templates overlays and specialized archetypes into one flat archetype that you can use in your tools and user interfaces.
See http://github.com/nedap/archie . It now also has experimental but usable support for rule evaluation.
Licensed under the Apache license, so it should be usable in any kind of project you like – open source or proprietary.
Regards,
Pieter Bos
Nedap Healthcare
well the problem with continuing to use ADL 1.4 is the in a) weaknesses modelling semantics (much weaker in 1.4) b) errors caused by lack of differential representation of specialised archetypes (a major problem) and c) different representation of templates (in ADL2 they are built-in).
Implementations can standardise on OPT 1.4 without difficulty for some time, but this doesn't require continued use of ADL 1.4 for modelling.
- thomas
Hi Pieter,
Thanks for the update. This kind of innovation is why I am so keen to make the jump to this brave new world.
I’d love to hear more about your main project but will contact you separately.
Ian
Lots of good things happening. We will see when major shifts will occur. I keep my finger in the wind and expect another year to wait.
I hope sooner. There will be a migration period in which both versions will be used.
Bert
c’était une blague…
I see that, sorry for that.
Please understand my situation. I was in the urge to solve a problem in the ADL1. 4 environment and I was not waiting for someone to tell me that that problem is already solved because ADL2 will come real soon.
Maybe it is maybe it is not, but that discussion did not help me.
But in the end my problem is solved so everything is oké now.
Best regards
Bert