Hi everyone, first time posting here after couple of months of intense specification reading and browsing through GitHub code and Discourse trying to catchup on everything openEHR related.
After reading the specification I then went to see the EHRBase code and found that it doesn’t support ADL2 templates yet, is that right?
If yes then can someone explain what is the overall ADL2 adoption in the openEHR ecosystem?
Although I am sure there is a lot of overlap between 1.4 and 2.0 I sort of felt that I wasted some time on reading ADL formalism given that is not implemented or ready to be used.
Thank you for you attention and I appreciate the community for been so keen to help. Many topics here were helpful in understanding more of multiple aspects of openEHR not very clear in the specification.
product manager of EHRbase here. There has been some discussions in the openEHR community during the last 3 years how to make the transition from ADL 1.4 to ADL 2. At the moment, EHRbase indeed does not support ADL 2.
I think we have reached some conclusions by the end of 2023 and we will be able to move forward across tools and vendors. There is still no joint roadmap, but there will definitely be the leap forward. From this point of view, your time and effort is not wasted.
Hope this clarifies the situation a bit and I’m sure others will be able to give some different perspectives on the issue.
Hi @Birger.haarbrandt, do you know if there is any way to test Operational Templates in adl2 format (adls files) on a server that implements the openEHR API or is there any time estimate for these resources to be available in EHRBase?
It would be good to know more of the background to your question. For all sorts of reasons ADL2 has been quite tricky to get established in current CDRs. Everyone wants to get there but there are still some quite practical issues to be resolved and TBH I would be surprised if any current ADL1.4 CDRs have opt2 capacity this year or even next. Other than of course NEDAP, who started with ADL2.
The good news is that there as consensus path in the SEC specifications group (with input from all the current CDR providers), and steady progress is now being made.
What are the aspects of ADL2 .opt that make it compelling for you right now, and are not in ADL1.4 .opt?
hello @ian.mcnicoll, first of all, thank you for your reply. The context of my question is as follows:
I am involved in a research project to develop a software component that is able to map FHIR Questionnaires to openEHR, automatically. And we started its development through the Archie library, we only took into account the REST API present in the openEHR specification, which already includes adl2, without checking if this version was already supported by EHRBase or similar. In other words, we were only confronted with the absence of this support at a very advanced stage of the project (we are new to openEHR).
That might not be real problem. I’d be happy to have a look at where you are and see if any issues can be worked around. Id be surprised if one could not make this work fairly readily with ADL1.4
I’m very interested in your topic of research in any case.
Ping me at ian@freshehr.com or in a private message here, if you feel a chat would help.
Isn’t the above contradictory? Is Nedap using ADL2 for their CDR without the issues?
Before openEHR I worked with Microsoft’s ERP and their clients wanted to upgrade their systems, but couldn’t because the implementers weren’t “ready”. Many users were stuck with old versions while newer and better ones were available.
My approach to openEHR is to generate as much as possible from the BMM files. The result is that the code for AM and RM can be generated for any version (including ADL1.4, ADL2, ADL3 and in any programming language).
Could the mentioned “practical issues” involve a fear of vendors breaking their systems with hand-written ADL v1.4 code, written by programmers which aren’t involved with the development anymore? That would mean the newer programmers are afraid to touch the code they didn’t write. I hope not
In the ERP world the reason was that implementers were too busy implementing new clients and didn’t have time to upgrade old versions (also new projects are more profitable ). Could this be an issue with slow adoption of ADL2?
Could the mentioned “practical issues” involve a fear of vendors breaking their systems with hand-written ADL v1.4 code, written by programmers which aren’t involved with the development anymore? That would mean the newer programmers are afraid to touch the code they didn’t write. I hope not
This is certainly not the issue. I think it is closer to your second guess that we have the (luxury) problem of being busy with delivering to customers. Also, there is still need for coordination between different tools and vendors so that users will be able to keep their chain (Archetype Designer → CKM → openEHR Server → Forms Tools → AQL Editor). So that’s not trivial.
If you need help on adl2 specifics, let me know. Archie should be able to do some of the conversions. And I seem to remember some experimental conversions are still in a branch on GitHub.
Hi @Joostholslag, first of all, thanks for your answer. Due to the fact that there is still no server solution to deal with adl2, I needed to convert the Archetypes/OperationalTemplates (adl2) to adl1.4, in order to be able to use them with EHRBase, if you can help me with anything (even those " experimental conversions" from Archie), I would be very grateful.
Maybe it could be inspiration to build what you need into Archie?
Btw how complex is your template? Maybe it’s easier to recreate it manually using archetype designer. Or do you need to be able to convert many templates?
@pieterbos might be able to share more info on Archie.
This Archie parser and converter converts from adl1.4 to adl2, but what I need is the opposite, convert from adl 2 to adl1.4, this is not available in Archie (at least in the publicly available version).
And tools.openEHR.org doesn’t offer this option either, I can import my files there, edit them, but I can’t export in adl1.4, only in adl2.
I need to convert a lot of models, because I’m developing a tool that converts FHIR resources to openEHR, using Archie. We intend for the tool to be fully automated, receiving FHIR resources, converting them to openEHR and storing them on the server, but my barrier is the fact that no open source server (CDR) supports adl2.
Thanks for your answer.
btw, I’m really curious how the “hand written” template-processing part of anyone’s implementation could be replaced by something coming from BMM. I’m talking about validation, example generation etc.
There is another generator for the templates that handles example generation and validation. The example generator takes OPT2 and generates a randomized compositions. It can even take archetypes and wrap them inside compositions. It just generated example data instances for 10+ OPTs and 3300 archetypes
@thomas.beale is using these generators – I’m sure he is willing to go into more detail (either here or in private).
p.s.
My approach is to generate as much as possible but there is also some hand written code
I’m working right now on a version of Archie that will incorporate a new RM (Java code generated from BMM, via @NeoEHR 's tools), including perform instance validation. The latter capability is already in Archie, and partly generic, partly openEHR-specific. I’m aiming (maybe even this weekend) to get it to the point where we have a fully RM-neutral instance validator, i.e. any new RM can be plugged in, and the only built-in thing in Archie (model-wise) is AOM2.
@NeoEHR has some other tricks for generating code from BMMs to create template-specific APIs (aka TDOs) that when called appropriately will generate guaranteed correct canonical structures and output in JSON (but it could easily be some other serialisation).
). Could this be an issue with slow adoption of ADL2?