Preprint re: SNOMED codes
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
Preprint re: SNOMED codes
EuroRec, the European Institute for Health Records, has the intention to become the neutral point of reference for several services needed around the EHR. One of those Services are an Archetype and Template Repository and Inventory. Eurorec intends to do the same for Coding Systems. This will create the stable managed environments EHR-systems and EHR's need. Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 7-jan-2007, at 2:13, Colin Sutton wrote: this points to the need to use safe URLs that will work. Do we think the URL http://snomed.org; is safe? Maybe we need http:// terminology.net or somesuch. The use of URLs whose meaning will not change over time is not to be taken lightly... [...] A safe URL is needed for each clinical terminology authority. (e.g. standards are managed by ISO, Standards Australia etc.; SNOMED UK and SNOMED AUS may have country specific needs) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070107/8e1d9bf4/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Preprint re: SNOMED codes
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 = subset = a query stored somewhere whose meaning is any kind of infection that has-site liver for example: terminology = 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,
Preprint re: SNOMED codes
Colin Sutton wrote: The query tool needs to manage this, as it should manage the language. I suggest the user (or user environment) should be able to select whether to look at local terminology or that of another country (the default may be where the patient's record was created, and the patient was travelling at the time or subsequently emigrated). the main thing that needs to be known is if snomed-ct-AUS is a proper superset of snomed-ct-INT (or however these variants will be designated); i.e. that there are no incompatibilities between the two. On storing a new event, the term accessed at the time should be stored in the record, not (just) the SNOMED code or URL, because the terminology may be updated on the server, and a future access should show the info known at the time of entry. well, snomed is designed never to change the meaning of a code, so having the code should be safe. But in openEHR we always store the code, the rubric (in the local language) and the full id of the terminology (including version if relevant). - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Problem in some sample archetypes and questions
Hi to all,
While revising my MST archetypes, I came across some confusion on the
use of cardinality and occurences. And when I reread ADL 1.4 and ADL2,
inspected the sample archetypes and then created new ones with Archetype
Editor and also tested with the Workbench my confusion got even more
increased. Here is the problem description and some questions:
As stated in ADL 1.4: Cardinalities indicate limits on the number of
members of instances of container types such as lists and sets. From a
simpler point of view, what I understand it tells the min and max
allowed number of beads (same or different beads) in a box. From a more
sensible way in the realm of clinical archetypes written in ADL, it is
used to constrain the min and max allowed number of run-time instances
of child nodes of attributes which can be a container such as CLUSTER,
ITEM_TREE, ITEM_LIST, HISTORY and so on.
So far so good but I have a practical problem to model a situation like
the following:
PARENT_NODE (A container type and might not exist or repeat up to 2 times)
a) CHILD_NODE (Must appear once)
b) CHILD_NODE (May appear 0 to 8 times)
So this roughly can be expressed as:
CLUSTER occurences {0..2}
any container attribute cardinality {1..9}
QUANTITY occurences {1..1}
ELEMENT occurences {0..8}
PROBLEM-1: As understood from above description that cardinality simply
depicts the number of instances of subchilds - REGARDLESS of their type
(i.e. QUANTITY or ELEMENT), then above cardinality can be {1..9} or
simply {1..*}. When I examine some sample archetypes such as Line 67 in
autopsy.v1, Line 33 in respiration.v1 and Line 103 in microbiology.v1
the cardinality of container node is {0..1} and they have a number of
child nodes with occurences 0 and it is clear clinically that almost
ALL of those nodes should appear in runtime data. So there is either a
misunderstanding of the use of cardinality here among most of us or I am
totally lost here :)
The above model is expressed in those archetypes roughly as follows:
CLUSTER
any container attribute cardinality {0..2}
QUANTITY occurences {1..1}
ELEMENT occurences {0..8}
QUESTION-1: What is the correct approach for above problem?
QUESTION-2: Assume in some other place in the archetype you reference
the ELEMENT node with occurences {0..8} by use_node. And in this
particular place you do not want to have up to 8 instances and but also
you want it to be mandatory (i.e. 1..) or even want {3..5}. What is the
solution? (other than writing the whole thing once again)
QUESTION-3: Related with second question, I also need to disallow usage
of some values when referencing by use_node entries. This I believe is
not an uncommon requirement in clinical medicine.For me I have an
element with a long list of values of sites of an organ (Esophagus,
stomach, colon and so on) and in many places of an observation these
sites repeat without change so I can reference original. But in some
cases selection of certain site(s) is not logical and should better be
restricted or selection of only one site makes sense. What is the solution?
Thanks and happy new year to all...
-koray
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
