1 / 11

NHS Connecting for Health A National Framework For Electronic SAP Implementation

NHS Connecting for Health A National Framework For Electronic SAP Implementation. Agenda. Introduction – background & outline. Why an architecture? The architecture framework Project approach. Timetable. Introduction. Background

colum
Download Presentation

NHS Connecting for Health A National Framework For Electronic SAP Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NHS Connecting for Health A National Framework For Electronic SAP Implementation

  2. Agenda • Introduction – background & outline. • Why an architecture? • The architecture framework • Project approach. • Timetable.

  3. Introduction • Background • Different paces and approaches to implementing electronic SAP across the country. • Uncertainty for local care communities and system suppliers. • Boundary difficulties for some service users. • A need to develop a consistent national framework. • Project Outline • Initiated by NHS Connecting for Health. • Reporting to ESCR Board, Care Records Development Board & National Programme Board of NHS CFH. • To develop an implementation plan and business case for electronic SAP for England. • Project board chaired by David Johnstone, with representation from health, social services, DH, ODPM, DfES and the Cabinet Office. • First stage of the project will define and evaluate options for electronic SAP. • Subsequent stages will develop an implementation plan and business case.

  4. Why an architecture framework? • To provide a overall structure with clearly defined components within which to: • Assess options. • Assess current situation. • Develop plans. • The framework will: • Ensure completeness of coverage. • Help understand the relationship between a complex set of resources and constraints (people, processes, systems, organisations, regulatory requirements). • Provide transparency of evaluation criteria. • Provide a basis on which to maintain and develop work in future.

  5. The Architecture Framework (1)

  6. The Architecture Framework (2)

  7. Assessment of information systems architectures • Identify all valid potential architectures. • Develop criteria for their evaluation (for example): • Fit with business process (SAP). • Information governance. • Performance: reliability, availability, responsiveness, recoverability  • Technical (including standards-compliance). • Fit with established systems architectures. • Maintainability. • Conduct the evaluation. • Publish the package for wide consultation: • The candidate architectures. • The criteria. • The outcome  recommendations.

  8. Attributes of the Information Systems Architecture Choices to be made through applying the evaluation criteria: (NB: not all the choices are mutually exclusive; a choice made in one attribute will in many cases limit the choice available in another.) • Applications structure: brokering ('pull-on-the-fly'), dedicated repository, specific system shared, peer-to-peer. • Technical Structure: Web-based, other thin-client/server, thick-client/server. • Network services: Point-to-point messaging, messaging hub, instant messaging. • Person Index: local identity indices, central index (e.g. Spine) • User interface: agency-specific user interfaces, one common user interface • Information exchange: automated business rules, manual control of presentation, user control of system-system update. • Information delivery mechanism: push, pull, neither. • Schemas: common-defined or mapped (coding, definitions and glossary). • Technical standards: messaging (e.g. HL7), email, XML schemas (e.g. NAC). • Security: single sign-on, digital signatures, firewalls, encryption, intrusion detection, identity management (these are NOT choices, but each may itself offer choices).

  9. Fact finding • Review current documentation • Meet with stakeholders • CfH, Gov Connect, LSPs, solution providers, etc. etc. • Capture information in a structured way (next slide) • to manage all the information, and to spot the gaps. • Identify architectures in use and planned for e-SAP and other multi-agency information exchanges. • This is an iterative process …………

  10. Consultation • Use SAP websites of Centre for Policy On Ageing and CfH. • Work with established forums (ADSS IMG, Adaptor’s Club, etc.). • Disseminate through SAP Leads at every level. • Meet key organisations: to be determined during fact-finding stage. • Respond to queries and issues registered through the websites. • Maintain a communications log.

  11. Timetable • MARCH: • Fact-finding and raising awareness • Building the Architecture Framework • APRIL / MAY: • Undertake the consultation. • MAY: • Review validity of outcomes and prepare final report for Project Board.

More Related