Andrew Patterson wrote:
This is a point of view on archetypes that I had never really considered. I had always assumed that the construction of the archetype definition and the selection of terminology binding would be part of the same process, either done by the same person or the same clinical group. The paper discusses some of the mapping problems that can occur when this process is split, but surely that would never be the case?
the process can easily be split and is likely to be so, e.g. in environments like the NHS where there are separate teams of experts for clinical modelling and archetypes. There are other reasons as well:
- an archetype is instantly usable even without terminology binding being figured out; it may be that prototype testing or a non-terminology enabled rollout is required
- many things in the ‘ontology’ section of an archetype come after the main modelling exercise: translation, addition of other term bindings; adjustment of term bindings
- an archetype may be published in a ‘vanilla’ form, with term bindings only being added in local situations (although clearly an internationally agreed binding to internationally use terminologies is preferable).
The intention would be that within some master archetype repository (be this a local/organisational/national repository), the archetypes would include a full set of terminology codes?
the archetypes would only include some cods that are direct maps for the ‘at’ coded terms in the archetype. But for attributes where the value (i.e. the answer) is a term value set from a terminology like snomed, the approach is to us an ‘ac’ code to refer to a query to the terminology service, whose result when run is the subset from which the user is allowed to choose at runtime. This query is stored in a terminology query service, only the id is referenced in the archetype.
(I can understand how one might think this because none of the sample archetypes in the openehr repository have much terminology data but that will surely that is a temporary situation and the intention is that a real official repository i.e. one run by nehta or nhs etc would have the term codes for their realm?)
correct - but not because of the lack of the archetype repository (one is under construction); the reason is that the community has not yet settled on a way of identifying or expressing subsetting queries to a terminology service; good progress is being made here; at Ocean we have developed a simple language to do it, which turns out to be very nearly the same semantics as the OWL-based expressions described by Alan Rector at a recent Semantic Mining meeting in Paris at which we were both present.
Which brings me onto a related point - at the snomed workshop in Melbourne late last year there was an (impressive) demonstration of some of the template building tools written by Ocean. Part of the demonstration involved creating a complex binding to snomed based on a small query language (effectively the query was "select all 'is_a' children of this snomed code up to a maximum depth of 5").
right - this is the language I mention above.
This query binding was placed into the relevant archetype as a URL reference to a webservice. Doesn't relying on a URL in the ADL definition make archetypes quite brittle. i.e. when the archetype definition is loaded into the clinical system I either have to consult the URL straight away and store the resulting codes, or else delay the binding and risk having the terminology codes for my ADL disappear in the future?
why would that happen? This isn’t semantic brittleness in the archetype - the meaning doesn’t change; it may be that you don’t have a reliable deployment environment. This is why we built the Ocean Terminology Server to provide a query cache for any user site.
It just seems to me that if snomed is indeed the way things seem to be going, that most terminology references in ADL will either very simple (this node = 34242343) or need a moderate level of complexity (all nodes in the 'is_a' 'route of administration' heirarchy, but not ones with a qualifier 'blah'). Will all these later style terminology bindings need to be done with URL's?
URLs won’t include the query statement itself (originally we thought they would, but having built a full terminology server and query subsetter has taught us otherwise); the URL will just include an id of the query. Working out an identification system is the next trick…
Isn't it going to be hard to keep these URL's alive for the lifetime of the archetypes? On the other hand, if the URL's are bound on archetype entry, how will they keep up with changes to the terminology? Should there be a small query language for terminology built into ADL?
as I say, that’s what I thought we would be doing a year ago; experience has shown that we need to push things apart by one further level, and only allow subset query ids in archetypes (remember - these are what is mapped to the ‘ac’ codes; you can still put snomed or whatever codes in the ‘at’ code binding part if you want).
None of this is simple and it has taken both us (in the industrial context) and the Manchester group over 5 years from the statement of need to get to a solution - which looks quite simple now we seem to have it (or be close), but I have to admit, we were groping in the dark for a long time…
- thomas beale