[EMAIL PROTECTED] wrote: > Quoting Ian Cheong <[EMAIL PROTECTED]>: > <snip> >> We're talking about a product with a high need for integration, which >> absolutely depends on the clinical data in the local system, where >> poor performance will make users switch it off, where bandwidth >> availability is variable, with a relatively small data set updated >> probably on 3 monthly cycles, interacting with a prescribing database >> which is updated quarterly, which absolutely has to be properly QA >> tested prior to release. >> >> What's the perfect solution for that? a web service???? >> Ian. > To this "drug interaction server" function needs to be added a "terminlogy > server" of similar functional requirements for the delivery of SNOMED, > ICD, etc with the requirements of: > After initial installation - small updates > Updates periodically (say 6 monthly) > Has to interact with vendor software. > > This sounds like a need for a more generic view of "content servers" for > working information systems. > > Ian, I'm unsure why you are cynical (if I've read your comment correctly) > that web services can't deliver relaibly under these constraints. In terms > of volume and throughput they are not very demanding on the bandwidth?
Bandwidth may not be a problem but latency is. What really counts is the perceived round-trip time for the transaction with a Web service. Latencies of a few seconds are typical, and latencies of tens of seconds or more are common. That tends to be acceptable (but a bit annoying) if you are browsing Web pages, but unacceptable if you are trying to finalise an electronic prescription with a waiting room full of impatient patients outside... The other thing is that we shouldn't confuse "Web services" with SOA (service-oriented architecture). The idea of using SOA as a modular and fairly standardised way of delivering functions to a range of applications is sound, but there is no reason why the "services" in an SOA need to be remote - they can (and in many cases should) run locally on the practice LAN/intranet, within the confines of the practice firewall. Both terminology and drug interaction services should definitely be built with that form of deployment in mind. Those internal services then periodically (and automagically) download updates from a remote, more centralised service. MS-Windows users should consider how virus checking on their PCs is done - typically virus definition updates are automatically fetched from a central provider to their local PC and the virus checking service on their PC uses these updated definitions. Terminology and decision support services should work the same way, allowing them to be as reliable as the LAN/intranet is, which is usually rather reliable (and orders of magnitude better than the reliability of Internet connectivity, with consistent and usually low latency). Also, there is no information leaking out to an external service provider. For example, if NPS were to set up a drug interaction service using a centralised Web service model, then each practice which uses that service is essentially handing over to the NPS a complete record of what drugs its doctors are prescribing. As Geoff Sayer can attest, such information is commercially valuable. Now NPS may have no plans to make commercial use of such information, but the fact that such data would be at their disposal means that adequate trust relationships, backed by data usage and privacy agreements etc etc, need to be established between each practice and the NPS. Better not to send the data at all, and rather have the NPS send updates to locally-running services which do the interaction checking. Leakage of private information and the need for strong trust relationships is also a major issue with terminology services. This notion of a locally-running SOA is predicated on licensing arrangements for drug interaction databases, SNOMED-CT and other resources which allow distribution to many thousands of end users (eg GP practices), rather than having just a single copy and every having to send their data to it. Of course, aggregated, or selective unit-record data can still be sent to a central provider to help them refine and improve the drug interaction or clinical terminology or whatever other service they provide, but there is no need for *everything* to be sent to them as a matter of course. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
