Transcript GP2GP Ensuring clinical safety

GP2GP Ensuring clinical safety
Delivering electronic health record transfers
in a safe and timely manner.
1
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.
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.
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.
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.
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.
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.
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.
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.
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.
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










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
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.
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’.
Record import/workflow
Diverse approaches across systems, however:
–
–
–
–
Import mechanism.
‘Filing exception’ messages.
Preview facility.
Warnings or triggering of workflow.
Medication management
Active repeat medications deactivated on import:
– Re-authorisation required to re-issue.
– EMIS LV provides work flow features to support reauthorisation.
– INPS Vision re-authorisation by ‘copy’.
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).
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.
‘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’.
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.
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.
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.
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.
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.
Message/transport limitations




5 Mb total message size.
100 attachments.
Attachment type restrictions.
Restrictions will disappear in medium term.
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.
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.
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.
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.
Referrals
• Interoperable, however:
– Loss of provider in INPS Vision to EMIS transfer
(message design issue).
– Full set of referral qualifiers generally interoperable as
text.
Recall/review issues
• Possibility of duplication between autogenerated 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.
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’.
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.
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.
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