NHS Healthcare Interoperability Best Practice Guide

1. HL7UK Interoperability Strategy Pack Charlie McCay Intel / Ramsey Systems

2. Motivation • There are many examples of successful interoperability projects in the NHS, and this best practice is not being replicated • There are many ways for healthcare interoperability projects to go wrong • Support is needed for IT managers new to the NHS to find healthcare interoperability guidance

3. Related work • CFH Interoperability Toolkit • focused on connectivity with CFH-funded systems • Closely collaborating • IHE profiles • Technical specifications for specific use cases, will be referenced by the package • STEP process • Generic procurement process • Others…

4. Scope Principles • NOT restricted to HL7 standards • Any material that will help with the delivery of interoperability projects • Reference other material, do not replicate • Single solution where there is consensus, capture different views where useful • Modular document that will be subject to regular maintenance • Deliver something useful ASAP

5. Out of Scope • Out of scope but needed • Case Studies • Technical Specifications • Detailed Technical Architecture • Implementation framework specifications • Work done (well) elsewhere • More that 20 pages

6. In scope • Examples of things that worked • Examples of things that did not work • Business cases • Artefacts needed before, during and after an interoperability project • What is needed for a set of projects to work (a program)

7. Success Criteria • Trust IT leads find the document useful • Document download volumes • Feedback requests • Contributors find the collaboration useful • Meeting attendance • Volume and quality of contributions • Meaningful ballot pool • Suppliers support the recommendations • References to the document in product collateral • Feedback requests • Constructive engagement with CFH, IHC, Scotland, HL7, IHE, LSPs etc

8. Document Governance and Distribution • Document approved by HL7UK vote • Voting by HL7UK members only • Document development in open forum • Meetings and wiki open to all interested parties • Document freely available • Not restricted to HL7UK members • Document format. • Initial drafts developed on MediaWiki • Release version: • Source: DITA?, HL7 publishing XML?, Word?? • Rendering: HTML (online browsing with persistent URLs) • Rendering: PDF for printed copy

9. Resolution principles • Consensus on single solution for single issue where possible • Where there are multiple possible approaches document each, with some discussion of rationale for variety • If good enough text not agreed, then section marked as “Deferred to subsequent version” and discussion captured in development environment

10. Long Term Vision • Initial release • prove the process • demonstrate the value of collaboration • Deliver a useful document • In subsequent releases: • Reference more case studies • Greater coherence (technical and business architecture) • Evolved relationship with related work

11. Document Sections • Introduction • Scope, method, governance • Related work • Organisations • Reference material • Project Lifecycle • Use Cases

12. Project Life cycle • Just use Prince? Before, after, … • Key areas for sharing best practice • Project Vision • Business Case • Work package definition • Technical implementation • Process impact management • Communications Plan • Metrics to measure success

13. Use Cases • Discharge Process • PACS interoperability • Clinical repository (“trust level spine”) • ADT • Pathology requests / results

14. Timelines for project • Meeting supported an “agile” approach • 18 weeks to produce document • Useful product delivered every two weeks • Initial tasks to include • Production of Project Scope document • Define responsibilities, scope etc • Questionnaire for Trusts • Who to contact • What questions to ask • Program lifecycle framework