ash wrote: > interestingly, thunderbird thought this was an e-mail scam......
It thinks that any message containing an IP address as opposed to a domain name in a URL is a scam or a phishing attempt. A reasonable supposition, but not always true. Tim C > > ash > > Andrew McIntyre wrote: >> Hello Tim, >> >> Yes exactly, Medical-Objects has clients running Webservice clients >> from behind firewalls now, and the connection is up only when their >> internet connection is up. Presumably there is no point in delivering >> a message when no one is there to read it. Many of our trial practices >> are only up during normal working hours and are working well. Email is >> a store and forward system and a well proven one. It lacks sender >> authentication which is a big problem as it has caused the spam >> problems. The XDS model does not have a well defined security >> interface. The standard answer is "Use SSL" which is not really an >> answer. >> >> There is very little difference between polling the repository for new >> messages and retrying sending to a client that is currently offline, >> but the latter is a push model and you only retry when you have >> something to send. When it succeeds you know you have delivery. With >> store and forward you send successfully but that is no guarantee that >> the recipient has collected the message. >> >> It can, and is being done now by your average GP surgery. Its totally >> point to point and realtime. >> >> Here is one running on my notebook, as well as SOAP it supports HTTP >> so you can see if its running using this URL in a browser. >> >> http://202.44.75.22:2511/NEXUS/AB5A38B7-7372-4BB3-B724-EA8886571336/HL7/ADMIN?METHOD=ALIVE >> >> >> It also supports SOAP as per our wsdl. >> >> While XDS is being pushed by some, I am not sure that it really solves >> any problems that cannot be solved using a push, point to point model. >> It has been put up for this years IHE demo but we are yet to see a >> working implementation to interact with and the security model is >> quite vague. As an internal system, within a large organisation it may >> have some uses but what is wanted currently is point to point delivery >> with good security and authentication *between* organisations. A >> webservice (be it HTTP or LLP or SOAP) model with message level >> security is a good fit to this need. >> >> Tuesday, May 9, 2006, 9:07:04 PM, you wrote: >> >> TC> Peter MacIsaac wrote: >> TC> ... >>>> Under a full web service model the IT systems of small business >>>> enterprises >>>> (like GPs) would need to have the capacity to be always connected to >>>> the >>>> internet ... >> >> TC> As discussed previously, I am not at all convinced that this is true. >> >> TC> Why does a Web service running on, say, a GP practice system, always >> TC> need to be available, 24x7? Is the practice open 24x7? Nope. So >> why does >> TC> the practice's Web services need to be available all the time? Of >> TC> course, other providers wishing to use the practice's Web services >> to, >> TC> say, deliver a report to them need to have robust retry and fallback >> TC> mechanisms to cope with a Web service not being available, but >> they need >> TC> those regardless, because no network, including the Internet, is 100% >> TC> reliable and to build systems of Web services based on the assumption >> TC> that everything will always be available is asking for trouble. For >> TC> further elaboration on these ideas, see >> TC> http://ozdocit.org/pipermail/gpcg_talk/2006-April/002906.html >> >> TC> Tim C >> TC> _______________________________________________ >> TC> Gpcg_talk mailing list >> TC> [email protected] >> TC> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >> >> TC> __________ NOD32 1.1526 (20060509) Information __________ >> >> TC> This message was checked by NOD32 antivirus system. >> TC> http://www.eset.com >> >> >> >> > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
