Adding a new major archetype/OPT version causes issues you described regarding AQL. Adding a new OPT version to all AQL queries is one way to handle this (it doesn’t require data migration).
Another approach is to migrate all compositions to the new major version OPT. This approach seems impractical due to the volume of data requiring migration (and the OPT authors not providing a migration plan).
Neither scenario is ideal for the users. In practice only the AQL scenario is available to the clients. The consequences of failing to update all AQL queries are real. I’m not a fan of putting the full burden on the clients. I also believe it will be bad for the openEHR image.
One way I’m exploring to mitigate these issues is storing archetype data using inheritance. For example tables for blood_pressure.v1 and blood_pressure.v2 inherit from the blood_pressure table. This allows using the version-less archetype name in queries (the database includes the data from the v1 and v2 tables). When a new major blood_pressure.v3 archetype is introduced, most queries will continue to work and will include the data for the new version. The good thing is that the queries will fail loudly instead of continuing to work while silently ignoring the v3 data.
The above works only if the new major version didn’t “break” the structures used in the queries. In other cases, the CDR could try to handle it by introducing alias fields and other technical solutions to the version-less archetype table. Some cases will still require changing the queries or migrating data. I would just like to investigate how much the CDR can help with new major archetype versions at a “technical” level.
I’ve been thinking about the idea of ‘semantic aliasing’ as a way of helping here, coming out of some ideas in the ADL2 transition.
The idea is that you carry an assertion in an archetype that says semantically i.e path fidelity, archetype A (e.g. the ADL1.4 bp archetype is query-safe to be treated identically to a specific ADL2 equivalent).
This allows a reference to openEHR-EHR-blood_pressure.v1' to be cross -queried with org.openehr::openEHR-EHR-blood_pressure.v1.3.1` without doing very risky wildcards on namespaces.
Something similar could be used in, in combination with local Entry level specialisations/ embedded templates, which have explicitly constrained out any nodes which have been changed in the new archetype version. So I am confident that even though I am now using the v2 archetype to store new data, I can assert that for querying purposes, my local specialisation/constraint is path equivalent to V1, and existing queries will still work (with some smarts inside the CDR).
The way to do that in my view is to add ‘is about’ codes on each node, which indicate what real world entity it is about, such as ‘heart rhythm’, ‘heart pressure at systole’ etc. These definitions need to come from an ontology. Snomed is probably a sufficient short term solution. Another code is needed to indicate ‘epistemic status’ or similar, that distinguishes between things like ‘target’ heart rate and ‘actual’ (measured) heart rate.
With these codes either in the data or at least on the archetypes, a query engine can find all actual systolic pressures over the last 3 months regardless of whether the data shape and archetype codes are from the ADL1.4 archetype or the ADL2 archetype.
If you think about it, the above is the same as your ‘assertion’, except more general, since it asserts that this path P1 in this archetype A1 is about some canonical X, rather than just being the same as this path P2 in archetype A2.
Yes, Ian. I believe “some smarts in the CDR” could help users migrate to newer major archetype versions while assuring them that existing queries will keep working predictably.
I would rather see that the queries fail than silently return incomplete results.
If no action is taken, users will delay switching to newer and better archetypes.
‘Ontologcal assertions’ are definitely helpful - came across an example yesterday when reviewing the Visual Acuity archetype. However it does require a fair bit of effort to ensure that the correct terms are both avaiable and accurate. Example A - the ‘Blood pressure’ SNOMED code used in FHIR ‘official bindings’ is IMO at the wrong place in the hierarchy. Not criticisng - it is a complex area but it’s not a ‘quick fix’ at least at scale.
My approach is, I think easier to apply locally without having to get too deep into ontological debate, dependency on terminology discussion.
Not fully thought through but I agree with both approaches
This “ontological” approach was already used in practice and I liked what this “is about” coding enabled. In my case it enabled a rules-based synthetic data generator. FHIR to openEHR mapping would be another candidate. I can imagine how it would also help ensure existing AQL queries work with newer archetype versions.
Path-based “semantic aliasing” would work too, but it would require manual work for each archetype. With “is about” codes, many things could be automated and used independently of a particular archetype.
I haven’t fully thought this through on my side either. Especially as it will take at least a decade for the healthcare community to agree what are the correct codes to use (like your FHIR example)
