This draft has moved to Archetype Authoring Tools in the openEHR Developer Guide.
The tooling guide is now maintained as a Zensical website. It is the first section of a broader developer guide, with implementation and conformance guidance to follow.
Please post corrections and additions on the openEHR Discourse forum or open a pull request at openEHR/developer.openehr.org.
I am hoping that once we’ve shown these to SPB members we’ll have a clearer idea of what tooling is available and a nice series of articles, which can be moved to perhaps a Knowledge Hub section of the forum.
@SPB you may wish to:
I can continue the series with
Awesome work! I would suggest a 16:9 ratio, as it is more standard than 4:3 IMHO.
I think tagging is a good idea. The tags depend highly on the way we want to search or sort things later on. Maybe we should establish a scheme with various categories. For example:
Hi Marcus,
This is a good overview and idea. You suggestion with adding tags sounds also useful, handy to have. It is also good to show and filter by it, a sort of multi dimensional categorization.
I also second @Martin_Koch suggestions.
About the tools itself:
Then there was also what I believe was the first non-Ocean editor, the LiU (Linköping University) archetype editor that made SNOMED CT bindings easier https://www.diva-portal.org/smash/get/diva2:264672/FULLTEXT01.pdf
We gave the code to openEHR but maybe it got lost in translation when moving openEHR source code projects from Subversion to Github, see @thomas.beale and me discussing at openEHR Subversion => Github move progress (By the way thanks again @marcusbaw for getting the mail archives online inside Discourse!)
I don’t think anybody would like to run the LiU archetype editor in production today, but finding the source code would be good if any developer wants an AI to look at it together with the academic paper to understand the design and perhaps reimplement some of it in some more modern form.
P.s. the last time the TermViz part of the solution was refreshed and used was around 2012-2013, see GitHub - ErikSundvall/TermViz: TermViz, terminology visualization component based on HTML5/JS and D3 · GitHub Perhaps time to revive and refine?
For quite strange reasons, the AWB had a lot of work done on it while I was in the US (I was not allowed to use any other tool!), so it has some new smart semantics in it, and improved OPT algorithms and so on. I am currently converting it to Kotlin. The whole BMM part is already running in Kotlin. So AWB will be EOL pretty soon.
I assume EOL means “end of life”? If so will this new partly Kotlin-based function appera in some other tool than AWB? Have you considered transpiling stuff from Kotlin to Javascript so that it is easy to reuse in webapps?
sorry yes - another anglo acronym!
The entire back-end is in Kotlin, i.e. BMM parser, builder, validator, AOM parser, builder, validator. So that part can be used in an IntelliJ plugin I have built, i.e. you see all your BMM and ADL files syntax highlighted, and you can ‘run’ and it runs the appropiate compiler.
The AWB front end is another matter. It can’t really be transpiled to anything directly because the UI model/meta-models are completely different - the modern targets are more powerful. I can expose the back-end as a language server, so there is a clear API for a front-end to talk to. But as for actually building the front-ed… still contemplating alternatives. AWB, old as it is, does a lot of nice tricks still not available in any of the newer tools (e.g. inheritance overlaying and so on).
To me it really feels as though there is no over-arching organising principle bringing together openEHR tooling, and to some extent it is continuing to get worse, with dozens of individuals working (it seems to me) separately and disconnectedly to create an ever more confusing landscape. No amount of ‘beginner guides’, Knowledge Hubs, websites, or GitHub repos can herd these cats. We need some leadership.
I tried to bring together my knowledge about what is current and what isn’t, and some structured data on each. The first post in the topic is a Wiki so it can be edited by others. However, there have already been suggestions to switch to a variety of other tools.
I liked the suggestion (by @joostholslag in the other related thread) of an AwesomeList in GitHub, this might be a simple starting point for managing the information on tooling, keeping the information-curation overhead small by making each one just a single line of a list, linking to some external page. An example of this in practice is this AwesomeList: GitHub - kakoni/awesome-healthcare: Curated list of awesome open source healthcare software, libraries, tools and resources. · GitHub. If we did this, it would be called something like github.com/openehr/awesome-openehr and we would accept PRs to add info.
Tool and software building in the open source space has proceeded completely organically, with most tools built by various companies that decided to release specific things open source.
I spent quite a bit of time, as well as Tony Shannon whom you will remember, on the document attached here, which was circulated some years ago, but we got no traction. That’s no criticism of anyone; we probably would have hoped for some proper funding, maybe from NHS, Wellcome, a European source, or possibly big tech, to help get a more coherent approach off the ground. While there is patchy funding, there will only be patchy open source offerings.
We actually spent a lot of time thinking about how Apache works (in particular), and devised a governance structure that you will see in this document.
openEHR_software_program.pdf (390.8 KB)
More recent efforts (about 3y ago) by myself and a few others to get a Software Program Board moving did not attract much interest.
Anyway, ‘organisation’ can only come from a common roadmap that everyone more or less agrees to, and gets progressively filled in with various components, tools etc. A realist view of this would be that not everything in the roadmap has to be OS, it just has to have defined and stable interfaces.
People in the Software Program might want to revisit this document if they have not seen it.
Thanks @thomas.beale for posting that 2019 document. I’ve reposted it in its own topic for discussion because this topic is about Archetype Authoring Tools.
I would move the Archetype Companion to the “Knowledge managment” section, as you cannot author “real” archetypes with it.