Thomas, I fully agree, as you know, already.
Gerard Gerard Freriks +31 620347088 [email protected] <mailto:[email protected]> > On 29 apr. 2016, at 16:42, Thomas Beale <[email protected]> wrote: > > 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-i-heather-leslie> >> >> https://www.linkedin.com/pulse/journey-interoperability-part-ii-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] >> <mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> <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
