I am forwarding the following message from Prof Jon Patrick (fromt the School of IT at Uniiversity of Sydney) to this list (but I'll encourage him to subscribe directly to the list). Responses to this list if appropriate with a CC to Jon at [EMAIL PROTECTED] please, or just directly to Jon.
My comments on Jon's missive appear below enclosed in triple square brackets. Tim C >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am writing this response to let the members of the GPCG_talk list know of the research we are doing with a number of groups on the utilisation of SNOMED CT (SCT). My area of expertise is Language Technology and Information Systems. The National Centre for Classification in Health (NCCH), which is hosted by University of Sydney, has asked me to assist it in harnessing SCT for its needs and to investigate ways in which it could be utilised in a range of Health areas. Our first approach is to 1) Understand the organisation of the SCT distribution files, 2) work on automatic and semi-automatic methods for mapping SCT to ICD10AM. Also the Family Medicine Research Centre has asked us to investigate the same tasks for mapping SCT to ICPC-2PLUS. These engagements have drawn us into a number of broader tasks with SWAHS and NSW Health (with Tim CHurches) to investigate a range of text analysis methods for medical records both in General Practice and Emergency Depts. This summer we have had funding for 10 advanced students to work on various aspects of these problems plus other work on automated Information Extraction from published Case Studies, and generating analytics for Patient Safety data. I am in a School of IT and my staff and students have a variety of competencies in Information Systems and hardcore IT while I have a background in IT, Lingusitics and I'm a registered psychotherapist (Vic). In summary we are a group of IT people who would like to try to make a contribution to Health Informatics. To deal with some of the specifics of the previous emails: Tim Churches <[EMAIL PROTECTED]> wrote: >Ian Haywood <[EMAIL PROTECTED]> wrote: >> Tim, I noticed you and several others are using SNOMED >>as an abbreviation for a "clinical coding system". > >SNOMED CT is a "clinical terminology" to be precise, or a >"clinical concept >coding system" if you like. It needs structure >superimposed on it to create >higher level coding and classification systems. I think the SCT people would not be happy with this characterisation of their work. They say it is an ontology which means it incorporaes both a terminology and a classificatory structure, plus you can do logic processing over the hierarchical structure of the classifications. [[[I agree that SCT comes wrapped in an ontology, but that is not the only ontology with which it can be used. There are other ways of organising and relating SCT concepts to each other. For example, the base SCT ontology is not very useful when dealing with, say, general practice presenting problems, but the low-level clinical terms contained in SCT are extremely useful in describing such problems. What is needed is an alternative, GP-presenting-problem-oriented ontology (or classification system) to be imposed on top of all those SCT concepts (at least, on the relevant concepts out of the hundreds of thousands contained in SCT). I dare say that a mapping between SCT and ICPC2-Plus is a rather major step towards that goal.]]] >Having used it in anger over the last few months (for >communicable diseases >work), my take is that it is an adequate system, rather >patchy in its depth >of coverage, with uneven degrees of pre-coordination, but >yes, better than anything else. I would most grateful to know exactly how you were using it - understanding current utilisations are important to our work. [[[Using it as a terminology for coding microbiological, serological and NAT lab results for notification of communicable diseases for public health surveilllance purposes, and also as a source terminology for a nascent ontology/classification scheme used to describe population health activities and practice. It has proven to be OK (but with room for improvement) for the first of these uses, and just woeful for the second. But it can be improved, and teh College of American Pathologists seems very open to input, particularly in areas which are very underdone in SCT, such as population health.]]] >As David More notes, a national license seems imminent. >If not, then I >agree, all bets are off with respect to the widespread >use of SNOMED CT. >The other concern has been intellectual property rights >and governance of >national versions and enhancements. I understand that the >owners of SNOMED >CT, the American College of Pathologists, have recently >acknowledged these >concerns (voiced by many countries) and have gone a long >way to allowing >local governance and the escrow arrangements needed to >ensure ongoing >access (but the deatls of this are very important and it >would be nice to >know what they are - NeHTA has been handling the >negotiations, I >understand - let's hope they have been tough and have >stuck to their >guns). As I have said before, it would have been much >better and quite >feasible for Australia to have developed its own clinical >terminology had >we started back in 2000, but we missed that boat. > >> It's important to differentiate the use-cases for coding >>clinical data. >> At individual patient and GP level they're pretty >>limited: some basic >> decision-support around drug-disease warnings, possibly >>linking to >guidelines. > >That's not really limited - I can conceive of that sort >of decision support >going a very long way and becoming rather sophisticated, >eventually. We do not intend working in the area of Decison Support Systems but we are interested in the problem of data capture of text/speech used at the point of care and automating its transfer into SCT concepts(1 project), then its storage in an EMR (2nd project) and its extraction for retreival (3rd project) and analytics (4th project). >> It seems (please correct me if I'm wrong) this can be >>done perfectly >> well, or rather, well-enough, with simple keywords (i.e. >>using English as >your >> coding system) > >Only if everyone uses the same keywords. Which is where >SNOMED CT comes in, >because it provides a very comprehensive, standardised >set of keywords, >which can then be replaced by a SNOMED CT ConceptID >(complete with built-in check digits) This is the direction of one of the research efforts. >> It doesn't seem fair to make GPs buy SNOMED when they >>aren't the main >> beneficaries. > >I agree. If GPs or other users have to buy SNOMED CT, it >won't fly. But the >cost of an all-of-US perpetual license (with updates for >for 5 years) was >US$35 million, so the cost of a similar license for >Australia should be >approximately one fifteenth of that. In the big scheme of >things (eg >compared to the $70 billion annual health budget for Oz), >that's >chickenfeed, and is little more than the cost of a few >consultancies for >the Feds. > >> There's no reason why the data collectors can't be the >>ones writing >> cheques to the US pathologists and >> develop a mapping to the keywords already in the >>database. > >The problem is that it is hard to map "tibia" to anything >other than >"tibia". If the terms of a national perpetual license for >SNOMED CT are >satisfactory, why bother? If the terms are not >satisfactory, then I agree, >we should aim to build a long-term substitute for SNOMED >CT by leveraging >it in the short to medium term. I would hope that a good implementation would keep the terminological service in the background so that clinicians didn't need to know what they were using - it just worked for them. This is one of the lines of investigation with NCCH and FMRC. How do you deliver a SCT type of beast into a working Health Information Management System in an automatic way? >> We should, at the very least, keep an EHR >>coding-system-agnostic, so GPs >> can buy SNOMED, DOCLE >> or whatever (or have it bought for them) if, and only >>if, they need it. > >The technology and information model behind SNOMED CT is >fairly simple, so >it may be possible to build terminology-agnostic EHRs etc >- that is what >openEHR claims to be able to do. I am unconvinced of this >(the >terminology-agnostic aspect) until I see it work in >practice. But systems >like DOCLE is so much more ambitious in what it aims to >do, comapred to >SNOMED CT, that I don't see how it can easily be >substitutable. The DOCLE >codes, maybe, but not the full DOCLE encoding system, >which commendably >tries to capture semantic relationships between >terms/concepts (albeit in >a very idiosyncratic and funky way). > >> Of course the government should buy a nationwide >>licence, but, like >> OpenEHR kernels. it's unwise to rely on that happening. > >Agree, but as David More says, we may not have to wait >too long. In the >meantime, anyone can get access to a full version of >SNOMED CT through the >US National Library of Medicine UMLS initiative - see >http://www.nlm.nih.gov/research/umls/ You can't use that >UMLS-provided >copy of SNOMED CT in commercial information systems, but >you can certainly >examine it and do "research" with it in pilot settings. >There are several >free tools (eg the CLUE browser) available to work with >it, but it is a >piece of cake to write some Python or other code to slurp >it all into >in-memory or shelved dictionaries etc to make it easy to >work with. We have already done a lot of work processing the SCT tables to understnd their structure. By the end of Feb I hope we will be able to make some concrete reccomendations to NCCH and FMRC. In the coming academic year I hope to engage Honours students on building prototype OpenEHR systems for GP and ED contexts. They will be made available in Open source. Your contributions and advice would be most welcome. cheers jon ------------------------------- Jon Patrick Chair of Language Technology School of Information Technologies University of Sydney Sydney, NSW, 2006, Australia _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
