Is this sort of radiology data sent over private lines or the public
internet? What are the bandwidth demands?
Not a good reason for extensive local peering, but a very interesting
application.
- Dan
Actually I got to sit with a company deploying this as a product, and I was impressed. Right now, it's all run over *gulp* dsl. But they are moving towards tunnels on the open internet.
My cousin actually does work in the field and when it's working, it's impressive. When there is a glitch such as a power failure (U can tell something isnt setup right if this affects their network) they have MIS issues and have to volkswagon it over to the main location.
On the one had it makes me nervous that it's not rock solid, on the other hand if it means a senior doctor has a shot at looking at me pics, ultrasound videos etc, before they do something, then Im happier. Somehow I think it's really used in some locations to cut back on expensive staff.
Still, not a need for an exchange pt. Perhaps a medical exchange point??? Perhaps that's the next thread? Goes against my philosophy of aggregation is the key to life.... But could there be medical or industry specific exchanges just like there are industry networks???
dave
Thus spake "Daniel Golding" <dgold@FDFNet.Net>
Is this sort of radiology data sent over private lines or the public
internet? What are the bandwidth demands?Not a good reason for extensive local peering, but a very interesting
application.
I've only seen companies pushing this data around between their own sites; for
instance a remote clinic with just general practitioners may send films to a
central hospital for analysis, or one hospital may send films to another
hospital when their staff radiologist is out to lunch or on vacation.
BW, of course, depends on how fast you want the transfers to go. The film files
are in the hundreds of MB range, and providers are upgrading from FT1 FR to FT3
ATM at major sites.
S
In the 1990's the MAEs and Gigaswitches would give us an unscheduled
failure of a major exchange point on a regular basis, which let us
demostrate our disaster recovery capabilities. With the improved
reliability, i.e. the PAIXes haven't had a catastrophic failure, we
haven't had as many opportunities to demonstrate how well we can handle
a disaster at those locations.Without creating an actual disaster, what if all the providers turned off
their BGP sessions with other providers at a PAIX (or Equinix or LINX or
where ever), both through the shared switch and private point-to-point
links, for an hour. More than likely no one would notice, but then
we would have some hard data. Individually providers have tested parts of
their own network, but I haven't heard of any coordinated efforts to test
recovery across all the service providers in a particular location.
This was more or less done in Sweden two weeks ago. In Stockholm there are two sites located in Government own locations. We migrated one of these sites to a new location, and then shut down "one of the halves" for around 8 hours.
Best regards,
- kurtis -
I definitely would NOT want to see my doctor over a video link when I need
him. The technology is simply not up to providing realistic telepresense,
and a lot of diagnostically relevant information is carried by things like
smell and touch, and little details. So telemedicine is a poor substitute
for having a doctor on site; and should be used only when it is
absolutely the only option (i.e. emergency on an airplane, etc).
(As a side note - that also explains reluctance of doctors to rely on
computerized diagnostic systems: they feel that the system does not have
all relevant information (which is true) and that they have to follow its
advice anyway, or run a chance of being accused of malpractice. This is
certainly the case with textbooks - if a doctor does something clearly
against a textbook advice, with negative outcome, lawyers have a feast -
but doctors never get rewarded for following their common sense when
outcome is positive. And automated diagnostic systems are a lot more
specific with their recommendations than textbooks!).
Emergency situations, of course, require some pre-emptive engineering to
handle, but by no means require major investment to allow a major
percentage of traffic to be handled as emergeny traffic.
As with VoIP, simple prioritization is more than sufficient for
telemedicine apps. (Note that radiology applications are simply bulk file
transfers, no interactivity).
--vadim