GP2GP Ensuring clinical safety

1. GP2GP Ensuring clinical safety Delivering electronic health record transfers in a safe and timely manner.

2. Clinical safety • Clinical safety has been a driving motivation at all stages of GP2GP development and testing. • Safety assurance • In line with the HSCIC clinical safety approach. • Robust methodology. • Strong clinical involvement.

3. NHS CFH clinical safety approach • Three stages – all involving clinicians: • End to end hazard workshop • Identifies hazards to be ‘mitigated’. • Development of safety case • Determines what must be done to ‘mitigate’. • Safety closure document • Proof that ‘mitigations’ have been performed to satisfaction of clinical safety testing team.

4. Following safety closure • Endorsement by Joint GP IT Committee of General Practice Committee (JGPITC) and Royal College of General Practitioners. • Issue of ‘clinical authority to release’ (CATR) by HSCIC clinical safety officer. • …Only then can deployment take place.

5. GP2GP clinical safety testing (1) • Use of artificial patient records: • Designed to uncover potential hazards. • Iteratively developed. • Use of real patient records in live environment: • To check for unexpected hazards.

6. GP2GP clinical safety testing (2) • Exhaustive side by side comparison of representation of record in sending and receiving systems: • Same system transfers. • Heterogeneous system transfers: • Single ‘A’ to ‘B’ transfer. • Double ‘A’ to ‘B’ to ‘C’ transfers.

7. GP2GP clinical safety issues • Hazard workshop and subsequent side by side comparative testing identified ‘safety issues’. • Broadly open to two kinds of ‘mitigation’ – or combination of both: • Technical ‘informatic’ solutions. • User guidance/training/education.

8. GP2GP safety forewarning • No clinical system can be completely safe how ever thoroughly tested: • GP2GP aim has been to reduce risk to levels ‘as low as reasonably possible’ (ALARP principle). • Users retain responsibility to adhere as far as possible to ‘best practice’. • Records have their limitations.

9. Users and ‘best practice’ • Safety assurance process: • Cannot test for user behaviour/best practice. • Can identify needs for guidance, training, and education. • Users: • Should be provided with access to appropriate guidance and training materials.

10. Guidance will be helpful: • For those hazards which are dependent on human behaviour. • Where the transfer process: • Results in the need for user intervention. • Causes the record to look unfamiliar. • Degrades information to human readable text. • Places items in unexpected locations. • Does not support business processes.

11. Qualifier interoperability Message/transport limitations Degrade handling Provenance/attribution Problem orientation System specific features Referrals Recall/review Issues Date handling Sending practice considerations Audit trails Index of issues • Validation of the incoming record • Deliberate exclusions • Record Import and workflow/preview and warning features • Medication management • Allergies and adverse drug reactions • Business process/continuity issues • General structural differences • Pathology results • Attachments • Form/template interoperability

12. Validation of record at receiving practice Need to ‘validate’ record at receiving practice including: • Verification of patient identity. • Review general quality of record: • Inaccurate data on sending system. • Distinct data entry conventions at sending practice. • Deal with allergy degrades. • Re-authorise medications. • Review business functions such as recalls/audits/degrades relating to DSS.

13. Deliberate Exclusions What is not included in GP2GP record transfer? • Test requests. • Diarised medication reviews/repeat issue reminders. • Practice workflows: • EMIS LV patient notes, RF module activity. • INPS Vision action dates on referrals. • Out of record warnings/alerts: • INPS Vision ‘post it’, EMIS alerts/warnings. • Everything else is ‘in’.

14. Record import/workflow Diverse approaches across systems, however: • Import mechanism. • ‘Filing exception’ messages. • Preview facility. • Warnings or triggering of workflow.

15. Medication management Active repeat medications deactivated on import: • Re-authorisation required to re-issue. • EMIS LV provides work flow features to support re-authorisation. • INPS Vision re-authorisation by ‘copy’.

16. Drug allergies/adverse drug reactions • Drug allergies are not interoperable between systems: • Different structures, terminology and drug dictionary differences, decision support differences. • Rather than attempt to solve interoperability issue GP2GP focuses on making the transfer process safe regardless of interoperability limitations: • Drug allergies degraded on import. • Warnings/workflow to identify presence of drug allergies. • Prescribing prevented until drug allergies have been processed by a user – either recoded into appropriate local equivalent or deleted. • Non-drug allergies are interoperable (depending on terminology).

17. Business process/continuity of care • GP2GP deliberately terminates on-going business processes: • Explicitly e.g. medication deactivation. • Implicitly/unavoidably: • Triggering of recalls/screening. • Use of different code sets in sending and receiving practices.

18. ‘Structural’ differences • SOAP/consultation types • Consultation sub headings partially interoperable: • Many of the INPS Vision sub headings ‘characteristic type’ and ‘additional’ on EMIS. • INPS Vision automatically assigns characteristic type to incoming records based on system defaults/read code chapter and hierarchy. • May lead to re-ordering effects: • Although minimal if original consultation follows logical SOAP order. • Consultation Types: • Partially interoperable, common consultation types are interoperable, otherwise ‘other’.

19. General structural differences • EMIS summary record entry • Single record entries added outside of consultations. • In INPS Vision everything is a consultation. • Leads to ‘non consultation’ data/medication data in INPS Vision. • Some EMIS concepts are always out of consultation e.g. follow-up, medication issue.

20. Pathology/test results • Fully interoperable: • Preserves ‘original report’. • Some restrictions on dates. Un-filed reports are auto-sent: • Rules to support clinical responsibility. Hand entered results • INPS Vision result operators, result qualifiers interoperable as text.

21. Attachments • Attachments interoperable between systems: • Some loss of context (title, type) due to system differences and message design restrictions. • Problems to consider: • Inability to retrieve files from some third party document management systems. • ‘Attachments’ that are not truly linked to the patient record.

22. Form/template interoperability • Template/form concepts not interoperable between systems. • INPS Vision forms (SDAs) interoperable between different systems as a series of individual statements but the linkage/grouping is lost in transfer.

23. Qualifier interoperability • Common clinical qualifiers not interoperable other than as text: • Laterality, certainty, episodicity etc... • Distinction between qualifiers and modifiers: • Qualifiers make same meaning more specific. • Modifiers change the underlying meaning.

24. Message/transport limitations • 5 Mb total message size. • 100 attachments. • Attachment type restrictions. • Restrictions will disappear in medium term.

25. Degrade handling • Degrades occur when the receiving system ‘does not understand’ the code for an incoming record entry. • A degrade is ‘human readable’ but not ‘machine readable’. • Degrade handling: • Explicitly identified in import/workflow. • Explicitly identified in record. • Preservation of original text, notes and other information. • Transmission as ‘degrades’ to achieve stability in onward transfer (‘A’ to ‘B’ to ‘C’…) • Common examples: drug allergies, EGTON codes. • ‘Degrades’ should be distinguished from the general degradation (loss of structure) that occurs in heterogeneous record transfers.

26. Provenance/attribution • GP2GP record transfer maintains the ‘responsible doctor’ in transfer. • e.g. When a summariser is making entries on behalf of a clinician, it is the clinician’s details that will be shown in transfer: • INPS Vision – consultation clinician. • EMIS – Dr in date/doctor/place. • In practice/out of practice • Imported records are imported as ‘out of practice’ events.

27. Problem orientation • Problem orientation: • Problem concepts significantly different between systems: • Linkages, usage e.g. EMIS episodic style vs. INPS Vision heading/title style, status, significance/priority. • As a result, limited problem interoperability: • However, problem status and the problem ‘as a heading’ are interoperable.

28. System specific features • EMIS LV consultations in the ‘narrative style’: • Sequences of text, code, text, code…. • Prefix text to a code is a foreign concept in INPS Vision. • Coupled with re-ordering effects due to SOAP heading interoperability, can lead to some significant re-ordering of consultations. • EMIS medication mixtures • Not interoperable – degraded.

29. Referrals • Interoperable, however: • Loss of provider in INPS Vision to EMIS transfer (message design issue). • Full set of referral qualifiers generally interoperable as text.

30. Recall/review issues • Possibility of duplication between auto-generated recalls/reviews on each system. • Different recall concepts between systems. • e.g. staging of immunisations built into INPS Vision immunisations concept but explicitly diarised in EMIS LV.

31. Date handling • Concept of the ‘clinically relevant’ date in some INPS Vision forms: • e.g. last fit, pregnancy dates. • Single date in EMIS LV. • INPS Vision to EMIS: Clinically relevant date displayed. • EMIS to INPS Vision: Single date is ‘date of recording’.

32. Sending practice considerations • Keeping up to date with filing. • Unseen/un-filed pathology results: • Automatically sent. • Requester of test retains responsibility for appropriate follow-up actions. • Dealing with late arriving information: • Process same as for paper records.

33. Audit trails • System audit trails are not transferred by GP2GP record transfer process. • Folders: • New folder generated each time record is transferred. • At each record transfer all previous folders are sent forward with the new electronic health record extract.

34. Useful links • GP2GP web site: www.hscic.gov.uk/systemsandservices/gp2gp • On that page there are links to: • Good Practice Guidelines for General Practice electronic records (appendix 2 for GP2GP) • Supplement to appendix 2