Somebody should use this forum’s MCP to count how many times Ian had to write, “This is solved in ADL2”.
@HHeiser @jbuch You are having problems because your CDR hasn’t migrated to ADL2 in the past 10 years since ADL2 became available.
I made that statement because for a while people would ask ‘why bother with ADL2’ , and for many implementers this kind of cross- language issue is not relevant.
I want to get us to ADL2 but we can’t blithely ignore the challenges of migrating from ADL1 to 2. There have been a whole number of ‘snags’ that have needed to be worked through, particularly if the vast majority do not have the luxury of implementing clean ADL2-only CDRs.
The CDR and tooling implementer community has engaged strongly in making sure that the burdens of transition are as low as possible because otherwise we will never, IMO, get there.
ADL2 was ‘ready’ 2 years ago but never 10, and we are still working through significant impacts on transition on existing queries.
Even the clean-room NEDAP implementation involved some assumptions and workarounds which have come to light and their insights have been invaluable.
We are not in a clean-room scenario - that is the price of success, and we have to manage the transition responsibly.
But let’s have that discussion somewhere else!
Not quite… the substantial changes were all worked out by 2012 and formally specified by 2014 (17 July 2014 to be exact).
All changes since then (other than the ‘constraint strength’ thing, and i think ‘RM visibility’ (both both non-breaking changes) are documentation changes, not syntax changes.
AOM2 changed a bit more slowly, but the hard parts were done by 2016, and the form available in 2014 worked (but it had a couple of edge case bugs). So that’s 10 years.
I have the entire source code history of ADL Workbench to show this history, but it is equally visible in the ADL2 and AOM2 specification revision histories. The code modifications since 2014 on AOM2 are all incremental.
The form of ADL2 available in 2014 solved nearly every problem on this page, including specialisation representation and templating. The ADL hierarchy in Confluence shows how old the discussions on all this were. The computational differences between ADL 1.x and ADL2 are like going from C to Java.
By 2011, I had the whole thing working in ADL Workbench, except for id-coding, for which we went through a lengthy consultation; that was agreed by 2014.
By 2015, Nedap had first implemented ADL2 in Archie, and it was in their EHR product by (I think) 2018 (that’s the product that didn’t even do ADL1.4).
Around 2017 (I think), Better had demonstrated ADL2 templates in their tool; they just were not exposed to normal users.
There were of course incremental improvements to many of the features, e.g. rules to do ADL1.4 to ADL2 code mapping and so on, but the main work was specified and demonstrated in tools more than a decade ago.
I agree template versioning necessitates a discussion on the impact on composition and AQL (versioning).
A basic premise of openEHR is data is for live. So the default assumption is compositions don’t get migrated. I do agree there are reasons why you want to do a migration of compositions anyways. And that can be done without breaking the premise. (as long as the composition is properly versioned and immutable within a version, and audit logged. and each version references the -version of- the template that it validates against. And this doesn’t change within a version either).
Now the issue you raise is that updating queries because of a new template creates too much complexity for developers.
I think the issue is skillset.
Why was the same field in a new node in the template? Was the problem sufficiently understood before modelling the template? Many changes to a node can be done without breaking the path. A key breaking one is when the semantics change. But then it’s not clinically safe to return data from the same query anyways. If the samantics of the node didn’t change in a breaking way, why was the node ID/path changed?
If there truly is different semantics between nodes that should be returned in the same query. That should be transparant to the one that is (semantically) responsible for the query. If that’s too complicated for the developer, someone that understands that difference should create the query.
Which is not to say it’s your or your developers fault. Skillset issues are to me still the biggest issue in health IT.
SQL just makes the syntax/operation easier. The issue is in the understanding, the problem is abstracted away, but is that abstraction leaky..?
Now the other side of the skillset issue is that people that understand the semantics don’t understand AQL.
One interesting approach to a related issue is from Nedap. Archetypes/templates from their customer’s aren’t usually properly modelled. So a lot of breaking changes. What they build is from the front end, a path mapping. So while uploading a new version of a template where the same datapoint is now in a different node/path, you can map the old path to the new one. This is now input for the front end to retrieve both paths.
Meetinstrumenten configureren in Ons Klinimetrie : Nedap Ons® (in Dutch)
I think this concept of mapping paths can be generalised to something that also works for AQL. So for the context of a specific CDR (deployment), if two paths are mapped to be equal, an AQL for one of those paths returns both.
I’m curious for your thoughts.
This is exactly what adl2 implies. You can query either for blood pressure.v1 which means any (minor/patch/release) version of major version 1. Or blood pressure.v1.1 which means any version martching the minor version, etc. And this is what is holding up release of adl2, because the legacy data/queries is really hard to solve.
Theoretically you can even query across major versions, though that is only safe with a very high understanding of the data/templates/archetypes and queryies.
The clinical unsafety in your case is real, but to me comes from a lack of understanding of the development team. Not an issue in the openEHR spec itself. Although I do agree it’s so hard for normal developers to do safely, as a community it’s a serious issue to address.