1. How standards for integration will enable key business objectives. Jagdip Grewal Chief Technical Architect

2. Agenda CFH Update and Why are we here? Enterprise Architecture – Integration Domain CFH and HL7 CDA The Future

3. Our Objectives To deliver a 21st century health service through efficient use of technology to: Enable and improve Access and Choice Enable care pathways and patient focus Improve accuracy in treatment Create opportunities for improved efficiency Create opportunities for real NHS reform

4. …and the NHS in England is BIG  In a typical week: 6 million6 million people will visit their GPs 800,000More than 800,000 outpatients will be treated 10,000Over 10,000 babies will be delivered by the NHS 50,000NHS ambulances will make over 50,000 emergency journeys 8.5 millionPharmacists will dispense approximately 8.5 million items 1,200 3,0001,050NHS surgeons will perform around 1,200 hip operations, 3,000 heart operations and 1,050 kidney operations millionsLabs and associated services will provide results on millions of tests 3 million  Or another way, 3 million critical transactions a day There is no way to do this on a small scale

5. Supply - - side Reforms Demand - - side Reforms Transactional Reforms System Management Reforms Better care Better patient experience Better value for money System Management Standards, Accreditation & Inspection Values, Brands & Codes Planning, Performance & Assessment Financial Strategy Wider Review of Regulation Payment by Results Information Strategy & Systems Payment & Settlement Plurality in Primary Care Foundation Trusts Plurality / Contestability Independent Sector NHS Treatment Centres Out of Hospital 18 Weeks Workforce Patient Choice Commissioning PCT Development Patient Info Long Term Conditions Demand Management Motivation: Why ?

6. Progress to date NHS Connecting for Health deployment statistics (to 3 October 2006)  276,899 users registered for access to the Spine  5,654,360 prescription messages transmitted using the Electronic Prescription Service (EPS)  1,348,277 Choose and Book bookings  70,907,782 images stored using Picture Archiving and Communications Systems (PACS)  15,686 National Network (N3) connections Thousands of systems exchanging information  Over 9000 Accredited Systems connected

7. Why are we here? Enable the best integrated healthcare by the time these children grow up!

8. Agenda CFH Update and Why are we here? Enterprise Architecture – Integration Domain CFH and HL7 CDA The Future

9. Enterprise Architecture – Integration is a key domain

11. Integration Architecture Domain - Standards CFH is committed to HL7  Use of V3 decision in 2003!  Still needs development work and we will continue to work within HL7 -e.g. HL7 Tooling Collaborative (http://www.hl7toolingcollaborative.org/)http://www.hl7toolingcollaborative.org/ Strategic alliance between HL7, ISO and Cen  Agreed at joint meeting in Geneva, October 2006  Aim to co-ordinate work programme and joint standards  Plan to pull in others SDOs to join (e.g. SNOMED)

12. Allow Incremental Rollout All care settings will be upgrading systems for several years to come. A release from a supplier could take 1-2 years to rollout across a cluster. Need to enable a way of transferring information between systems which allows  For different levels of SNOMED compliance of systems  And for those which are not compliant, to allow the clinician to view the information

13. How do clinicians work? Need to be aware of information overload  The right information is key Clinical coding teams  Will be here for a while yet Business change in NHS will take a while

14. Need to enable increasing coding of clinical flows Post- coordination Full Pre-coord Partial Pre-coord Text Provider of Care’s System Primary Physician’s System Post- coordination Full Pre-coord Partial Pre-coord Text Snomed Compliance Benefits

15. Agenda CFH Update and Why are we here? Enterprise Architecture – Integration Domain CFH and HL7 CDA The Future

16. CFH and HL7 CDA In Q2 06 a decision was made to adopt HL7 Clinical Document Architecture as the basis for all clinical messages. This supports the vision of allowing messages to flow between organisations and be processed at the capability of the receiving system.  The minimum would be to view the message as a document.  GP summary message v1 (MIM 4.2) is not HL7 CDA.  Other MIM domains (Emergency, Discharge etc) are being amended to be HL7 CDA compliant to be published shortly.

17. About CDA – a reminder CDA documents carry a number of different pieces of information:  Metadata – information for document management e.g. type of document  Text – a textual representation of the clinical content which is rendered for human readability  Coded – a fully structured representation of the clinical content which is used for decision support

18. Components of CDA The clinical content in a CDA Release 2 document is stored in:  Sections -Allowing for classification and storage of narrative text -NHS CfH will define business headings and CRE Type sections  Entries -The coded elements of the document -These will be constrained from the CDA CSP using templates

19. ED Care Provision Event

20. Templates Templates will allow constraints to be applied to the section, entries and roles of the CDA document The mechanism for templating is currently being developed by Comms and Messaging It will allow for greater extensibility of the messages using a modular approach as seen in MIM 4.1.04 A library of templates will be maintained to meet changing requirements The following classes will have templates applied:  Sections -e.g. Business Headings, CRE Types etc  Entries -e.g. Clinical Statements  Roles -e.g. author

21. Template List Identifier The template list identifier lists the allowable templates in the same way a vocabulary lists the allowable codes It allows for greater extensibility of the messages as new templates can be added to the list removing the necessity to update the base model The format of the identifier will be: NPFIT-nnnnnn# Examples: NPFIT-000001#Role NPFIT-000002#ClinicalStatement

22. Section Template Example The Template in ClinicalStatement is an abstract choice. The template which will actually appear in it’s place in an instance is one from the template list identifier NPFiT-000005#Section

23. Abstract Choice

24. Clinical Statement Template Example The Template in AuthorChoice is an abstract choice. The template which will actually appear in it’s place in an instance is one from the template list identifier NPFiT-000001#Role

25. Validation The instances will carry the generic CDA class names and will be validated against the CDA schema The instances will be validated against the templates using a validation tool set which could include schema, schematron etc CDA Templates Instance validation

26. What will this achieve? Flows to and from different care settings e.g. Acute to GP  Without all systems being -HL7 v3 compliant -Fully SNOMED compliant Earlier benefits from information flows through CFH infrastructure (i.e. Spine)

27. Agenda CFH Update and Why are we here? Enterprise Architecture – Integration Domain CFH and HL7 CDA The Future

28. Devices (MRI etc.)  Will collect more and more data Life sciences industry and genomics Personalised health care? Standards - Long and interesting journey ahead….

29. Summary CFH committed to HL7  Key standard in its Enterprise Architecture CFH has decided to use HL7 CDA Release 2 for clinical information flows  Using templates to constrain part of the document