[EMAIL PROTECTED] wrote: > Dear List, below is a text describing a project I intend offering to my > students for the coming semester. I would be grateful if you could make > any additions or comments to enhance the specification. Acknowledgements > to Tim Churches for his contribution to the text. > thanks > Jon > > Web Interface for Maintaining Medical Ontology, SNOMED CT > Introduction > With the adoption of the ontology SNOMED CT (SCT) by the Australian > Government for reporting clinical content a brand new sub-market in > SNOMED-CT-related health IT software has opened up overnight in Australia. > The aim of this project is to provide an open source system to support its > adoption. > > Aim > To build a Web-based SNOMED-CT browser/search facility, perhaps using some > nifty Web 2.0/AJAX methods to provide good interactivity. At the moment, > most SNOMED-CT browsing is done using a free (but not open source) Visual > Basic GUI application called CLUE (see > http://www.clininfo.co.uk/clue5/index.htm ). A SNOMED-CT look-up facility > as a Web service licensed under an open source license which permitted > integration with both open source and closed source clinical applications > (i.e. Mozilla, BSD licenced) is needed.
Just to clarify the architecture that I had in mind: a) most of the look-up and other functions exposed as Web services which can be called from any Web service-aware application, including GUI desktop clinical applications b) a separate Web browser front-end that uses those Web services, to allow browsing of SCT from anywhere there is an Internet connection Ideally a) should be implemented using a cross-platform technology to allow deployment as a Web service running *inside* a GP's firewall i.e. on the LAN, where the vagaries of Internet connectivity don't matter. Automatic periodic refreshing across the Internet of the Web service software code and the SCT data which it uses should be built-in. There would also be room for another project, c) a GUI browser for installation on desktop PCs which also uses a) for data and smarts. There would seem to be a wide range of interesting and challenging computer science design issues to be addressed in the above, from knowledge engineering and natural language processing through software engineering and programming to human interface design. If I were a computer science honours student I'd be champing at the bit to work on this sort of thing, particularly when it is almost certain to see real-life use, both here in Oz and overseas in other SCT-adopting countries. > The system should also provide for a number of other functions needed to > maintain it and support particular users, such as: > Specialist subsetting > Subsumption testing over all transitive relationships > Inheritance mapping > Hierarchy visualisation > Minimum Network presentation > Integration with the current Text-to-SCT processing system Sounds good. Some sort of shared workbench for groups working on subsetting or maintenance tasks would also be desirable after the initial infrastructure was established. > Comparison to other Systems > The problem with the CLUE browser, apart from its general clunkiness and > not terribly smart look-up facilities, is that it needs to be installed, > along with the SCT data files, everywhere you need to use it. > > Another product MyCroft that maintains SNOMED CT is produced by Apelon > TermWorks and may give further ideas on utilities see > http://www.apelon.com/ . MyCroft is their free (but not open source) desktop terminology/classification browser. TermWorks is their fully-fledged terminology/classification workbench. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
