Transcript Introduction - EMIS National User Group

GP2GP record transfer and the life
long record
GP2GP
John Williams
GP2GP Clinical Safety Lead
GP2GP:
GP2GP
 Transfers a ‘snapshot’ of the patient’s whole
general practice electronic record directly from
one practice to the next
 Is triggered at the point when and where the
patient registers with a new practice
 Capable of delivering the record, fully
integrated into the record system of the ‘new’
practice, within minutes of registration
GP2GP project history:
GP2GP








Began in late 2004
Emis LV – Gateshead 2005
InPS Vision – Isle of Wight 2005
Heterogeneous transfers – Croydon 2006
Emis LV and InPS Vision FRA – 2007
Synergy FOT – Hampshire 2010
EmisWeb FRA – 2011
TPP SystmOne FOT – Derbyshire 2012
Current status of GP Systems and GP2GP
Supplier
System
Status
EMIS
LV
Accredited
EMIS
Web
Config 3 (EPS1 & GP2GP)
Accredited
Config 4 (EPS2 & GP2GP)
Accredited
Config 5 (EPS1 & GP2GP &
SCR2) In First of Type
GP2GP
Config 6 (EPS2 & GP2GP &
SCR2)
First of Type Date to be
confirmed
INPS
Vision 3
Accredited
TPP
SystmOne
In First of Type due to
complete end of September
iSOFT
Synergy
First of Type planned for
October 2012
Microtest
Evolution Practice
Manager
First of Type planned for
January 2013
GP2GP Live Estate - status
 As of 24.08.12
- 4721 = Total Number practices live with GP2GP in
England
- 58% = Total Percentage of practices in England Live with
GP2GP
- 11363 = Total Number of GP2GP Extracts per week
- 2,282,657 = Total number of GP2GP Transfers to date
% GP Practices with GP2GP Compliant Clinical Systems
GP2GP
Practices
Supplier
FRA - Actual
EMIS LV
INPS
EMIS Web
03-Jul-07
29-Sep-07
25-Oct-11
Possible No.
Actual No.
2839
1391
941
2,744
1,346
644
% Possible
Supplier
Estate
33.66%
16.51%
7.93%
% of Supp
Estate Dep
96.65%
96.76%
68.44%
TPP SystmOne: progress to date
 Currently in First of Type in Derbyshire PCT and due to
start national deployment soon
 Involves the use of cross mapping tables for the first
time in live record transfers
 Successful transfers with other systems to date:
GP2GP
-
S1 > EMIS Web = 7 successful transfers
EMIS Web > S1 = 11 successful transfers
S1 > EMIS LV = 6 successful transfers
EMIS LV > S1 = 42 successful transfers
S1 > Vision = 2 successful transfers
Vision > S1 = 2 successful transfers
GP2GP v1.1a record transfer
 From 0% to nearly 100% of practices in 10
years?
 But even then, still unfinished business...
GP2GP
- User experience affected by degradations,
disorganisation and duplications
- Not yet fully supporting the lifelong record
GP2GP
Before the era of computers
 The paper record:
GP2GP
-
Had no limits on size or number of components
Could travel between all practices
Needed no cross mapping table translations
No problems with returning patients
Could travel across borders
Followed the patient life-long
Arrival of computers
 Broke the life long record
 Initially led to dual recording on paper and
computer
 On each change of practice at present still
requires
GP2GP
- Paper print-outs (even after a successful GP2GP
transfer)
- Rekeying / ‘summarising’ of information at next
practice
GP2GP version 1.1a
 Is near to being able to transfer records
between all candidate GPSoC systems but:
GP2GP
- Has limitations on size, number of attachments and
permitted file types
- Cannot support returning patients
- Cannot cross borders
- In a heterogeneous “Systems of Choice” setting has
to cater for differences in structure and coding
- Still requires paper printouts
 Not life-long record but a key step on the way
 Based on paradigm of moving a single record
around by means of messaging
GP2GP version 2.2
 Aims to develop solutions:
GP2GP
- To remove limitations on size, number of
attachments and permitted file types
- To minimise the need for paper printouts
- For Returning Patients
- To make drug allergies and blood pressure readings
interoperable
- To improve the handling of ‘metadata’ about
attachments
 Will also aim to ensure that these
developments are coordinated across the four
countries with a view to enabling cross border
record transfers
Limitations on size / no of
attachments
 Spine related problem: limits originally set
- 5mb total size
- Maximum of 99 attachments
- Permitted file types
GP2GP
 Solution is imminent: awaits implementation
by suppliers
 Involves splitting the message into small
‘chunks’ that are each small enough to cross
the Spine and then reassembling them at the
receiving end
Reducing the need for paper
printouts (1)
GP2GP
 At present, whether or not the EPR has been
successfully sent by GP2GP, the sending
practice is still obliged to print out the whole
EPR plus attachments and to forward this with
the Lloyd George envelope
Problems with attachments
 It may be technically impossible to send some
attachments
- File type is not ‘legal’ for Spine
- File cannot be located by GP2GP on extract at
sending system
GP2GP
 In such cases the attachment is automatically
substituted with a ‘place holder’ at the
sending practice containing the name of the
missing file plus a message such as:
- 01: File type unsupported
- 02: File not found
Stopping paper printouts: Agreed
way forward
 The EPR must have been successfully
imported at the sending practice. May have:
- A) One or more attachments substituted with ‘place
holders’
- B) No ‘place holders’ sent: all attachments assumed
to have been successfully transferred
GP2GP
 Possible outcomes and agreed actions to be
taken
- EPR not successfully imported: Full print out
required
- Outcome A): Print out of attachments only required
- Outcome B): No print out required
Stopping paper printouts: The
solution
 Solution is imminent: awaits implementation
by suppliers
 Improved reporting so that sending practices
are clearly informed for each record transfer:
GP2GP
- Whether or not the EPR has been successfully
imported / ‘integrated’ at the receiving practice
- Whether or not there were any place holders
Returning patients: the problem
 Once a patient has been registered with a practice they
will have an EPR that persists after they have left to
register elsewhere
 The current situation is that when they return to this
practice there is no way to merge any EPR incoming
with GP2GP with the previous record. There is a need
to distinguish reliably and safely between:
GP2GP
-
Additions
Amendments
Deletions
And whether these are generated by users, or artefacts
created by the record transfer process
 Applies whether the patient’s record originally left the
practice by GP2GP or by paper transfer
Returning patients: the
requirement
 In GP2GP v2.2 the aim is to develop and
implement a solution that will:
- Distinguish between ‘human generated change’ and
‘machine generated change’
- Distinguish between human generated additions,
amendments and deletions
- Leave the previous (existing) record unchanged
where there have been no amendments or deletions
(expected to be the majority of previous record)
GP2GP
 Will depend on intelligent interpretation of
“GUIDs”
Making drug allergies
interoperable: the problem
 Currently different systems represent the
cause of a drug allergy in different ways that
cannot be reliably transferred automatically
 Different systems support different elements of
‘qualifying’ information such as:
GP2GP
- Severity of reaction
- Likelihood that allergy is real
- Type of adverse reaction
GP2GP
Drug allergies: GP2GP pragmatic
definition
 All systems can identify adverse drug reaction entries
that interact with their prescribing decision support
systems
 These are currently handled as a special ‘category’
such that a receiving system can be in no doubt that it is
receiving information about a drug allergy even if it
cannot process it
 Incoming drug allergies that cannot be processed are
converted into “record transfer allergy degrades”
 Prescribing is locked down until these have been
reviewed, re-entered and deleted
 In GP2GP v2.2 the aim is to do away with the need
for this ‘lock down’ and associated extra work
Drug allergies: the solution
 Develop and implement common
representation of drug allergy causative agent
that ALL receiving systems:
GP2GP
- Will be able to process
- Will be able to offer to their prescribing decision
support systems
 Implement a drug allergy ‘archetype’ that
carries a professionally agreed set of
information – a structure that will transfer
repeatedly without degrading
 This work is under way...
Drug allergy model
Severity
Certainty
Allergic
reaction
GP2GP
Type of
reaction
Causative
agent
Blood pressure ‘archetype’
 Being developed at the same time
 Aim is to create a generic mechanism for
‘archetypes’ that can be re-used the first two
candidates being:
GP2GP
- Blood pressure
- Drug allergy
Blood pressure model
Cuff size
Body
position
Laterality
BP
reading
GP2GP
Type of BP
reading
Systolic
BP value
Diastolic
BP value
Korotkoff
sound
Attachments and ‘metadata’ (1)
GP2GP
 This is primarily about improving naming
conventions for attachments so that
meaningful display names transfer from
system to system
 Currently users may experience a situation
where every document attached to an
incoming record is labelled as ‘other report’
 The only way to ascertain the content is by
opening each attachment in turn
Attachments and ‘metadata’ (2)
 There is now a Scottish standard for the
naming of documents involving the use of two
‘subsets’:
GP2GP
- Document type
- Care setting
 In the GP2GP setting this has been
incorporated into a wider set of ‘metadata’
which will in future be associated with every
attachment in the record transfer message
 The aim is for this set of ‘metadata’, including
a meaningful document display name, to
survive successive record transfers intact
Attachments and ‘metadata’ (3)
 As a result, once implemented:
GP2GP
- All attachments should have meaningful display
names regardless of which system is sending or
receiving
- There will be a wider set of useful information easily
available about any attachment
- This metadata should also be useful in other ways
(e.g. to document management systems that
arrange documents into folders)
 This metadata may eventually evolve into a
standard which applies beyond the GP domain
and which is applicable in all four countries
Cross border record transfers
 Strictly not within the remit of GP2GP v2.2 but
essential that development of all of these
enhancements, and any similar work in the
other three countries, are carried out in a way
that ensures cross border compatibility
 Already differences. For example:
GP2GP
- Patient identifiers and organisational data are held
on the Spine in England only
- NHS and CHI numbers
- Document storage and distribution
 Solutions for all of these have been identified
GP2GP v2.2: ‘Mending’ the broken
life long record
 The paper record:
GP2GP
-
Had no limits on size or number of components
Could travel between all practices
Needed no cross mapping table translations
No problems with returning patients
Could travel across borders
Followed the patient life-long
GP2GP v2.2: in addition
GP2GP
 Starts the process of standardising the way
that key parts of the clinical record are
represented
 This in turn should help to reduce degradation,
disorganisation and duplicates and thereby
enhance user experience
 Must be done with professional consensus
 V2.2 as currently described only scratches the
surface in this respect
The future




GP2GP
More than just a GP record?
Patient access
Will the record become ‘distributed’?
If so, would need to shift away from the
paradigm of a discrete GP record moved from
place to place by messaging
 But many of the lessons being learned in
GP2GP ‘interoperability work’ are likely still to
apply
GP2GP