IN 364
15. April 2002
Margunn Aanestad
Case study: Telemedicine
• Not traditional Software Engineering:
concerns the ”C” in ICT, more than the ”I”?
– a) second opinion on digital images attached to
an e-mail message
– b) real-time advice during emergency surgery
• A wide variety in technologies, use areas,
organisational complexity, criticality, etc.
• Ranges from:
What is telemedicine?
A complex and challenging case:
- technology is:
- new, immature
- open and generic
- organisation:
- large, complex,
- demanding, critical
- radical restructuring expected – how to
model and design for this?
Why is this relevant for SD?
• Learning-based development.
• Learn from experience, see new problems
and new opportunities, further developing
technology and organisation
• Design and re-design in use, by users
Evolutionary and experimental SD
–
–
–
–
–
No ”proof” of effects
Lack of resources (time, financial, devotion)
Little management support
No perceived need
No tolerance for disturbances, fault
• Dilemmas
• Disadvantaged starting point
”The uphill battle of evolution”
– Surgical telemedicine in Oslo (RH – US) (the
article: Growing networks…) (From Margunn’s
PhD work)
– MobiMed (ambulances in Østfold)
(IFI
Master thesis, february 2002, Nina Mikkelson)
• Two telemedicine case that illustrates this
dilemma and how it can be handled:
Today:
• ”Development of Interactive Medical
Services”
• Telia, Ericsson, Rikshospitalet, Ullevål and
UiO (Informatics)
• Exploratory development of broadband
network technologies for surgical
telemedicine (minimal-invasive surgery)
• 34 Mbit/s ATM network, MPEG2 (rt)
The DIMedS project
• Initial interest, but constraints on
participation due to local workload
• Result: not very much use of RH-US link
• Wanted to increase no. of transmissions
• Wanted to get experience with use (learn)
• Wanted to build support within hospitals for
later purchase/extensions
Starting surgical telemedicine
– Radiologists , medical students and teachers,
ear/nose/throat specialists, nurses
– Not just clinical procedures, but also lectures,
discussions, meetings, seminars and
demonstrations)
• Not just surgical telemedicine:
Detours
• Such transmissions might be perceived to
miss the target, be deviation from the
project plans.
• We argue that they were necessary and
useful ”detours” in order to reach the goal
(which in turn were changed and influenced
by the detours and the new participants)
”Stunts”
Mobimed – Østfold county
– From patient becomes ill until ambulance
arrives
– Transport to hospital
– Time spent within hospital before treatment is
started (transport from ECU to Heart ICU).
• For myocardial infarction (hjerteinfarkt)
treatment should be given within one hour
• Time delays:
The need for telemedicine
• 1996: PW (a doctor) hears of MobiMed
(transmission of ECG from ambulance) and in
1997 he goes to Falun to see the system in use
• February 1998: a pilot study starts in Halden, with
two ambulances + cardiology ward at F. (Aim: to
bypass ECU, take patient directly to Heart ICU)
• January 1999: anaesthesia nurse administers
thrombolytic medication during transport
• July 2000: >400 ECGs transmitted, ”call-to-needle
time” reduced by 50-60 minutes
Some milestones
The Mobimed ”project”:
• 1999: Askim looses its ECU (emergency
care unit)
• April 2000: Mobimed in Askim ambulances
• October 2000: > 200 ECGs transmitted,
nurse administers medication.
• Ambulance personnel reaches level 3 in
their training (allowed to give medication)
• 2001: Sarpsborg, Moss and Fredrikstad
Some milestones
The Mobimed ”project”:
•
•
•
•
Started with enthusiasts
Visible and tangible benefits
Incremental growth, not all in one go
Low cost, simple solutions
The Mobimed ”project”
• Start with the simplest and cheapest
solution that satisfy the needs of most users
in their least critical and simplest practices
and which doesn’t require a large network
• Use this technology as far as possible,
enroll more users
• Use the same solution on more innovative
and beneficial ways
”Bootstrapping”as strategy
• Use the solution for more critical tasks
• Use the solution for more complex tasks
• Re-design/improve the solution so that new
tasks can be carried out
• (Repeat from start)
”Bootstrapping”as strategy