1 / 34

GP2GP Ensuring clinical safety

GP2GP Ensuring clinical safety. Delivering electronic health record transfers in a safe and timely manner. 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.

minor
Télécharger la présentation

GP2GP Ensuring clinical safety

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

More Related