One of the core philosophies of openEHR is the decoupling of applications and data, which results in vendor-neutral data. But recently, a question has occurred to me: templates are often not as standardized as archetypes (as the CKM focuses primarily on archetypes), and different vendors have different implementations. Since AQL queries are sometimes tied to the Composition structure, they depend not only on the archetypes but also on the specific template defined by specific vendor. Doesn’t that break the vendor-neutral promise?
The template defined by a specific vendor depends on archetypes.
AQL, and querying in general depend only on archetypes too. It’s strange to have a conduction in AQL/query that’s based on a template.
Also you might be mixing two things: one thing is the template model and AQL syntax, which specs are very much independent, and a specific template or AQL instance, which could have very custom stuff at runtime.
Can you give an example we can analyze together?
1 Like
I’d say vendor-neutral data with openEHR is an opportunity rather than a promise. There’s nothing keeping vendors from using exclusively home-cooked and proprietary archetypes either.
7 Likes
In any moderately complex openEHR systems, or indeed any EHR system, there is going to need to be some degree of local ‘shaping’ of the semi-cooked ‘standards’. This will include the use of shared archetypes, shared codesystems, shared valuesets, shared business rules and indeed shared cultural/legal assumptions.
It is always a compromise, and the kind of systems being built on openEHR can vary from a small patient-facing app to a registry datastore, to an EPR data store, to a full regional or national record. All of these will require archetypes, templates and terminology to be shaped in different ways to meet the use case.
In my experience, it is rarely ‘vendors’ who force more compromise, or try to lock up archetypes but particular realities of projects with fixed timescales, fixed resources and very often significant integration challenges with legacy data, and data quality.
As others have said, from a technical pov, we are never really querying templates, though we might be confined to querying against specific node names or compositions and terminology defined by the template.
One place we should start to do better is to introduce sets of ‘standard templates’, and this is where the work of aligning with IPS, EPS and other EHDS projects is very helpful. We can’t force people to use them but we can start to provide higher-level components, terminology-bindings and mappings that ‘green-field’ developers can use - see this post by @Seref as a great description of the approach.
Finally ‘vendor-neutrality’ and ‘interoperability’ in the openEHR world, are really not the same thing.
The CDRs provided should be vendor-neutral, such that if the same archetypes, templates, aql and terminology are used for a given customer/use case, then it should be possible to migrate that data very simply to a different CDR. We know that is possible, though still imperfect.
Getting interoperability between ‘customers’ is very much in their own hands, not that of the CDR supplier. The more they use standard archetypes, standard templates, standard terminologies and enforce their use, the more interoperable they will be, but we will never have 100% interop, and actually if we do, we have probably failed, since we have killed innovation.
2 Likes