As an example of how not to try to do things ... http://www.kith.no/upload/6407/HelsIT-2011_T2-2_Laura_Sato.pdf
#fail 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 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-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
