Andrew Patterson wrote: >> 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. >> > > So is the URL just a name/ident for the terminology (ala XML namespaces) > or an actual "I'm a HTTP server URL, send me a GET request for some codes".. > The exact structure of the URL is the part that is currently not determined. Its logical meaning is exemplified by:
terminology = xxxx subset = a query stored somewhere whose meaning is "any kind of infection that has-site liver" for example: terminology = xxxx subset = 1234-5678-91bc-def0 Currently we have a way to write such subset expressions (significantly more complex than this) and evaluate them. If the syntax of such an expression were standardised and therefore evaluatable by any terminology service containing an instance of snomed-ct, then we would probably design the URL to simply indicate the terminology and the query id. But - since the id of the query will make sense against multiple terminologies (i.e. "any kind of infection that has-site liver" could possibly be evaluated against ICD10 or some other disease terminology) then the namespace of the queries is truly global; if not, then query namespaces are with respect to terminologies. My guess is that a few hundred will handle most questions on most forms. There will also be queries that are subsets of existing subsets. Even with a few hundred, the ids need to be well-designed (it may just be Guids as I have implied above, but then there has to be an agreed registry of subset queries, and an agreement of whether they are globally unique or not). The problem is to get some international agreement on how to approach the identification problem. Technically it is easy either way. > I can understand how the first adds no extra brittleness - but surely you > can see how the second adds more than just meaning into the > archetype. Embedded in the 'meaning' is the configuration for your > deployment environment.. so whether the URL is http://snomed.org/query2323 > or http://127.0.0.1:111/query434, the archetype now has embedded within > it a commitment to maintain that particular server, at that particular port > under that particular name running for the life of > we certainly would not want to do this - there should be no implication of a server; only of a particular query. > the archetype. If I decide to deploy a new local terminology server > 5 years down the track, do I need to get my system administrators > to load each archetype in the system and manually change the > port number of the server in all the term binding URLs? > which is the reason for not doing that. URIs properly used should never identify servers - Berners-Lee got that right years ago, it's just that almost no-one realised how important he was, and we live in a world of broken URLs rather than logically sound URIs. > It just smells a bit funny to me - I can't put my finger on exactly why > or propose a better way, but it just gives me the vibe of something > that could come back and bite people on the arse down the track. > which is why we need to be careful with this...same as for codes in terminologies (see e.g. Cimino's desiserata, or rules on good terminology design). > >> 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.... >> > > I admit I am playing catch up here and I accept that your results are > from quite a bit of experience on your part - can you give me a brief > background on the reasons for the change in thinking from > a year ago with embedded queries in the archetype to the current > thinking. > well, one obvious (to us now) reason is that the correct formal query for "any problem with site liver" might not be gotten right the first time round. If we embedded the query in every archetype that had an attribute with that meaning, then you can see the maintenance nightmare and potential for error. If we instead only have to change it once in an authoritative service (or the terminology itself, assuming the subset queries could be added to a chapter of the terminology...) then life is a lot simpler. Also, newer subsetting syntaxes might come along; again the logical meaning of the archetype doesn't change, so we don't want it to have the actual subset query expression in there, just the id of the subset. - thomas _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
