We’re pleased to announce Archie version 0.4! For those of you unfamiliar with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for archetype modelling and EHR implementations with ADL 2.
Version 0.4 is a big change from version 0.3. Many features have been added that make Archie suitable as a library for modelling archetypes, and the existing functionality has been improved.
It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and Kurt Allen. This enables Archie to work with other reference models than the included OpenEHR reference model. The BMM files and AOM profiles that are in the ADL workbench are included in the library – of course you can supply your own as well.
We developed an archetype validator that implements nearly all of the validations in the specification, and we improved the flattener and the operational template creator to be compliant with the specifications. The flattener, archetype validator and operational template creator work with both the BMM models or with metadata derived from an actual java reference model implementation.
Many tests were added to ensure better conformance with the specification and many fixes have been introduced. We’d like to thank Thomas Beale for giving advice about many details of the working of OpenEHR implementations and for fixing mistakes in the specifications when they were found.
Of course, Archie also contains a lot of other tools, many of which allow it to be used as the basis for an EHR implementation as well as a modelling tool: An ADL parser and serializer, the OpenEHR reference models, rule evaluation, path lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation tools.
Archie version 0.4.1 is available at Maven Central. See the instructions and documentation in the readme at https://github.com/openehr/archie for how to use the library.
Allow me to express my appreciation and gratitude please: Archie is a fantastic piece of work, which has become my go-to library since I discovered it. Thanks a lot for all your hard work.
Can I also express my thanks on behalf of the openEHR community. Late in life I am becoming a bit of a java-ninja (well , in my dreams), so I will definitely give Archie a go. I can already think of a few really useful bits of tooling we could develop.
This is excellent work, and has proven to be a great test for the AM specifications, helping me to find various errors. But the main interest is that we will be able to build new tools such as a Java/JS replacement for the ADL Workbench, and of course things like a high-quality, BMM-driven runtime archetype validating kernel for EHR systems, workflow implementations and many other components.
And due to several small bugs, we’re at version 0.4.2. Should be available soon at maven central.
For anyone wanting to test Archie without writing code, we’ve also created a command-line archetype validator. Works with all included BMM reference models, including OpenEHR and CIMI.
3. Make sure you have a java 8 JRE installed and that typing ‘java -version’ in a command/terminal window shows you installed java version 1.8.x
4. Run bin/adlchecker (linux, OS X) or bin/adlchecker.bat (windows) from a terminal/command prompt and follow the instructions to point it at your archetypes
Note that it only supports ADL 2, not 1.4. It can also output the flat ADL.
If you find any issues, they can be reported at the github repository.
Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie (written in Java, disappointingly) would enable JavaScript implementations. JavaScript has nothing in common with Java (apart from the name).
Or a Java app with rest api and a JavaScript frontend. Let the java application take care of parsing, validating, flattening, operational template creation etc and send json to your front end. Archie has built-in json serialization and deserialization support.
Interaction with a JavaScript front-end could be done with any back-end programming language — it doesn’t have to be Java.
So your point is that Archie's serialisation and deserialisation to JSON will will assist this? I believe Thomas’s Eiffel implementation already has JSON serialisation, since about 5 years ago.
Great work! A very good contribution both as code (with widely usable licence) and in practice as a specification debugging effort!
//Erik Sundvall
P.s. Regarding Javascript I’d recommend looking at the related Typescript superset instead for anybody wanting to do implement openEHR RM or AM on client side in browsers. It will likely feel more familiar for Java (and Eiffel) people and others wanting to do generics, type checking etc.
Is anybody out there working on or planning a Typescript (or possibly JavaScript) based openEHR library implementation with a permissive open source licence (like Apache 2)? I guess many thoughts and design patterns from Archie could be reused… Such a library could be used for e.g. https://angular.io/ and/or https://nodejs.org/en/ based projects.
yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. Just that JS/TS are the languages that seem to be popular for web app development these days, and Java for the back-end. The connection between front and back-end that people seem to prefer these days is REST APIs, which both Java and JS can do easily enough.
Belated thought on this topic: a much better way to connect a JavaScript front end with a Java back end, or any similar combination, would be with a binary RPC protocol like ICE, that comes with tools to make it all work.
The problem with Ice is that it is not open source licensed when used in a non GPLv2 product.
Another problem is that they do not publish the price of a commercial license.
That are restrictions that cause many programmers not to use it.
A small amount of JavaScript working with Json from a backend works very well for us.
You don’t always need explicit class definitions. it does require a different programming style than a more object oriented language.
Thomas has a point,
JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are misused for functional error-codes
- the http-protocol with all the headers is not efficient and has unnecessary overload
- REST is not error or type safe, you can send anything to a restservice, it processes the whole request-headers, and then looks if the parameters are sufficient in number and in type
The question is only of a license-restricted product as ICE is the answer to this problem
For microservices GRPC works very well, it has a performance of sometimes 100* the performance of rest, it supports also bi-directional streaming, and it is safe, because the interface-code is generated.
There are some promising projects for GRPC in browsers which support HTTP/2 (this are all browsers in their latest versions)
I did not test it, but I will, in a few weeks in a project I am working on. https://github.com/improbable-eng/grpc-web
Those are all valid points, but for many applications, I would say are not actual problems. If we're discussing the context of archetype editing tools, I would say REST with JSON is fine. HTTP traffic is usually compressed and browsers have heavily optimized their JSON parsing, making it much more efficient than it would seem. Very good tools are available in many languages to parse and validate JSON encoded data against a given model and given types. Many people know how to use it so they can start developing right away, and debugging is easy due to the fact that is human readable.
For microservices with enough traffic, or for devices with limited processing power or limited bandwidth, a binary encoding makes sense. However, GRPC would not be my first choice for OpenEHR - you would have to find a way to map all the inheritance in the OpenEHR model to protocol buffers.
Regards,
Pieter Bos
Nedap Healthcare
> A small amount of JavaScript working with Json from a backend works very well for us.
>
> You don’t always need explicit class definitions. it does require a different programming style than a more object oriented language.
Thomas has a point,
JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4
bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of
CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are
misused for functional error-codes
- the http-protocol with all the headers is not efficient and has
unnecessary overload
- REST is not error or type safe, you can send anything to a
restservice, it processes the whole request-headers, and then looks if
the parameters are sufficient in number and in type
The question is only of a license-restricted product as ICE is the
answer to this problem
For microservices GRPC works very well, it has a performance of
sometimes 100* the performance of rest, it supports also bi-directional
streaming, and it is safe, because the interface-code is generated.
There are some promising projects for GRPC in browsers which support
HTTP/2 (this are all browsers in their latest versions)
I did not test it, but I will, in a few weeks in a project I am working on. https://github.com/improbable-eng/grpc-web
