I agree with Geoff. How are you going to motivate GP's ? Except for the few dedicated GP's, 99% + will not bother about this and won't impliment it - unless of course there is a very big "carrot" indeed (a small "carrot" won't work). Then a percentage will. Just look at the fiasco when there was a big IT uptake amongst GP's because of a "carrot". Dr's just printed prescriptions with default settings etc. and the pharmacists complained about this. As mentioned prviously in one of my posts, I still frequently see prescriptions printed elsewhere where the print settings are so bad, that it is difficult reading all the stuff on prescriptions.
Even more important. Has the various software developers been contacted and kept in the loop about this ? There input / advise is vital. What about our specialist colleagues ? "GP's correctly code, but specialists exempt as they don't have PC's on their desks" are the headlines in the press !! Why once again target the GP ? Aren't specialists, hospitals etc. just as important. Cedric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, 20 July 2006 8:22 AM To: General Practice Computing Group Talk Subject: Re: [GPCG_TALK] SNOMED Project Proposal 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 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
