# EHRBase and ADL2.0 **Category:** [Platform](https://discourse.openehr.org/c/platform-implem/7) **Created:** 2024-01-14 14:10 UTC **Views:** 779 **Replies:** 23 **URL:** https://discourse.openehr.org/t/ehrbase-and-adl2-0/4825 --- ## Post #1 by @thiagofelix 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. --- ## Post #2 by @birger.haarbrandt Hi @thiagofelix, 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. --- ## Post #3 by @thiagofelix Than you Haarbrand, I will focus more on the ADL 1.4 for now and downstream artifacts/API based on this version. --- ## Post #4 by @Jose_Pereira 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? --- ## Post #5 by @birger.haarbrandt @Jose_Pereira I think it could be worth checking with Nedap if there is a way to get access to their openEHR server with adl2 format. I don't have a definitive date for EHRbase and unfortunately I don't think it will be this year. --- ## Post #6 by @ian.mcnicoll Hi José Pereira, 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? --- ## Post #7 by @Jose_Pereira ok, thanks for your answer. --- ## Post #8 by @Jose_Pereira 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). --- ## Post #9 by @ian.mcnicoll Thanks José Pereira 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. Ian --- ## Post #10 by @Jose_Pereira hi Ian, I just sent you an email. Thanks for all your attention! --- ## Post #11 by @borut.jures [quote="ian.mcnicoll, post:6, topic:4825"] 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. Other than of course NEDAP, who started with ADL2. [/quote] Hi @ian.mcnicoll, 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. ADL2 is 10 years old (https://specifications.openehr.org/releases/AM/latest/ADL2.html). I’m having a déjà vu experience with old versions :grimacing: 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 :crossed_fingers: 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 :wink:). Could this be an issue with slow adoption of ADL2? --- ## Post #12 by @birger.haarbrandt > 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 :crossed_fingers: 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. --- ## Post #13 by @joostholslag 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. --- ## Post #14 by @Jose_Pereira 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. --- ## Post #15 by @joostholslag I’m unsure about the status of an opt2->1.4 converter. Did you check wether Archie or tools.openEHR.org offers this conversion? The reverse conversion is partially done in this branch: https://github.com/openEHR/archie/pull/261 And this branch is for converting data: https://github.com/openEHR/archie/pull/392 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. --- ## Post #16 by @Jose_Pereira 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. --- ## Post #17 by @Seref [quote="borut.jures, post:11, topic:4825"] 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. [/quote] No (... post must be at least 10 chars says the forum. So I cannot just say No) --- ## Post #18 by @birger.haarbrandt 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. --- ## Post #19 by @borut.jures 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 :blush: @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 :wink: --- ## Post #20 by @thomas.beale [quote="birger.haarbrandt, post:18, topic:4825, full:true"] 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. [/quote] I'm working right now on a version of Archie that will incorporate a new RM (Java code generated from BMM, via @borut.jures '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. @borut.jures 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). Code generation is the way ... --- ## Post #21 by @joostholslag [quote="thomas.beale, post:20, topic:4825"] @borut.jures 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 [/quote] @borut.jures could you please share some more info? How much handwork is needed to generate an api for a specific template? And what is the (data)model/schema for the api, usually it’s OpenAPI, right? --- ## Post #22 by @borut.jures @joostholslag I had to spend some time writing the generators, but now it takes no handwork to generate an api for a template. Is this what you meant? I have OpenAPI and GraphQL generators, but they require some more work – mostly to decide how to represent all the complexities of BMM and ADL in these formats. Once that is done it would take "a day" of handwork to add it to the generators. Closest to production are Java "domain model" classes. The first screenshot is a classic approach with named setters. The second is using a LOINC code to automatically set the corresponding values. This is the approach @thomas.beale "added" to the generator. All the classes used in the example are generated from OPT2. ![vital_signs.java1|491x500](upload://gDvh9L8Zqd2V5BEgEK3JR5isfeN.jpeg) LOINC: ![vital_signs.java2|540x500](upload://26UYKOcQKUYMUehCiGZux17FgCf.jpeg) --- ## Post #23 by @thomas.beale [quote="joostholslag, post:21, topic:4825"] And what is the (data)model/schema for the api, usually it’s OpenAPI, right [/quote] When we speak of this kind of content-based API, it's not canonical RM API calls like in the official openEHR API, it's the API of a (Java / C# / whatever) class that is used at the programming level. OpenAPI is what you write web-visible APIs with; the API of a Java class is not (on its own) visible through a web protocol like REST or Protobuf or whatever. Of course, it can be connected through to such a web API, if we wanted these kind of classes to be exposed that way, but they are normally used in two places: * client-side app programming, where you bind in the generated class(es) and your own code can make calls that create the (say) `VitalSignsEncounterTemplate` class, and then do a lot of calls like `myVsTpl.setBloodPressureSystolic (args)`, etc, and then at the end make a call like `generateJson`; * server-side integration programming, where a data ingestion engine is processing data items and has determined (in our approach) the canonical LOINC code for the item (by various tricks) and has a data object to go with it (i.e. some Quantity representing the value of systolic BP); the calls will be then of the form `setViaLoincCode (aLoincCode: String, args)` The classes generated by @borut.jures 's tools from a template provide both of the above programming level APIs rolled into a Java class. --- ## Post #24 by @birger.haarbrandt FYI: We got something similar in the EHRbase openEHR SDK, but ADL 1.4 only for now. --- **Canonical:** https://discourse.openehr.org/t/ehrbase-and-adl2-0/4825 **Original content:** https://discourse.openehr.org/t/ehrbase-and-adl2-0/4825