Yes indeed - meant 2.0.1
The problem I was talking about was with deployments using EHRbase and just plain openEHR REST APIs. Don’t want to bring in my work on openEHR on SQL / Postgres into this conversation.
We really have to pick between these 2 evils:
- migrate all compositions to the new major version OPT. This approach seems impractical due to the volume of data requiring migration .
- Adding a new OPT version and archetype versions to all AQL queries. This approach seems impractical because application and query complexity will keep growing. It’s also clinically unsafe if not done well.
Now I would really like there to be a magical 3rd option where openEHR “semantically” figures out the meaning of an AQL and propagates it down to older versions of the archetype / template etc. But it just opens up another surface area for bugs.
Maybe some smart people can really sit down together and figure it out? But then the semantics of AQL itself might change. Instead of querying for :
select systolic from observation o [blood_pressure.v2]
maybe we can now do
select systolic from observation o [blood_pressure.*]
But this isn’t possible today because the paths between these different archetype versions aren’t the same.
Maybe in the future, template IDs can be queries semantically with a wildcard on the version. But then someone really need to make sure these semantically meaningful “paths” remain consistent.