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

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

authorisation.– 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 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.

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