Thanks to Tim, Horst and Len for details that assist me in moving away from my own narrow confines. My proposal was not meant to be web services in the sense of sending data to a remote wed page for processing -I didn't dream of it. In terms of converting clinical notes to SNOMED you can only do that in real-time - this means the service has to be done on the clinicians desktop (or local LAN), likewise I had assumed an drug interactions server would need to run in the same way -hence I fully concur with Tim+Len's model. In my message I was trying to introduce the notion that there is something generic going on here that we might be able to exploit for efficiency's sake, that is a general "content server" that once installed on a host machine only needs to be updated (like virus software) for each change in each of the content databases. How many such databases would you be likely to needed, starting with these three. 1. Drug Interactions 2. SNOMED CT 3. ICD-10AM
cheers jon Quoting Tim Churches <[EMAIL PROTECTED]>: > [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 > ---------------------------------------------------------------- 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
