[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
