Hi Bert, "I think that every leaf-node in an Archetype can be encoded in SNOMED, don't you think?"
I'm afraid not even close, especially when you take into account the changes in the meaning of datapoints that apply when used in differing contexts. When doing modelling for histopathologym I was not even close to getting 50% binding of SNOMED to archetype leaf-nodes, ands histopath is one of the better covered parts. We have been here before!! This was the whole drive of the English national program, and cost us almost 10 years of sensible progress. That is not to say that SNOMED-CT is a bad thing, just that it has to be used appropriately. At it's simplest, information models should provide structure and context 'names' , terminology provides the values. It is clearly much more complex than that but not a bad start point if we are looking to play to the strengths of each. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 29 April 2016 at 17:37, Mikael Nyström <[email protected]> wrote: > Hi, > > > > I can just add that those entities Tom mentions below as > > > > “The waters are muddied further by the attempts to represent > informational, timing and context-related entities in SNOMED CT.” > > > > Are the clearly separated sub-hierarchy called “Situation with explicit > context” ( > http://browser.ihtsdotools.org/?perspective=full&conceptId1=243796009&edition=en-edition&release=v20160131&server=http://browser.ihtsdotools.org/api/snomed&langRefset=900000000000509007) > and that sub-hierarch contains only 1 % of the concepts in SNOMED CT. It is > therefore no problem to use SNOMED CT without these concepts for those who > want to do it. > > > > Regards > > Mikael > > > > > > > > *From:* openEHR-technical [mailto: > [email protected]] *On Behalf Of *Thomas Beale > *Sent:* den 29 april 2016 16:43 > *To:* [email protected] > *Subject:* Re: SNOMED > > > > Hi Bert > > Erik and Ian partly answered this, but it is always worth remembering that > SNOMED CT, if based on proper ontological principles, contains assertions > that represent entities in the real world. This means taxonomy (IS-A) and > properties, qualities, possible relationships and so on (see BFO2 > <https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjkjrG8hrTMAhWEWxQKHc_dDsIQFggcMAA&url=https%3A%2F%2Fbfo.googlecode.com%2Fsvn%2Ftrunk%2Fdocs%2Fbfo2-reference%2FBFO2-Reference.docx&usg=AFQjCNFaciudhkU555FkqpQscrO0rRJUmQ&sig2=wWITHga_L6Vp1RTU4lvEEw&bvm=bv.120853415,d.d24>for > a modern top-level ontology providing these ideas). These are properties, > qualities and relationships of real things in the real world, i.e. actual > hearts, cardiac arrests, disease types and so on. > > The openEHR RM and derivative archetypes are built to represent > information 'about' these real things. The relationship is often written as > 'is-about'. There are important differences to be aware of: > > - what information is written 'about' many things can sometimes > resemble a description of the thing itself, e.g. parts of a colonoscopy > report tend to follow anatomical structure of colon and things found in it; > - sometimes it relates to a surrogate phenomenon, e.g. an archetype > for heart rate that actually records pulse; a great deal of clinical > observation is of surrogates e.g. state of skin, palpation, heart sounds, > asking about pain, blood glucose etc, but they are actually about something > else; > - what gets recorded can be what is cheap and painless to record; > consider that we don't do an echocardiogram every time you want simple BP > or heart rate. > - what gets recorded about X can be culturally determined; different > in other ways from 'how X really is' in nature. > - most important: most clinical data recordings don't replicate > 'textbook' relationships found in an ontology, e.g. the fact that there are > 5 heart Korotkoff sounds at different phases of the cardiac cycle will > never be written down by a physician, neither will the fact that systolic > BP is-a pressure of blood in a vessel is-a pressure of fluid in a vessel > etc. So if we were to generate an information structure from part of an > ontology representing the heart / CV system, it would generate numerous > useless data points and relationships on the information side. > > How well or how much SNOMED CT follows underlying ontologies like BFO2 or > Biotoplite or whatever is another question. I am not up to date on the > progress, but I am fairly sure that most of SNOMED has not been validated > against these kinds of ontologies. The waters are muddied further by the > attempts to represent informational, timing and context-related entities in > SNOMED CT. > > Thus, my view is that: in principle, generating information structures > straight from an ontology (even a perfectly built one) will simply never > work, for the reasons in the list above; in practice, what you would get > from SNOMED CT, given its imperfect adherence to ontology would be even > harder to understand or use. > > - thomas > > On 29/04/2016 07:50, Bert Verhees wrote: > > Hi, > > I got an idea when reading the nice story from Heather on LinkedIn. In > fact it is hers idea, but in a opposing way. > > https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie > > https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie > > I wonder in how far it is feasible and useful to create archetypes from > SNOMED concepts, it would be possible to generate them, with attributes and > so on. > In a few hours time, one would have a complete forest with archetypes, > including ontology in more languages. > Maybe some smart handling, filtering, combining can create a better > collection, also looking at the paths, so that there are similar paths for > similar situations, to keep the number of different datapoints low, which > can help creating a faster key-value storage. > > I don't know how it is about copyright, with members, and licensing, that > should be looked at. > > The argument that SNOMED is fragmented should not count, I think (however > without having an expertise on this), because, when working with > handwritten archetypes will always be incomplete and fragmented. > > Bert > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
