Andrew Patterson wrote:
Ok, this definitely makes sense to me. The only trick now is to work out a
way of fitting it into the archetype (and agreeing on a suitable
postcoordination
format - I get the sense from the snomed documentation that even the
snomed people aren't sure what the best way is).
they are working on the syntax, although it seems relatively solid at the moment. We are also working collectively within the NHS-sponsored Technical Advisory Group (TAG) on this. David Markwell is currently authoring an in-depth report on how to bind such exprssions to archetypes, and we are looking at what changes are needed to ADL etc to allow it to happen. There is a relatively simple change that would allow an expression rather than a single code on the right-hand side of any binding expresion that you currently find in an archetype - most likely that at least will happen, so you would get lines like the following in the ontology section:
term_bindings = <
[Snomed_ct] = <
[at0012] = <[417597005 116680003=250412004,363714003=282288009,418775008=271348005,363714003=15220000]> – Urine dipstick test finding (finding) is a = Dipstick test finding (finding), Interprets (attribute) Microbiology interpretation(observable entity), Finding method (attribute)=Urine dipstick for pH (procedure), Interprets (attribute)=Laboratory test (procedure)
Now I don’t know whether this expression is one that you would actually use, but regardless of the details, there are some interesting issues:
- can we accommodate the expression syntax as an RHS value in a binding line in an archetype? As long as there can be no characters, it seems that we can
- how should we render it? I have used the purely coded form above, with the meaning taken out as a separate comment. This does raise some questions about how the natural language vresion shown in the comment should actually be rendered - currently it could not be reconstitutable back into the original structure due to the lack of delimiters on each term phrase (“Dipstick test finding (finding)” etc). Does this matter?
On a broader topic, is there any intention to add bindings for common
terminologies
into the 'release' archetypes that will go through the archetype governance
process? If not, at what level are people expecting that terminology bindings
will be added (local templates, or customised 'national' archetypes?).
this is a tricky question, not least because of the ambiguities and errors in Snomed. This very question you raised, and many others I have come across in discussions over the years make it clear that what you think is going to be a 1-minute decision on what Snomed code to use for some typical clinical data item…turns into a 3-hour debate. There seem to be two reasons for this:
-
errors in Snomed. These are in theory fixable, they just have to be found and proper design logic applied when coming up with a fix. There are quite a lot of errors based on my own experience, one hopes they are fixable in a viable time.
-
‘ambiguities’ in meaning. This is where the meaning in Snomed doesn’t ‘quite’ match the meaning of something with a similar or same name in an archetype or other information model. I believe this is partly because Snomed was originally constructed as an ‘ontology of reaility’, otherwise known as a ‘model of meaning’ - i.e. a structural description of categories of things in the real world. However, it does not do well on describing informational items, and the problem is that some information items, e.g. “urine glucose” (meaning recorded measurement of urine glucose level") are not quite the same thing as the same thing in Snomed (meaning “actual level of glucose in urine of subject”). Snomed also includes numerous pathology test variants of the general phenomenon, hence the codes in your example above.
Personally I believe that we need a basic rule for saying that “archetypes record data points of the form ‘recording of measurement of X’” whereas Snomed contains a code point for X. As long as we are convinced that we are talking about exactly the same X, then at least this class of ambiguity goes away (same argument for thingst like “recording of ‘recommendation of X’”, “recording of ‘order for X’” etc)
Going further, I think Snomed needs to have a clearer theory of notions like: measurement of X, target value of X, recommended P, ordered P, (no) risk/(no) history/(no) family history/diagnosis of D. In my view, every code point in Snomed should correspond to either a phenomenon or a category in the real world. If X is “urine glucose”, it is clear what phenomenon it corresponds to. If D is diabetes, it is clear that the category which would classify some individuals is “diabetes sufferers”. Something like “no risk of breast cancer” is a fiat category, stated by physicians, although it probably does have an (unknowable) real boundary in the real world. All this leads to the need for Snomed to have a proper biomedical ontology underpinning it…but I don’t think there is one. Without such an ontology, there is no rigorous ability to decide what the real meaning of any concept in Snomed atually is.
Some thoughts relating to ontology and openEHR are here - http://www.openehr.org/wiki/display/ontol/Ontologies+Home See Barry Smith’s page at http://ontology.buffalo.edu/smith/ for many papers on biomedical ontologies.
