It is still very much in development, but it is now at a state where it
could be of use to people. It currently features:
- an ADL2-parser that parses the full definition, specialises,
terminology, value sets and (a subset of) rules sections
- an archetype object model implementation
- a flattener that can also make operational templates - still needs
testing and work!
- basic path queries with node ids and node meanings.
- an experimental Archetype treewalker for openEHR reference models it
can save you many instanceof calls.
It parses most valid ADL2 files i¹ve tested it with into an archetype
object model. That includes most of the content of the clinical knowledge
manager. We¹re currently using this same library for an openEHR
implementation and we will add features, fixes and tests to it as we
progress.
You might ask, why a new library? Don¹t we have adl2-core already? The
answer is quite simple: licensing.
We could not use the adl2-core library for our projects, because it would
require us to release the entire project under the (A)GPL. So we ignored
the existing library and built our own. And now we release Archie under
the Apache license. This means you should be able to use it in any project
you like.
Want to help? Great! There¹s a list of missing functionality on the github
page. Just fork and create a pull request. Or just report any issues you
find on the github issue tracker.
Apache 2 is a good licensing choice, that is what we recommend for openEHR open source projects, although some contributors have felt reasons to use other licences.
Apache 2 for example makes it easier for some companies to allow staff to spend paid working time on improving industry/community-shared open source components that they use in their closed or open platforms. Nowadays I’d guess more openEHR software implementation work is done by business employees during paid time than by volunteers using their spare time.
Having more ADL2 parsers does bring some extra benefits:
compatibility tests and discussions can clarify the specification if needed
more of the possible design space is explored by more teams that can learn from each other
However having a dozen of open source ADL2 parsers would probably be a waste of developer effort.
I think the same goes for archetype/template editing tools, having a handful of tools explores more options and brings up more good discussions than having a single one, but having too many would potentially be a waste of developer effort.
I don't know why you write this, looks in this way like a congratulation with a remark.
We have, for example, many editors for Java, text, documents, all kind of things. I would not regard that as waste, but as innovation.
Competition keeps the quality high.
For example, I am sure the effort of Pieter Bos improved the quality of the work of Thomas, and there is nothing bad in that.
Let thousand flowers bloom. Encourage many ideas from many sources.
It was not intended as a remark towards new initiatives. Sorry for being unclear. You raise some good points Bert.
I tried to be balanced, encouraging new openEHR work and alternative implementations, there is always room for more, but at the same time encouraging people to first look at existing efforts and see if they can influence/modify/widen those to fit their needs before starting yet another effort since the openEHR community has still has many other software needs that would be worth spending time on.
Regarding ADL2 parsers there was certainly room and a need for an Apache licensed one now. I understood Marand’s reasoning behind releasing their ADL2 implementation under (A)GPL, but personally thought it was not the wisest licence choice for a component that we want to see maximal reuse and testing of, also in “industrial” settings. (Marand already knows my views on this.)
So if there was something of a hidden remark in the message, it was more like “look, this is what may happen if you release reusable openEHR components under (A)GPL, people will need to redo the work mainly for licencing reasons”.
But as I said redoing work has benefits too, like exploring more options, learning, creating more choice and testing/validating/clarifying specifications in more ways. Having another ADL2 parser will make ADL2-adoption and specification even more mature.
Personally I hope that also new web based archetype/templating tools (see http://www.openehr.org/news_events/industry_news.php?id=134 and https://goo.gl/7Cd52R) in due time will shift more over from (A)GPL towards Apache 2. Pieter &Co’s work might influence that shift by provoking thought and/or providing an alternative ADL2 underpinning.
I think that the best way is if there is a grammar-description and object description which exists vendor and platform neutral in a liberal license, f.e. Apache-like.
Mostly this is already the case, and where this is not, the foundation/community should take care that it will come.
Only in this way, OpenEHR can stay a platform independent/open (standard) specification.
Good to hear you appreciate our effort. While developing Archie we found
issues in both the ADL-antlr grammar and the Marand ADL-designer. We¹re
very happy to see how soon after we reported them the issues were fixed -
Often even within a matter of minutes after reporting. So it already has
helped the compatibility of different tools - we can now parse the ADL2
output of the adl-designer.
About our motivation: we develop and sell software for the Dutch care
market. Our current EHR-implementation works great for many organizations,
but is not flexible enough for some others. That is why we are looking at
openEHR and developing prototypes for the next version of our EHR. When we
realised the improvements in ADL 2 and the limitations of the java
reference implementation we decided we needed to switch to ADL2.
We found out there was no open source tool available we could use. So we
developed Archie and released it under the Apache license - so others will
more easily be able to develop their own tools, whether open or closed
source. And because we think that for a platform like openEHR - the more
people using it, the more benefit there is to anyone using or developing
openEHR-based software.
o.
