1 / 33

GP2GP record transfer and the life long record

GP2GP record transfer and the life long record. John Williams GP2GP Clinical Safety Lead. GP2GP:. Transfers a ‘snapshot’ of the patient’s whole general practice electronic record directly from one practice to the next

xylia
Download Presentation

GP2GP record transfer and the life long record

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GP2GP record transfer and the life long record John Williams GP2GP Clinical Safety Lead

  2. 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

  3. GP2GP project history: • 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

  4. Current status of GP Systems and GP2GP

  5. 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

  6. 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: • 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

  7. GP2GP v1.1a record transfer • From 0% to nearly 100% of practices in 10 years? • But even then, still unfinished business... • User experience affected by degradations, disorganisation and duplications • Not yet fully supporting the lifelong record

  8. Before the era of computers • The paper record: • 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

  9. 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 • Paper print-outs (even after a successful GP2GP transfer) • Rekeying / ‘summarising’ of information at next practice

  10. GP2GP version 1.1a • Is near to being able to transfer records between all candidate GPSoC systems but: • 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

  11. GP2GP version 2.2 • Aims to develop solutions: • 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

  12. Limitations on size / no of attachments • Spine related problem: limits originally set • 5mb total size • Maximum of 99 attachments • Permitted file types • 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

  13. Reducing the need for paper printouts (1) • 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

  14. 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 • 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

  15. 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 • 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

  16. 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: • Whether or not the EPR has been successfully imported / ‘integrated’ at the receiving practice • Whether or not there were any place holders

  17. 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: • 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

  18. 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) • Will depend on intelligent interpretation of “GUIDs”

  19. 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: • Severity of reaction • Likelihood that allergy is real • Type of adverse reaction

  20. 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

  21. Drug allergies: the solution • Develop and implement common representation of drug allergy causative agent that ALL receiving systems: • 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...

  22. Drug allergy model Severity Allergic reaction Certainty Causative agent Type of reaction

  23. 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: • Blood pressure • Drug allergy

  24. Blood pressure model Body position Cuff size Systolic BP value BP reading Laterality Diastolic BP value Type of BP reading Korotkoff sound

  25. Attachments and ‘metadata’ (1) • 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

  26. Attachments and ‘metadata’ (2) • There is now a Scottish standard for the naming of documents involving the use of two ‘subsets’: • 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

  27. Attachments and ‘metadata’ (3) • As a result, once implemented: • 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

  28. 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: • 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

  29. GP2GP v2.2: ‘Mending’ the broken life long record • The paper record: • 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

  30. GP2GP v2.2: in addition • 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

  31. The future • 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

More Related