> 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".. 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 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? 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. > 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.... 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. Thanks Andrew _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
