SweetP - answers and
questions from the
front line
Dr Ian Wells
Royal Surrey County Hospital
Guildford
Presented at the Integrated Care Records:
Problems and Solutions Workshop
Edinburgh, 11th to 12th December 2003
1
Answers and questions
• Clinical Computing at the Royal Surrey (RSCH)
• SweetP - principles and practice
• Answers - and future plans
• Questions - are we missing the point?
• from how to why and what
... and please savage gently!!
2
Clinical Computing at the
Royal Surrey County Hospital
3
Computing in a hospital?
• section in Medical Physics Department
• scientific - supporting work of department
• network,Varis, interfacing, image server
• clinical - most ‘customers’ outside department
• not related to IM&T Department
• employ clinical scientists or equivalent
4
Clinical Computing
• development - clinical databases (since 1987)
• research - IKBS and medical reasoning
• teaching - UniS Dept of Computing MSc
• strategy - ASSIST PDC, CCL SAG
5
Clinical Databases
Operational
Development / future
Clinical Results Server (CRS)
West Surrey Hepatitis C Service
Diabetes and Endocrinology (SweetP)
Orthodontics
Cancer Network (CanCAS)
Endoscopy
Nuclear Medicine (NMR)
Audiology
Urology Seeds (SPOC)
Patient information leaflets
RSCH Intranet Server
Macmillan Cancer Nurses
Clinical Investigation Unit
Medical Photography and Graphics
Trace Element Laboratory (MacPath)
Pathology Results Archive
6
EPR strategy
• fill gaps OASIS cannot reach
• tightly integrated with OASIS (4D - Oracle)
• inhibit spread of standalone Access databases
• satisfy needs of IT enthused consultants
• OASIS remains master system
7
Development strategy
• 4D software tools [1] since 1987
• 4D Co-operative since 2002
• all software open source
• modular and moving to components
• clinical database shell for new systems
8
Clinical
database
shell
Specialized software components which only apply to a single clinical
application (e.g. importing fundus images)
Clinical data layer - specific to actual clinical application
(SweetP, HepC, Lipids ...)
Generic data layer - patient specific information and other data items
which are common to all clinical applications
Generic software components including attribute/value manager,
PAS and pathology interfaces, statistics, advanced reporting,
inference engine and web access
Foundation software layer for common presentation and operation, help
system, password control, basic reporting
4th Dimension 2003 software for development and deployment
Operating System (UNIX, Mac OS, Windows)
9
SweetP - principles & practice
10
SweetP background
• management of diabetic clinic
• developed for Prof David Russell-Jones
• single use since 1999, all doctors since 2001
• over 4900 clinic attendances recorded
• new version using shell to support NSF
11
Failure criteria
• synchronize patient details with OASIS
• generate clinic letter without dictation
• provide individual and overall statistics
• easy to use for doctors and secretaries
12
SweetP in the diabetic clinic
even the Professor can use it ...
13
SweetP in the office
and the secretary is smiling again!
14
Comparative statistics
Mean
BMI
BP syst
BP diast
HBA1c
Chol
Trigs
All
28.7
142.3
79.2
8.4
5.1
2.1
Male
28.5
142.3
79.5
8.3
4.9
2.2
Female
28.9
142.4
78.9
8.6
5.2
2.0
First 6
months
28.3
142.7
79.4
8.5
5.0
2.4
Last 6
months
28.9
141.4
78.4
8.2
4.9
2.0
15
HBA1c distribution
HBA1c
700
600
500
400
300
200
100
0
4
6
8
10
12
14
16
18
whole clinic - but could be for single doctor for peer review
16
‘Front cover of notes’
17
Routine clinic visit
18
Answers - and future plans
19
Why did SweetP succeed?
• met failure criteria
• robust and easy to use
• in-house development leads to local ownership
• research initiative so free to users
• prepared to discard prototypes
20
SweetP prototypes
• data set derived from British Diabetic
Association recommendations
• data set reflecting existing ‘paper database’
• data set based on consensus of local diabetes
consultants at Health Authority meeting
• which one succeeded - what does this tell us?
21
Well behaved data?
• selection lists for coded items
• mapping to multiple external codes
• field labels and colours
• multiple ranges for numeric data
• rule-based actions where needed
22
EAV module
• Entity - Attribute - Value manager
• inspired by MYCIN [2]
• user control of attributes and values
• entity definition stays with developer!
• integral component of clinical systems shell
23
24
25
26
Questions are we missing the point?
27
Doctors talk to patients ...
28
Pass around information ...
29
... and make decisions!
30
Better information
- better medicine?
“Medicine is the art of making acceptable decisions
in an imperfectly understood problem space using
insufficient and often erroneous information”
With acknowledgment to Edward Shortliffe
31
How do doctors reason?
• Harvard studies by Elstein in 1978 [3]
• 24 doctors and 3 specially selected cases
• grouped into ‘experts’ and ‘remainder’
• retrospective analysis of management of cases
• focus on acquisition of cues + reasons for errors
32
Backwards not forwards!
• hypothetico-deductive approach to diagnosis
• pure inductive reasoning not used
• up to five hypotheses in memory
• Miller’s ‘magical number’ 7 +/- 2 (1956)
• 3-point weighting of uncertainty
• 7-point experiment showed no better results
• experts better at data gathering & interpretation
33
Use computers with caution
• doctors are human, tend to reason backwards
and are limited by Miller’s number
• the order and emphasis of data items is
important in both entry and review
• departure from established practice could lead
to early discarding or merging of the correct
hypothesis and thus the wrong decision
34
Food for thought
• established ‘paper database’ may represent best
practice in clinical information management
• we should not rely solely on the doctor’s
intuition for our understanding of the medical
decision-making processes
• are our suppliers aware of the question - let
alone the answers?
• we ignore the cognitive aspects of computing at
our peril (perception and cognition)
35
Neisser’s cyclic model of perception
Top down
Expected features
Deductive
Perceptual model
Environment
Bottom up
Feature analysis
Inductive
36
Conclusion
“The (medical) deductive process is not automatic,
even though experienced practitioners can make it
seem to be”
Elstein (Harvard project [3] page 111)
37
Acknowledgments
• Richard Harper - getting the RSCH involved
• Alex Taylor - fieldwork and encouragement
• Jose Spring - keeping us in order
• Rob Scott et al - invitation to participate
38
References
1. 4D software tools: www.4duk.com
2. Buchanan BG, Shortliffe EH eds, ‘Rule-Based
Expert Systems: the MYCIN Experiments of the
Stanford Heuristic Programming Project’,
Addison-Wesley 1985.
3. Elstein AS, Shulman LS, Sprafka SA, ‘Medical
Problem Solving: an Analysis of Clinical
Reasoning’, Harvard University Press, 1978
39
Contact details
Dr Ian Wells
Clinical Computing Section
Department of Medical Physics
Royal Surrey County Hospital
Guildford
Surrey GU2 7XX UK
Tel: +44 (0)1483 464 039
Email: ian.wells@royalsurrey.nhs.uk
Also: Department of Computing, University of Surrey
40
The end
41