Hello,
I heard about the openEHR initiative some time ago and have been following it with interest, from a developer perspective. The recent transition announcement sounds encouraging, however there are some questions which I feel are left unanswered, after doing my best to read through the openEHR documentation on the website:
- It would be great to have a more detailed and up-to-date status of projects. Looking at the Java reference implementation, I see it is incomplete, lagging behind the latest version of the specification (at least on the project page), and the latest commits are from about a year ago (with the exception of 2 commits on the xml-serializer and adl-parser – a bug fix from what I saw). Documentation on the kernel is even more scarce. Please do not interpret this a critique against the developers working on it, I just think it would be very helpful to know what parts need the most work, so that other people can contribute. Or is the information available and I just overlooked it?
You can get all the SVN RSS feeds from this page.
Ah, perfect, the feeds are a great help for keeping up-to-date.
- The concern above extends to the specification itself, although this is a bit off topic on this mailing list. While news that various governments are adopting the openEHR standard for their health care systems is encouraging, seeing that version 1.0.2 was published almost 3 years ago and that not much information is available about the future of the standard is not. I understand that this is a standard, and therefore should not be subject to a lot of change, but, again, it would be very comforting to have a more detailed roadmap and an up-to-date status available.
actually, the main reason no changes have been made for some time is that over 18 months was spent working on an organisational merger with IHTSDO, which was backed by the IHTSDO board, but fell through in the end.
Sorry to hear that, I’ve only been following this industry for a short time, but the number of competing standards is staggering. I really hope things will get better in the future.
However, the community is pretty active in recording issues, and you can see around 40 issues logged over the last 3 years on the SPECPR tracker. As you have seen, the foundation is about to move to a new governance model, so we will start processing these issues once this happens. During this time, most of the proposed solutions (in no way guaranteed to be mutually consistent!) have been tried out in various implementations in the community, so that when these PRs get processed officially there will be good evidence for deciding quickly on them.
Sounds encouraging. I had looked at the JIRA tracker before, but without knowing about the background of the last 18 months, the 3 year old unresolved issues looked quite worrying.
- I’ve thought about starting a clean room implementation, and used the XML schema (via JAXB) to generate the objects. While functional, the result was sub-optimal (generics are not used, Java naming conventions are ignored, etc.). Since Eiffel is used for the original specification, one reason being that it supports OCL-like constraints, I also thought about generating an Ecore (Eclipse EMF) meta-model, which can be generated from UML diagrams (although that would also result in the problems mentioned above) and supports OCL constraints. Manually creating the model might be a better choice in my opinion. Is there any similar initiative currently in progress? I wouldn’t want to reinvent the wheel.
there are a few things going on, and probably there will always be, because the modelling problem has to be attacked from different angles:
-
‘Faithful’ source models - models that accurately reflect the published semantics of the specifications:
-
For software development: Erik Sundvall (Linköping, Sweden) and Eric Browne (Australia) have separately started a port of the model to various UML tools. I see Erik has replied to this post, so you have the details there.
-
this kind of approach is useful for two things: generating online UML documentation & diagrams, and potentially useful for helping to build and/or reason about software (although many people I know involved in building serious systems don’t appear to use UML for much more than team discussions of models).
-
For Archetype validation and modelling: I have continued to develop the reference ADL workbench, which is model-driven. In this case, the goal was the same: represent the original specifications faithfully. In theory this might have been possible with XMI, but it is hard work, and UML is still lacking in some respects. EMF did not have generic types when I started on this, so I created a ‘Basic Meta-model’ (BMM)specification and schemas, which drive the ADL Workbench. Detailed reasons for this here. The BMM schemas are far easier to understand than XMI, but nevertheless express proper object-model semantics (data view). At some point, I will try to morph these schemas to a form where they can be exported in an EMF format.
-
Note: currently the BMM schemas express class invariants in a way more familiar to UML users, e.g. optionality is a boolean flag on a class called ‘is_mandatory’. Not all invariants from the specifications are expressible in this way, but most of the ones relating to the information (i.e. data) view of the model are there.
-
XSD-based models - the openEHR XSDs are - like any XSD - not faithful renditions of the models of the source specifications - due to the different inheritance semantics, lack of generic types and so on. However, they do faithfully express the basic data semantics. Starting from the XSD is clearly useful for generating classes that can deal with openEHR XML data and process it at the XML level. Seref Arikan at CHIME, UCL is working on a bridge between XSD-based Java classes and the BMM models exposed by the ADL Workbench above.
in some imaginary perfect world, all these models would be one and the same thing, but unfortunately, they are not - we are stuck with the differences and limitations. Ecore/EMF may be one place to eventually connect them and integrate them.
Thank you very much for taking the time to explain all of this. Regarding your BMM specification, I can see why you would want to develop your own (at the time, there was no viable alternative), and I have to say I am impressed by the thorough approach you have chosen. Great work!
Even with my limited knowledge of the subject, transforming these models to different languages seems difficult, if not impossible, not even considering lossless round-trip transformations. That’s why I’m hesitant of starting an EMF ‘port’ – not to end up with just another semi-compatible model at the end. I’ll read up some more on the alternatives before making a decision.
- Especially following the transition announcement, I’m considering working on a tool for easier archetype modeling, which will be essential before any large scale clinical implementation can take place. The recent discussion on the technical mailing list regarding web-based vs. rich client solutions has merit, but for me is still a long way off, at least until the issues above are dealt with. Are there any existing projects that cover this?
The ADL workbench will become a ‘technical’ editor in the near future, i.e. allowing editing of archetypes with the full technical aspects of both the AOM and the RM visible. These are generally hidden as much as possible in clinical modelling tools like the Archetype Editor. This is a short-term effort (I hope;-)
A medium term effort getting underway is called ‘Bosphorus’, by Seref is to connect a Java front-end to the ADL Workbench back-end (i.e. executed as a server) via some more modern technical tricks (ZeroMQ, Google Protocol Buffers) than JNI or other naive wrapping methods.
The reason for doing this is that we think that the work of implementing the front-end and message-based bridge to be less than re-implementing the entire ADL compiler right now. The reason to do that is that some final aspects of ADL 1.5 are still under development, and creating a complete ground up ADL 1.5 Java toolstack right now seems premature (I suspect it is worth waiting for another year before doing that). Seref aims to connect XSD-based Java classes to this framework.
I would therefore think that if you want to work in Java, Bosphorus may be the most interesting project.
I have to admit I only looked at some screenshots of both archetype editors, the Archetype Editor because it’s for Windows (well, .NET), and I’m using Linux (I guess I could try Mono…), and yours because I couldn’t get it to run (there was a page-long dump when starting it from the terminal – I can try again if you’d like more information, or maybe give a hand in trying to work out the cause). Also, to answer your question in the release notes – Yes, at least one person is trying to use the Linux build 
I would be more than happy to avoid reimplementing anything I can, especially a compiler, so I’ll continue doing some research – especially on the Bosphorus project you mentioned.
The openEHR website also mentions that ADL and AOM are set to become ISO standards… I assume you’re refering to a specific version – if so, which one? Wouldn’t that version be likely to become the most ‘popular’? Also, I’ve noticed version 2.0 of the ADL is on the official specifications page – is there a roadmap for the ADL 1.x and 2.x branches?
I am confident about the benefits an open implementation of openEHR can provide, and would like to contribute to it. Thank you for reading, I’ve tried to summarize my points as best I could. I am looking forward to hearing your opinions.
Regards,
hope this helps,
More than you know. Thanks!