when is a standard not a standard? the case for unifying lsp approaches to local interfacing
DESCRIPTION
HL7 UK Conference – October 2006. When is a standard not a standard? The case for unifying LSP approaches to local interfacing. Philip Scott Head of IT Projects & Development Portsmouth Hospitals NHS Trust Co-chair, HL7 UK NHS Implementers group. Why discuss this?. - PowerPoint PPT PresentationTRANSCRIPT
Philip ScottHead of IT Projects & DevelopmentPortsmouth Hospitals NHS Trust
Co-chair, HL7 UK NHS Implementers group
HL7 UK Conference – October 2006
When is a standard not a standard?The case for unifying LSP approaches to local interfacing
Why discuss this?
There is an opportunity now to mitigate migration/maintenance problems down the line as CRS deployments progress
There is an opportunity to win over clinical enthusiasm for “yet another system”
If an Enterprise Architecture is being adopted, the “Enterprise” must be complete and not have holes or gaps round the edges
Aim: generate discussion not give answers
Topics
Are standards a good idea?But we’ve already got standards!But what about …?Are there workable solutions?Questions
Are standards a good idea?
Yes“Enable clinical semantic interoperability”Jolly good!Well that’s alright thenThe end(nearly…)
But we’ve already got standards!
Clinical information content: Snomed CTElectronic messaging: HL7 v3But – what about now?
What about…
Existing non-HL7 message flows supporting operational needsPMIP and things hanging off it or disguised
inside itDischarge summaries, clinic letters, OOH…
“Legacy” system interoperabilityInformation flows outside MIM scope
1 - NASP Interface – HL7 V3 2 - Existing Systems Interface – HL7 2UK (VA.2) 3 & 4 - Departmental Systems Interface – HL7 V2.3/V2.4
CSC P1R1 Data Centre
CSC P1R1 Interfacing
P1R1 NASP
EBS ETP PDS GPtoGP
NASP MHS
Trust A
Existing System 1 (ES -A1)
Existing System 2 (ES -A2)
Existing System 4 (ES -A4)
Trust Interfacing Engine - A (TIE-A)
Existing System 3 (ES -A3)
Trust B
Existing System 3 (ES -B3)
Existing System 4 (ES -B4)
Existing System 2 (ES -B2)
Existing System 1 (ES -B1)
Trust Interfacing Engine -B (TIE-B)
1b
Data Centre Hosted Departmental System
TheatresMaternity
P1R1 PAS
i.IE
Lorenzo
i.CM i.PM
NASP Interfacing Engine (NASPIE)
Interfacing Engine (EBIE)
Existing System Interfacing Engine (ESIE)
1a
3a
2a
2b
2b
2b
2b
2b
2b
4a
4b
4a
4b
4b
LRS SSB SDS
Maternity IE
Theatres IE
CSC Alliance
Fujitsu
Fujitsu Data Centre
Trust System
Trust System
Trust System
Trust System
Trust System
Trust System
Trust TIEH
L7 2
.3
HL7
2.3
HL7
2.3
HL7
2.3
Hosted TIE
DIE
HL7 V2.3OpenEngine
Millennium
HL7 V2.3
BT
Have market forces simplified this already?
HL7 v2 alone does not offer semantic consistency (to say the least)
When you’ve seen one… [laugh now]“Rampant optionality”Given Benson’s eq.1: Therefore:
)(
1
LSPsni
iiii ncp
ncp
Information flows outside MIM scope
Information flows outside MIM scope
Other issues of scope:Realm (home countries, Europe, world)Service (NHS, social care, police, YOT,
housing, education…)And more immediately for England:
Provider type (NHS, private sector, military)LSP region (cross-cluster flows)LSP sub-units (deployment groups ≠ clinical
networks, initial “external” visibility = 0)
Information flows outside MIM scope
Current approach is pragmatic commercial reality rather than “ruthless standardisation”
CSC: UK vA.2, v2.3, v2.4 BT: UK A.2? Fujitsu: v2.3 Which v2.3? Which v2.4? Which UK A.2? Issues:
Maintenance: no re-use possible, upgrades complex Risk of varying semantics or data quality workarounds Cross-boundary flows: specialty systems, cancer networks,
ISTCs, tertiary referrals, lab to lab
Are there workable solutions?
Use IHE profilesDevelop HL7 v2.5 UK (?)Change to HL7 v3 (UK?)Develop Logical ModelsHL7 UK NHS Implementers subgroup
favoured some sort of logical model to constrain v2
Certifiable testing (≈ sandpit etc)
And what about…?
“Legacy” systems interoperabilityNeeded until children grow up (at least)Eventually true EPR, not for some yearsSpecialty systems will have to co-existRepositories for unsolicited results will
have to co-exist (not to mention EDM)Can we make it easier for clinicians?
Legacy system interoperability
HL7 CCOWFew applications have it out of the boxSome add-on products offer CCOW-like
behaviour/functionalityFront-end integration may be easier in
some cases than a messaging interfaceClinicians will bite your hand off for
patient context synchronization
Legacy system interoperability
GOSH is procuring a solution via OJEUPHT is currently procuring via CatalistLSPs apparently take varying stances
(flavours of No)Is CFH interested…?Could be low-hanging fruit!
Legacy system interoperability
Legacy system interoperability
Legacy system interoperability
Legacy system interoperability
Legacy system interoperability
Legacy system interoperability
Legacy system interoperability
Legacy system interoperability
Legacy system interoperability
Conclusion
There is an opportunity NOW to mitigate migration/maintenance problems down the line as CRS deployments progress
There is an opportunity to win over HUGE clinical enthusiasm for “yet another system”
If an Enterprise Architecture is being adopted, the “Enterprise” must be COMPLETE and not have holes or gaps round the edges
Discuss…