A content server sounds fine and dandy.
Such things are alluded to as part of the as-yet-unimplemented 1997
GPCS functional specifications - which I think contains a reasonable
list of what is needed.
http://www.gpcg.org.au/index.php?option=com_content&task=view&id=137&Itemid=37
see IBMfunc.pdf page 17 - mentions reference databases and on the
next page "external information manager" - presumably the guts of a
"content server". I presume that the "content server"jargon is more
recent than 1997.
Content servers will not easily happen without either standards for
such content servers or significant involvement of market leading
commercial interests.
Are local content servers on the NeHTA radar???? ...as long as the
update mechanism is a web service.
Horst, if drugref uses a web service, someone will fund it!
Ian.
At 8:39 am +1000 21/6/06, [EMAIL PROTECTED] wrote:
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
--
Dr Ian R Cheong, BMedSc, FRACGP, GradDipCompSc, MBA(Exec)
Health Informatics Consultant, Brisbane, Australia
Internet: [EMAIL PROTECTED]
(for urgent matters, please send a copy to my practice email as well:
[EMAIL PROTECTED])
PRIVACY NOTE
I am happy for others to forward on email sent by me to public email lists.
Please ask my permission first if you wish to forward private email
to other parties.
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
