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? 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.
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) 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) > 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 ;-) 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. 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. IanH _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
