Overview of the London Integrated Solution v0'1

1
Overview of the London Integrated Solution v0.1

• Steve Powell,
• Head of Architecture, LPfIT
• 18th June 2008

2
Objectives

• Explain the integrated solution from the business
  point of view
• Explain the multiple sources of information in
  the solution and how they are used
• Explain the use of the London SPR to support
  cross care setting business processes
• Note This presentation applies to both
  integrated releases but more detail is currently
  known about IR1

3
Approach

• Solution Principles
• Business View
• Information View
• Messaging View
• Integration View

4
Solution Principles

• Care setting applications provide best of breed
  functionality within care setting
• The London Shared Patient Record supports sharing
  of information across care settings
• Cross care setting business processes use in care
  setting information supplemented with SPR data as
  needed
• Presentation of SPR data to end users occurs via
  care setting applications
• All Information Governance checks occur within
  care setting applications

5
Business View

• A clinical scenario is used to demonstrate the
  business application of the integrated solution
• Steps in the scenario are related to the clinical
  events shared across care settings to support
  care provision
• Assumptions
• Access to applications through common Portal
• Information governance
• Role Based Access and Legitimate Relationships
• Sealed envelope functionality
• Linkage to Spine record for demographics and
  clinical data

6
Messaging View

• Integration between care settings and SPR is
  achieved via clinical messaging (mainly HL7v3)
• The SPR tracks information about treatment being
  received by a patient using Active Relationships
• When a patient starts treatment in a care
  setting, that initiates an Active Relationship
• When that treatment is completed, the Active
  Relationship is terminated
• When clinical events are received by the SPR,
  clinicians with Active Relationships with that
  patient are proactively notified by the SPR
• The following diagrams show the messaging logic
  used by the SPR

7
Integration View

• There are a number of integration points
• SPR achieved via HL7v3 messaging
• Spine HL7v3 messaging
• ASR legacy systems HL7v2 messaging
• Extraction of operational data into information
  management subsystem ETL
• Bulk transfer of data to ASRs - ftp

8
Overview

• This is the technical solution being deployed in
  support of the various NHS care settings across
  London
• LHMS utilises several Commercial Off The Shelf
  (COTS) products to support the individual care
  settings and adds integration to support
  interoperation and information sharing
• Each care setting product has a development
  roadmap, which means different releases of each
  product will be available at slightly different
  times
• Levels of integration will also vary, with a
  roadmap to full integration and interoperation
• Two Integration Releases (IR1 an IR2)

9
Information Sources

• The London Integrated Solution supports access to
  multiple repositories
• Care setting applications contain detailed
  patient records for the care setting
• The London SPR contains structured, SNOMED coded
  information that is proactively notified to
  clinicians, and supports fine grained queries
• The Spine contains demographic records and
  clinical summary documents

10
The Care Setting Applications and Vendors
Care Setting
Vendor
Product
General Practice
Vision
Acute
Mental Health
(with a mental health configuration)
Community Care
(with a community care configuration)
11
The Primary LHMS Components
other
Spine
LRS
GP (Vision)
Mental Health (RiO)
PSIS
PDS
SDS
Data
Data
NASP Services
SPR
Integration Engine
Notes

• This shows the four main components of LHMS one
  for each care setting and the Integration
  Engine (IE)
• Spine services are also shown
• The Shared Patient Record (SPR)

Acute (Millennium)
Community Health (RiO)
Data
Data
12
SPR holds copies of specific types of patient
events
BT Data Centre
Patient C
Patient B
Vision
Patient A
Shared Patient Record (SPR)
GP Practice
Specific events logged with SPR
1 Day to day care delivery using the Care
Setting Applications results in events being
generated and copied to the SPR
Specific events logged with SPR
Millennium
RiO
2 Events of differing types are stored against
each patient with a date / time stamp
Event Types
Community Health Clinic
Acute Hospital
13
Technical Overview Conceptual Architecture
Shared Patient Record (BT)
NASP Services
TMS
Integration Engine (clinical message routing)
Audit Logging (Sensage)
RiO MHS
Spine Services
GP (Vision 3)
Community Care (RiO)
BT Data Centre
Mental Health (RiO)
Acute (Millennium)
Trust
Information Management (BT)
Portal
Other LSP Subsystems Pathology, RIS,
EDM, Ambulance, Pharmacy Stock Control, ...
Trust End User Workstations
Trust Integration Engine
Trust Legacy Apps
14
BT LHMS Roadmap Current Baseline
Vision3
Vision4
InPractice Vision - GP
V5
V7
CSE Servelec RiO MH / CC
V6
LC2
LC1
LC3
Cerner Millennium - Acute
R0
IE1
BT Integration Services
IE2
Integrated Releases
IR1
IR2
Vision RC2 RiO V6 Millennium LC2
Vision RC3 RiO V7 Millennium LC3
15
Functional Basis of Integration

• Inter-application clinical messaging
• Notifications initially limited to death and
  merge
• Centralised Information Management (IM)
• Storing patient data in clinical messages to
  local databases
• Shared Patient Record (SPR)
• The system will hold patient data from birth to
  death for all patients treated at locations in
  London
• The system will cover patients treated in London,
  whether or not they are registered with a GP
• The system will push information about the
  patient to the care settings applications of the
  care professionals involved in his/her care

16
Longitudinal Care Record and Shared Patient Record
Spine NASP
PDS
Spine PDS
Demographic Data
ACF
Spine PSIS
PSIS
GP Summary
GP2GP
Shared Patient Record
Longitudinal Care Record
LHMS Summary
SDS
SSB
Patient Event Record (PER)
Data retained within care setting
Other
Local demographic data
Primary
Acute
Mental Health
Community Care
Other
SPR access
Care setting applications communicate with Spine
services
17
LHMS Functional Capabilities

• Sharing of key information including
• Admission, Referral and Discharge
• Leave and AWOL
• Assessment
• SPR Patient Query / Report three types
• LHMS Summary, Patient Event List, History
• SPR Notifications including
• Death
• Merge
• Requesting Results Reporting
• Including medication management
• Medications
• Allergies
• Decision Support
• Integrated Care pathways

18
Message Flows

• The following slides show some example message
  flows based on typical healthcare delivery
  processes
• Messaging occurs between care settings
  electronically enabled through LHMS integration
• The LHMS Integration Engine (IE) ensures correct
  message deliver and also copies messages to the
  Shared Patient Record, where configured to do so
• The core care setting applications can query SPR
  and retrieve patient event information
• For IR1, this is supported from the GP, Mental
  Health and Community Care locations
• For IR2, this is additionally supported from the
  Acute care locations

19
GP Consultation and Referral
other
2 GP records notes
Spine
4 with copy of referral going to SPR
BT Data Centre
ACF
Vision
PSIS
PDS
5 GP may also update PSIS-based GP Summary
SDS
GP Practice
3 and initiates referral to Acute
SSB
SPR
NASP Services
Patient
6 and SPR-based GP Summary
1 Patient attends GP appointment
NOTE Although not shown explicitly, care setting
apps issue a single message, which is then copied
by the IE to the SPR
Millennium
RiO
Acute Hospital
Community Health Clinic
20
Acute Assessment and Treatment
other
Spine
BT Data Centre
ACF
Vision
PSIS
3 with copy of assessment going to SPR
PDS
SDS
GP Practice
SSB
SPR
NASP Services
NOTE Although not shown explicitly, care setting
apps issue a single message, which is then copied
by the IE to the SPR
1 Patient attends outpatient appointment
Millennium
RiO
Patient
Acute Hospital
2 Clinician performs assessment and provides
treatment
Community Health Clinic
21
Acute Discharge and Onward Referral
other
Spine
2 with copy of admin discharge outpatient
report going to SPR and to the original referrer
(the GP)
BT Data Centre
ACF
Vision
PSIS
PDS
SDS
GP Practice
SSB
SPR
4 and copy of referral is sent to the SPR
NASP Services
5 and to original referrer in this case the
GP
NOTE Although not shown explicitly, care setting
apps issue a single message, which is then copied
by the IE to the SPR
Millennium
RiO
Patient
3 Clinician onwardly refers patient
Acute Hospital
1 Clinician discharges patient
Community Health Clinic
22
Community Referral Accepted AE Admission SPR
Notification
other
Spine
BT Data Centre
ACF
5 Admission for surgery notified to GP and
logged in SPR
Vision
PSIS
PDS
SDS
2 Info is copied to the SPR, setting up an A/R
GP Practice
SSB
SPR
NASP Services
NOTE Although not shown explicitly, care setting
apps issue a single message, which is then copied
by the IE to the SPR
Millennium
RiO
3 Patient taken to AE for emergency
6 SPR generates notification
1 Referral is accepted and an appointment made
4 Patient details captured and decision taken
to admit
Acute Hospital
Community Health Clinic
23
Summary

• The London Healthcare Management System (LHMS)
  enables deployment of specific care setting
  applications into London-based NHS locations
• LHMS then adds integration capability to enable
  electronic communication between these locations
• LHMS also adds a collective view of significant
  events that happen to a patient across all
  LHMS-enabled locations in London
• Further details on functional and technical
  capabilities for each of the subsystems
  comprising the LHMS are available through each
  subsystems document set

24
Questions?
25
The Scenario Sidneys Story

• 85 year old man
• Long standing chest condition with severe
  shortness of breath
• Long standing disorder of blood cells leading to
  anaemia
• 12 Hospital admissions over the last 2 years
• GP practice team have carried out a search on the
  records of registered patients to identify those
  patients who are Very High Intensive Users
• Target to reduce emergency bed days by 5 from
  2008 through proactive management and systematic
  care planning approach

26
Sidney is referred to Community Matron

• Sidney is identified as a Very High Intensive
  User by his GP practice.
• His GP refers him to his local Community Matron
  for further case management.

27
1. Referral GP to Community Matron
If applicable (not in this example), Choose
Book Referral sent to EBS
TMS
2. Referrals sent directly between contexts
1. Appropriate patient data from DB and
additional notes from GP formatted and sent in
Referral message.
3. Recipient application displays data, and
clinician may save to local DB.
28
Matron Orders Blood Test

• The community matron prioritised him on her
  caseload and visited him. The community matron
  completed a full assessment using the Single
  Assessment Process. This included a physical
  examination, (including taking blood/urine and
  vital signs measurements) and a psychosocial
  assessment of Sidneys needs. A management plan
  was negotiated with him as part of his
  personalised care plan and a copy was given to
  Sidney. Sidney was visited regularly and he was
  also given the community matrons contact details
  to use if he experienced any signs of
  deterioration.

29
2. Pathology Order Community to Acute
3. Test results deconstructed from message,
displayed, and if clinican wishes, saved to local
DB.
TMS
2. Test results sent back to community matron
1.Order for test created and sent to lab.
30
Matron asks GP to prescribe medication

• A few weeks later Sidney rang to say that he was
  more breathless and had increased sputum. The
  community matron visited within two hours and
  undertook a physical assessment which led to
  diagnosis of an exacerbation of his COPD. As the
  community matron was not yet an independent
  prescriber she contacted the GP and arranged an
  urgent prescription for antibiotics and steroids

31
3. Community Prescribing ETP Prescription (via
GP system)
TMS
GP Summary subset of Patient Report
32
Sidney is referred to the Social Services Team

• She then arranged for the Social Care Rapid
  Assessment Team to give an intensive short term
  care package until the exacerbation was resolved.
  
• This enabled Sidney to be managed at home, which
  was his choice.

33
4. Referral Community to Social Care (external
interface)

1
External Interface
TMS
34
Sidney is admitted then discharged from Hospital

• Several weeks later, Sidneys chest pain and
  weakness reoccurred. A blood test showed that he
  was very anaemic again, but on questioning the
  nurse found that he had experienced some dark
  blood in his stools over the week preceding this.
  She was able to liaise with the GP to arrange an
  urgent admission at the acute hospital that
  Sidney chooses.
• Investigations were carried out and he was
  diagnosed with cancer of the colon and agreed to
  surgical treatment by hemicolectomy. He was
  scheduled for surgery and recovered well. Sidney
  returned home with a short term home care package
  including meals provision provided by Social
  Services, Intermediate Care Services and District
  Nurse post operative care.

35
5. Discharge Acute to GP (Includes notification
to CH user)
1
MIM Discharge to PSIS
2
London Discharge to CH and GP
TMS
2. Local database updated with clinical data.
1. Spine-compliant data sent as MiM to GP and
PSIS London data sent only to GP
2. Local database updated with clinical data.
36
Sidney is referred to Mental Health team

• The District Nurse referred Sidney to Mental
  Health Specialist Services for assessment, as she
  had become increasingly concerned about his
  paranoid thoughts and agitated behaviour. The
  District Nurse feared Sidney was loosing control
  of his anger due to his cancer diagnosis. He was
  assessed by a member of the Community Mental
  Health Trust. The mental health professional
  ascertained that his case was not an emergency
  and that Sidney needed to be seen once every two
  weeks by the Community Psychiatric nurse. There
  was no need to consider assessment under the
  Mental Health Act and no change to his medication
  was necessary.

37
6. Referral Community to Mental Health (GP
Notified)
2. Referrals sent directly between contexts
TMS
1. Appropriate patient data from DB and
additional notes from GP formatted and sent in
Referral message.
3. Recipient application displays data, and
clinician may save to local DB.In the case of
the GP system, Referral event is always included
in shared patient event record
3. Recipient application displays data, and
clinician may save to local DB.
38
Information View
39
Shared Patient Record (SPR)
SPR
other
Patient visits GP, information is collected and
the patient is referred to hospital. GP-related
event messages are written to the SPR.
1
Spine
LSP Summary
LRS
GP (Vision)
Patient Event Record (PER)
PSIS
1
PDS
SDS
NASP Services
SPR
Integration Engine
Patient

• PoC message with details of care event including
• Patient ID (NHS )
• Organisation ID
• Service ID
• Event type
• Event details
• etc.

Notes
2

• Delivery of care to a patient results in the
  collection of information within the care setting
  application database
• Additionally Provision of Care (PoC) messages are
  generated and sent to the SPR
• The SPR stores these care event messages as the
  Patient Event Record (PER)
• Entries within the PER can be summarised and
  viewed via the LSP Summary

Acute (Millennium)
Patient attends hospital and is treated. Patient
information is collected and stored in the Acute
application database. Acute-related event
messages are sent to the SPR via the IE.
2
2
40
SPR Active Relationships
Active Relationship Index
other
Spine
Synonym
NHS
Org / Service
Org / Service
LRS
GP (Vision)
Synonym
NHS
Org / Service
Org / Service
PSIS
Synonym
NHS
Org / Service
Org / Service
PDS
Services
SDS
The SPR processes the received patient event
message and determines whether an active
relationship exists between the patient and a
service. The Active Relationship Index (ARI) is
updated accordingly.
NASP Services
2
SPR
2
Integration Engine
For existing NHS number entries, the Organisation
ID / Service ID pair are copied from the event
message into that entry.
Notes
An event message is sent to the SPR
1

• Care setting applications send patient event
  messages to the SPR as described earlier.
• The SPR adds the patient event message to the PER
• The event is processed to determine any changes
  that need to be made to the Active Relationship
  Index (ARI)
• Where necessary index entries are added, removed
  or extended.
• Synonyms are used for merge / de-merge (see later)

Acute (Millennium)

• PoC message with details of care event including
• Patient ID (NHS )
• Organisation ID
• Service ID
• Event type
• Event details
• etc.

Services
41
SPR Notifications (generation)
Active Relationship Index (ARI)
other
Spine
Synonym
NHS
Org / Service
Org / Service
LRS
3
GP (Vision)
Synonym
NHS
Org / Service
Org / Service
Org / Service
4
PSIS
Synonym
NHS
Org / Service
Org / Service
PDS
Services
SDS
The first step is for the SPR to check active
relationships and create a new relationship for
the acute organisation / service.
NASP Services
3
4
SPR
The SPR then generates notifications for each of
the services listed against that patient in the
Active Relationship Index (other than the service
from which the event message was received)
Integration Engine
4
Patient
Patient attends hospital (e.g. AE)
1
Notes
2

• Receipt of an event message by the SPR triggers
  active relationship checks
• Where an active relationship is considered to
  exist a notification is sent via the IE to each
  Service with which a relationship is associated
  (other than the latest event originator)
• The notification message will contain sufficient
  information for the receiving application to
  further route and display the notification.

An event message is sent to the SPR
Acute (Millennium)
Community Health (RiO)
5

• Notification Message
• Organisation ID
• Service ID
• Patient ID (NHS )
• Patient name
• Event type
• Event details

Notification received by care setting
Services
Services
42
SPR Notifications (processing)
other
InBox for Team A
Spine
Activity information
LRS
Activity information
GP (Vision)
PSIS
Activity information
--N-- Patient 1234567
PDS
Activity information
Services
SDS
Receipt Processing
NASP Services
1
Notification sent by SPR to care setting service
SPR
Integration Engine
Inbox shows that notification has arrived with a
given patient id and then perform IG checks when
user accesses notification.
3
Notes

• On receipt of a notification message each care
  setting application will route that message to
  the appropriate inbox associated with the
  indicated service.
• Appropriate IG checks will be performed before
  allowing a user to see anything other than the
  patients ID. These may be performed before
  displaying the notification or at the point of
  accessing the notification.

Acute (Millennium)
Community Health (RiO)
2

• Notification Message
• Organisation ID
• Service ID
• Patient ID (NHS )
• Patient name
• Event type

Notification received by care setting service
from SPR
Receipt Processing
Services
Services
43
Integration View
44
Summary

• The integrated solution is driven by the business
  requirements for cross care setting business
  processes and information sharing
• The diverse data repositories serve different
  purposes the integrated solution leverages them
  to support London wide clinical care
• The messaging solution supports proactive
  notification of clinical events using Active
  Relationships

45
London Roadmap
V5
V6
V7
V4
R0
R1/ LC1
R2/ LC2
R3/ LC3
V2
V1
GP 400
RC3
Vision 3
IC200
IC100
IC300
46
IG Roadmap
IR1
IR2
V5
V6
V7
V4

• consent
• RBAC
• RiO2RiO
• LRs
• SE

• consent
• RBAC
• RiO2RiO
• Own LRs

• consent
• RBAC
• Own LRs

• proprietary

(MH CH)
R0
R1/ LC1
R2/ LC2
R3/ LC3

• consent
• RBAC
• OutReach
• LRs
• SE

• consent
• RBAC
• OutReach
• LRs

• consent
• RBAC
• Own LRs

• proprietary

(Acute)
V2
V1

• consent
• (RBAC)
• Local LRs

• consent
• RBAC
• LRs

(e-SAP)
inps Vision
RC2
RC3
Vision 3

• consent
• RBAC
• LRs
• SE

• consent
• (RBAC)

• consent
• RBAC

(GP)
IC300
IC200
IC100
PACS

• consent
• RBAC

• proprietary

2007
2008
2009
2010
47
Spine Integration Roadmap
IR1
IR2
V5
V6
V7
V4

• SSO
• PDS
• ETP
• PSIS

• SSO
• PDSCAB

• SSO
• PDS
• CAB

• Standalone

(MH CH)
R0
R1/ LC1
R2/ LC2
R3/ LC3

• SSO
• PDS
• CAB
• PSIS
• ETP?

• SSO
• PDS
• CAB
• 3 discharge messages

• SSO
• PDS
• CAB

• CAB

(Acute)
V2
V1

• TBC

• TBC

(e-SAP)
inps Vision
RC2
RC3
Vision 3

• SSO
• CAB
• PDS
• ETP
• PSIS

• CAB
• SSO
• PDS
• ETP
• GP summary?

• SSO
• CAB
• PDS
• ETP
• GP Summary

(GP)
IC300
IC200
IC100
PACS

• TBC

• TBC

2007
2008
2009
2010