Hi Geoff, I accept what you say about the GP world needing motivation. As for migration tools I would hope that the Text-to-SCT converter we have created would be seen as the start to filling that role. Now with the release of the general license I expect we will be able to a switch over to delivering SCT codes on-line, so you will be all be able to see it working easily. I am visiting NEHTA today to open discussions with them directly about our work and how we might be able to collaborate with them. cheers jon
Quoting Geoff Sayer <[EMAIL PROTECTED]>: > Hi all > > This all assumes that "average" GPs care about terming, coding and > classification... evidence would suggest the contrary. > > Nearly all the GP clinical apps have controlled medical vocabulary > already > (and some have classification capability to international standards > already) > yet I have never heard a GP say (one that doesn't subscribe to GPCG)... > > "If only I had SCT I would record reasons for prescribing and provide a > complete/current patient medical history... it was the lack of a > suitable > medical vocabulary that was holding me back" > > I think a standard is important but the fundamental lack of interest > amongst > the masses remains the same... I can hear a deafening silence from the > mainstream on this development... > > We need to think about selling what the benefits of SCT will be to the > end > user from a day to day practical perspective... and great for research > won't > wash... > > What will it mean to those GPs who have recorded data > inconsistently/consistently over the past number of years... got some > migration tools ready to bring into the new SCT era or do we right of > the > past... > > What will it allow GPs to do now that they can't do now? > > This type of information on benefits may inspire vendors as well I would > suggest. > > Geoff > > > [EMAIL PROTECTED] wrote: > > Quoting Tim Churches <[EMAIL PROTECTED]>: > >> 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 > > Tim, is it your intention that this evolve towards a "SNOMED module" > > which can be served up to vendors on a platter, ready for integration > > into their own products? > > Yes, exactly. By having the software module as cross-platform open > source and the SNOMED-CT data freely available to all under the NEHTA > sublicense, it would exert competitive pressure on clinical information > system vendors to either incorporate the module into their software or > to provide something better. > > > Hopefully this will partly answer the "it's too hard" excuse from > vendors > which > > has stymied other attempts (as Ken Harvey knows) to get > decision-support > into > > the GP's desktop. > > Yup. One less excuse. > > > For true integration you would need a local server otherwise the > > EHR would experience a performance hit (to which users in this domain > > are exquisitely sensitive) > > Yup, that's what I proposed. > > > Would you consider the LGPL licence, as this allows integration > > but requires vendors to contribute back changes (to the module). > > I agree BSD-type licence is much simpler and would be more reassuring > > to them legally (even Microsoft use BSD licensed code) > > Either LGPL or Mozilla licenses would be fine - they are functionally > equivalent in that they both require changes to the open sourced code to > be contributed back to the community, but neither presents any > impediment to tight integration of the open source code with closed > source code in a vendor's product. BSD would also be OK but less > optimal, although likely to be more favoured by closed-source vendors > since it does not require them to make any enhancements they make tot he > code available to others. After seeing how well the development of the > PostgreSQL open source database proceeds using a BSD (non-copyleft) > license, I am a lot more relaxed about the whole copyleft thing than I > used to be. Ultimately it is up to Jon Patrick and his team at USyd how > they might license the proposed modules, but I would strong recommend > that they don't use the GPL, which would be sure to discourage other > software vendors from using the modules. > > >> Automatic periodic refreshing across the Internet of the Web service > >> software code and the SCT data which it uses should be built-in. > > ^^^^^^^^^^^^^ > > > > I agree with auto-updating the SCT codes, but the software itself? > > The could get needlessly complicated if done in the first iteration of > the > > > module. IMHO users who want such a facility should select an OS that > provides > > it ;-) > > Yes, probably. I suppose I had in mind that the modules might use > various soft-coded rules or other parameters which could be updated > dynamically from time to time, rather than the compiled code. Whatever. > > > A client-side module which regularly (say ~1/month) polls the central > > SCT webservice for updates would be simpler to adminster, as well as > faster, as > > it saves the GP the adminstrative overhead of running a dedicated SCT > server > > on their own network, at the cost of some bandwidth (as each client is > > independently updating) but this would not be significant given the > size > > of the data. > > Yup, that would work. > > > The question then is what interface to provide to the EHR. A C > interface > > (that is, "DLL" on Windows) is the most widely-acceptable solution, > this > is how > > HeSA provide their module for HIC Online. You could also use > .NET/Mono, > but I'm > > not sure how many EHRs are written in .NET at present. > > I have nothing against webservices per se, but it's important not to > let > > them be a solution in search of a problem, there may be simpler and > more > > appropriate options. > > I only suggested that Jon mention "Web services" at every opportunity to > keep NEHTA happy... BTW, Argus Connect should re-write all their > promotional material to say they their products uses Web services (and > in very, very fine print mention that the Web service runs on port 25 as > a Simple Mail Transfer Protocol service). > > Tim C > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
