Delivering electronic health record transfers in a safe and timely manner.

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

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 clinicians
  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.connectingforhealth.nhs.uk/gp2
  gp
• On that page there are links to
• Good Practice Guidelines for General Practice
  electronic records (appendix 2 for GP2GP)
• Supplement to appendix 2