Docstoc
EXCLUSIVE OFFER FOR DOCSTOC USERS
Try the all-new QuickBooks Online for FREE.  No credit card required.

eCare Conceptual Solution Overview

Document Sample
eCare Conceptual Solution Overview Powered By Docstoc
					Report



         Data Standards & eCare Division



eCare Conceptual Solution Overview



                    001-11334N-010




                       Version 1.1
                        Release




                Copyright of the Scottish Ministers
Document Control
                                         Document Configuration
  Title               eCare Conceptual Solution Overview
  Status              Release
  Filename            eCare Conceptual Solution.doc
  Author(s)           Robbie Harris
  Issuer              Scottish Executive
  Issue Number        1.1
  Issue Date          01/09/05
  Classification      Distribution to specified list only
  Supersedes          Draft High Level Component Description for eCare Program (001-11334N-002)


                                           Document Approvals
  Name                  Position                       Signature                              Date
  Stuart Graham         eCare Technical                                                       01/09/2005
                        Coordinator (Scottish
                        Executive)


                                              Document History
  Version      Date           Author            Description
  0.1          09/01/2004     RH                Initial draft for internal comment
  0.2          20/01/2004     RH                First Draft
  0.3          23/01/2004     RH                Incorporates feedback from review
  0.4          30/01/2004     RH                Incorporates feedback from consultation
  1.0          20/08/2004     RH                Release
  1.1          01/09/2005     RH                Updated document to refer to new division


                                              Document Review
  Name                                Position                                Company
  Elaine McKinney                     eCare Programme Manager                 Scottish Executive
  Stuart Graham                       eCare Technical Coordinator             Scottish Executive
  Ken Parsons                         eCare Technical Coordinator             Scottish Executive
  Alistair Gibson                     Programme Manager                       Atos Origin
  Alexander Rattray                   Technical Architect                     Atos Origin
  Martin Irving                       Head of SCI Development                 Common Services Agency



001-11334N-010
eCare Conceptual Solution Overview                                                      Version: 1.1 Release
                                                                                                    01/09/05
                                                   Page 2
                                         Document Distribution
  Name                               Position                    Company
  Blythe Robertson                   Policy Officer              Scottish Executive
  For Public Distribution




001-11334N-010
eCare Conceptual Solution Overview                                         Version: 1.1 Release
                                                                                       01/09/05
                                                 Page 3
Table of Contents

1.                 Introduction                                       6
1.1                Background                                         6
1.2                Overview                                           6
1.3                Stakeholders                                       7
1.4                Scope                                              7
1.5                Out of scope                                       7
1.6                References                                         7

2.                 Vision Statements                                  8

3.                 Design Principles                                11
3.1                Reference Model                                  11
3.2                Document Context                                 12

4.                 Design Rationale                                 13
4.1                Overview                                         13
4.2                Solution Constraints                             13
4.3                Assumptions                                      13
4.3.1              Requirements                                     13
4.4                Key Technical Decisions                          14
4.4.1              Consented Data Store                             14
4.4.2              National Data Models                             14
4.4.3              Hosting                                          14
4.4.4              Security                                         14
4.4.5              Directory Service                                15
4.4.6              Microsoft Platform                               15

5.                 Conceptual Model                                 17
5.1                Component Description                            18

001-11334N-010
eCare Conceptual Solution Overview                  Version: 1.1 Release
                                                                01/09/05
                                           Page 4
5.1.1              Agency Applications                               18
5.1.2              eCare Adaptor                                     18
5.1.3              eCare Framework                                   18
5.1.4              eCare Safe Haven                                  18
5.1.5              Multi Agency Store (MAS)                          18
5.1.6              eCare Index                                       19
5.1.7              eCare Matching                                    19
5.1.8              eCare Messaging Service                           20
5.1.9              eCare Viewer                                      20
5.1.10             Security                                          20
5.1.11             Directory                                         20
5.1.12             eCare Applications                                20
5.1.13             eCART                                             21
5.2                Conceptual Extensibility Models                   21

6.                 Derived Logical Model                             23

7.                 Derived Physical Model                            24




001-11334N-010
eCare Conceptual Solution Overview                   Version: 1.1 Release
                                                                 01/09/05
                                           Page 5
1.      Introduction

This document sets out the initial conceptual solution for the MGF-2 eCare project. This
describes the overall ‘shape’ of the architecture; the major blocks of functionality and their
relationships, and is the basis for common understanding regarding the same.

The Scottish Executive acknowledges the contribution of Atos Origin to the production of this
document.


1.1     Background
The eCare Programme was originally conceived to support the objectives of the 21st Century
Government and Joint Future agendas, and was a fundamental part of the Modernising
Government Fund – Round 1 (MGF-1). MGF Round 2 sought to maximise the benefit of the
MGF-1 outcomes, by rolling out the framework to other areas of Scotland and to other client
groups (e.g. children). In this way, the programme has continued to support the long-term
objectives of service modernisation and improvements in the citizen’s experience.

eCare, and its sister programme, the Social Care Data Standards Project, have evolved to
become the Data Standards and eCare Division of the Scottish Executive based within the
Education Department, but working closely with Education, Health and Justice


1.2     Overview
Systems architecture concerns the gross organisation of a system described in terms of its
components, their externally visible properties and the relationships amongst them - from a
physical infrastructure, platform, communications, security, support, and applications
software perspective. Systems architecture describes what is in a system, and is itself an
abstract description of the system. Architecture simplifies and is constraining. Essentially
systems architecture is the most abstract depiction of a system that reflects critical
requirements and constrains all subsequent requirements.

This document presents a high-level Project. IEEE Standard 1471-2000 "IEEE
Recommended Practice for Architectural Description of Software-Intensive Systems", which
has informed this document, states that the "[q]uality of an architectural description refers to
its capability to meet the needs and concerns of the stakeholders for whom it was
constructed." The stakeholders for this document, as defined in the eCare Programme
Project Initiation Document, are listed in the following section.




001-11334N-010
eCare Conceptual Solution Overview                                             Version: 1.1 Release
                                                                                           01/09/05
                                             Page 6
1.3      Stakeholders

    Stakeholder
    eCare Programme Board
    eCare Single Shared Assessment Project Board
    eCare Children’s Services Project Board
    eCare Learning Disability Project Board
    eCare Technical Working Group
    eCare Operational Development Working Group
    Social Care Data Standards Project
    Vendor Group
    Local Project Boards and Consortia



1.4      Scope
This document will:

     •   provide a high-level technical solution for the eCare project from an Application
         viewpoint

     •   describe the design principles and rationale employed

     •   document key prior assumptions and decisions


1.5      Out of scope
This document does not:

     •   propose a complete solution

     •   consider statutory or legal issues relating to the inter-agency sharing of personal and
         sensitive personal data by the eCare Programme


1.6      References

Reference         Title                                                          Date
1                 eCare Programme PID                                            2003
2                 eCare Technical PID 1.1                                        2004
3                 eCare Security Architecture (001-11334N-009)                   2004

001-11334N-010
eCare Conceptual Solution Overview                                             Version: 1.1 Release
                                                                                           01/09/05
                                                Page 7
2.      Vision Statements

The following table documents the current vision statements understood to be applicable to
the conceptual solution. No formal requirements analysis and documentation has as yet
been undertaken. As a result these statements may change in quantity, scope and definition.
We have assumed that all statements documented to date are have no priority and a status
of ‘Not Agreed’. The statements are maintained as a requirements catalogue available in
from the project team. Note that since this document presents only the conceptual solution,
and not the complete architecture as a whole, not all of these visions will be met in this
conceptual overview.

  Description                                                                 Stakeholder
  Store client/patient entry for each source system                           eCare Technical PID
  Specify a minimum standard data set for Person and Assessment
  information for sharing through a central store and store that minimum
  personal information.                                                       e-CART Overview
  The system will enable Assessment and other detailed data to be
  stored and shared.                                                          e-CART Overview
  Implement a Scottish standard for storing Activity Recording information
  within Single Shared Assessment, Child Services and Learning
  Disability.                                                                 e-CART Overview
  Have the ability to generate and maintain Person and Activity
  Recording information that can be shared across agencies                    e-CART Overview
  Maintain Activity Recording information including Referral, Assessment
  information (questions and answers), Care Plans (what you wish for),
  Services (what is delivered), Reviews and Contacts.                         e-CART Overview
  User definable ability to store additional data items against eCare index   eCare Technical PID
  Maintain a directory for all practitioners                                  eCare Technical PID
  Ensure that all data maintained has a full audit history.                   e-CART Overview
  Enforce centrally defined data standards.                                   e-CART Overview
  Report against MAS data. This could include statistical as well as
  individual reporting.                                                       e-CART Overview
  Provide a single shared view of a person's data                             eCare Technical PID
  The user must be able to locate and view any stored information that
  they are entitled to see about the person that they are interested in.      eCare Team
  Have an automatic searching and matching capability                         eCare Technical PID
  The system must authenticate the user and allow them to see the
  information that they are allowed to see and not allow them to see any
  information that they are not entitled to see.                              eCare Team
  Ensure that only “consented” data is available to external agencies.        e-CART Overview




001-11334N-010
eCare Conceptual Solution Overview                                                  Version: 1.1 Release
                                                                                                01/09/05
                                                 Page 8
  Description                                                                  Stakeholder
  Provide security to ensure that all personally identifiable information is
  stored to a level of confidentiality that meets Scottish Executive
  requirements                                                                 e-CART Overview
  Allow locally defined assessment information to be maintained to meet
  a specific local business need.                                              e-CART Overview
  Enforce that centrally controlled assessments (e.g. Carenap) are
  controlled, maintained and implemented according to National User
  Group requirements.                                                          e-CART Overview
  Compile single 'trusted' eCare view of client/patient details                eCare Technical PID
  Broadcast updates to collaborating systems                                   eCare Technical PID
  Protect the eCare Framework and Application servers and network
  against unauthorized network access or misuse, using firewalls, anti-        eCare Security
  virus software, intrusion prevention, and other appropriate measures.        Architecture
  Provide a Technical Product Set made up of components suitable for
  use by all MGF2 partners                                                     eCare Programme PID
  Provide the rollout to the partners of Hardware suitable for hosting the
  Technology Product Set                                                       eCare Programme PID
  Provide support to the local projects and consortia to enable their local
  project objectives to be met                                                 eCare Programme PID
  Technical Product Set and hardware implementation over 7 NHS Board
  areas and 16 local authority partners                                        eCare Programme PID
  Identification of data sets for interpretation in to XML schema standards
  and definition of the above datasets                                         eCare Programme PID
  To ensure that wherever clients live, information about them will be
  shared by relevant practitioners whether or not the Health and Local
  Authority boundaries are coterminous.                                        eCare Technical PID
  It will be critical that the technology will allow access by multiple
  agencies with different sharing requirements with partners.                  eCare Technical PID
  The fact that the technology will be used in different local settings
  should not detract from the requirement that standards are maintained.       eCare Technical PID
  Consistency of information no matter where services are provided             eCare Technical PID
  Consistency of view of the jointly assessed user’s needs.                    eCare Technical PID
  Reduction in duplication of services so enabling more services to be
  provided                                                                     eCare Technical PID
  If the patient moves the records can appear to move with then reducing
  the number of times the same question is asked                               eCare Technical PID
  Development of an extensible generic tool which will give practitioners
  access to a web based application with the capacity to develop facilities
  to meet local requirements                                                   eCare Technical PID
  Mechanisms to allow automatic data exchange between health and
  social work corporate systems                                                eCare Technical PID


001-11334N-010
eCare Conceptual Solution Overview                                                   Version: 1.1 Release
                                                                                                 01/09/05
                                                   Page 9
  Description                                                                   Stakeholder
  There should be one version of the eCare repository (multi agency
  store)                                                                        eCare Technical PID
  There may be multiple instances of the eCare repository                       eCare Technical PID
  There is a requirement to share agreed standard data sets to allow
  information sharing across Local Authority and Health Board
  boundaries and with central agencies                                          eCare Technical PID
  The eCare repository must interact seamlessly with the Extensible
  Confidentiality and Activity Recording Envelope                               eCare Technical PID
  The Patient/Client Index must have direct links to the NHS Scotland
  CHI/UPI to maintain patient demographics and GP details                       eCare Technical PID
  There should be a single version of the eCare messaging service               eCare Technical PID
  There should be a single Health and a single Social Work and the
  facility for layering a single Education message set                          eCare Technical PID
  Elements of the message set should be standard across health, social
  care and education e.g. patient/client management and confidentiality
  and consent management                                                        eCare Technical PID
  There should be a single version of the messaging error handling
  application                                                                   eCare Technical PID
  A flexible and modular application able to run with and between
  different systems                                                             eCare Technical PID
  Can be modified by users under controls to meet local needs                   eCare Technical PID
  Ability to exchange structured data sets with the eCare messaging
  service                                                                       eCare Technical PID
  Patients/Clients should be identified on a single index                       eCare Technical PID
  Patient/Client Index should be supported by the NHS Scotland CHI/UPI
  to maintain patient demographics and GP details                               eCare Technical PID
  Patient/Client consent will be registered and maintained on the index         eCare Technical PID
  A notification system will alert practitioners when patient/client
  information has changed                                                       eCare Technical PID
  The information sharing solution must be capable of supporting
  interaction between multiple primary care organisations and multiple
  local authorities                                                             eCare Technical PID
  Information has to be exchanged on a transactional basis and as close
  to real time as technically possible. The appropriate practitioner(s) need
  [to be] alerted when any significant event has affected a patient/client in
  their care. The exchange of information must be patient/client centred
  and be structured to match the business process.                              eCare Technical PID




001-11334N-010
eCare Conceptual Solution Overview                                                    Version: 1.1 Release
                                                                                                  01/09/05
                                                  Page 10
3.      Design Principles


3.1     Reference Model
An Architecture Reference Model provides a description of the architectural and design
characteristics of the proposed solution presented in this document. Each layer in the
reference model represents a set of information that describes particular attributes of the
solution. The Reference Model presented here (which is based on the Microsoft Architecture
Reference Model) is independent of and applicable within best-practise software intensive
architectural approaches and methodologies such as MSF, RUP, RM-ODP and 4+1. The
following table shows the Reference Model.

                     Business Problem
                     Describes: The result the business is trying to accomplish
                     Typical Deliverables: Diagrams and text providing business
                     context and desired outcomes

                     Conceptual Solution
                     Describes: The overall architecture of the solution
                     Typical Deliverables: Diagrams and text that describe the shape
                     of the overall solution including major blocks of functionality and
                     their relationships

                     Logical Services
                     Describes: The major logical services required to realise the
                     solution
                     Typical Deliverables: Diagrams and text describing the specific
                     services required to deliver the functionality and the relationships
                     between the services

                     Physical Services
                     Describes: How the specific technologies will be used to create
                     the required services
                     Typical Deliverables: Diagrams and text that detail the solution’s
                     overall physical characteristics

                     Implementation
                     Describes: Implementation specific attributes of the solution
                     Typical Deliverables: Diagrams and technical specifications
                     describing the implementation requirements of the solution


                                        Architecture Reference Model




001-11334N-010
eCare Conceptual Solution Overview                                                          Version: 1.1 Release
                                                                                                        01/09/05
                                                   Page 11
3.2     Document Context
Based on the Architecture Reference Model, the context of this document in relation to the
other architectural documents required for this project is as follows:




                             eCare Architecture Framework Top Level Context

This diagram shows that the Architectural Description for the eCare Programme will be
based upon vision statements (including requirements specifications and other business
context artefacts – such as Project Initiation Documents). This translates to the Business
Problem layer of the Architecture Reference Model.

The Architectural Description itself covers the Conceptual, Logical and Physical layers of the
Reference Model. These will cover the fields of Security, Infrastructure, Data, Applications,
and Support. These fields will individually deliver Implementation layer specific detail. In
addition each field will itself document its conceptual, logical and physical architecture. This
document describes the overall conceptual architecture of the solution at a high level, with an
Application focus.




001-11334N-010
eCare Conceptual Solution Overview                                            Version: 1.1 Release
                                                                                          01/09/05
                                                Page 12
4.       Design Rationale


4.1      Overview
This section describes the key design rationale that the solution is based on – in particular
the main constraints, assumptions, and key technical decisions.


4.2      Solution Constraints
         “In February 2002, Round 2 of the Modernising Government Fund was launched. In
         December 2002 funding of £39.5 million was announced to be provided over the next
         2 years. This time, emphasis has been placed on nurturing the most successful
         initiatives from within MGF1 and taking lessons learned and products developed to be
         rolled out to the larger community. Successful work will be made available across the
         public sector, at minimum cost.”

                                                                  — eCare Programme PID [1]

The conceptual architecture described in this document is therefore constrained by the
outcomes from the MGF-1 projects – i.e. the lessons learned and products developed. The
MGF-1 projects that have delivered outcomes relevant to this conceptual architecture are:

     •   NHS Tayside PCT & Perth & Kinross Council (Care Together)

     •   NHS Forth Valley PCT & Stirling Council

     •   Lanarkshire PCT & North Lanarkshire Council

     •   NHS Scotland SCI Development Programme

     •   West Lothian

     •   SCI Gateway

     •   SCI Store

     •   SCI Integration


4.3      Assumptions

4.3.1 Requirements

At the present time of writing the MGF-2 Business Problem layer is documented by a number
of vision statements contained in a number of documents – mostly Project Initiation
Documents and Business Cases. Both ‘vision statements’ and ‘requirements’ document a

001-11334N-010
eCare Conceptual Solution Overview                                            Version: 1.1 Release
                                                                                          01/09/05
                                            Page 13
result that the business is trying to achieve; the distinction made here is that a ‘requirement’
has been fully analysed, documented and agreed by all stakeholders. Within those terms, the
conceptual architecture described here is based upon vision statements, which are liable to
change as they become formalised. It is also the case that the conceptual solution may be
incomplete as a result. To minimise the risk of potential substantive change, the solution
presented here is necessarily at a high level and broad in scope. So saying this solution
assumes that future requirements analysis will validate the vision statements on which it is
based.


4.4     Key Technical Decisions

4.4.1 Consented Data Store

All data held within the eCare Multi Agency Store (MAS) must have the appropriate and prior
consent for multi-agency sharing. No data – personal, sensitive personal or otherwise –
should be held within the store that cannot be shared by all the agencies that use the MAS.
The eCare MAS must include a mechanism to remove data where consent has been
subsequently withdrawn. Finer grained consent models may be developed and implemented
by local agency consortia as appropriate. In terms of the Data Protection Act, the originating
Agency will be considered to be the data controller.

4.4.2 National Data Models

The eCare Programme will define national data models for the sharing of data. These data
models will ensure consistency and allow for eCare XML messaging and integration
standards to be nationally defined.

4.4.3 Hosting

The eCare Framework will be hosted in many different geographical locations by a local
partner within a consortium of local government agencies. The programme will place no
constraints regarding where the solution is hosted or operated – such decisions will be made
at the local level and may leverage local facilitates and resources as appropriate.

4.4.4 Security

The eCare Framework will employ a Safe Haven or Demilitarised Zone (DMZ) as part of the
security architecture to secure the solution infrastructure and communications protocols. A
Safe Haven is a perimeter network that connects two, or more, other networks – these other
networks being for example Health Care, Social Care, Education, Criminal Justice, etc. Rules
will be implemented to ensure that HTTP/HTTPS are the only ports and protocols permitted
between the Safe Haven and its connected networks, and that such communications
originate from outside of the Safe Haven, i.e. no traffic is initiated from within it. Further
details can be found in the eCare Security Architecture description document [3].




001-11334N-010
eCare Conceptual Solution Overview                                            Version: 1.1 Release
                                                                                          01/09/05
                                            Page 14
4.4.5 Directory Service

A previous draft of this document stated:

        “The eCare Framework will provide the technical means to deliver a directory of
        practitioners, and practitioner groupings. It is currently understood that this directory
        forms the user base of the eCare Framework. The directory service would be
        populated by each consortium of local agencies. The directory service would also
        maintain the roles of each user with respect to the Framework, and provide
        authentication and role based authorization services. This service is only necessary if
        local deployments employ the eCare Applications – and is therefore shown as an
        optional component of the architecture. Note that this decision is currently pending
        and depends on future definition of a security policy, and analysis of application
        security requirements. Should it be verified, Microsoft Windows 2003 Active Directory
        would be deployed as an LDAP compliant directory service.”

Whilst a directory service is still seen as being required in order to support eCare
Applications, it no longer conceptually resides within the eCare Framework. Since eCare
Applications are expected to be hosted within Agency networks, that agency’s existing LDAP
compliant user directory is expected to fulfil this role. If an Agency network does not have an
existing directory service, Microsoft Active Directory will be required.

4.4.6 Microsoft Platform

The technical platform product family for the eCare         Web Services
                                                            are small reusable applications that use
Framework will be provided by Microsoft, namely:            XML, a universal (i.e. non-proprietary)
Microsoft Windows 2003 Server; Microsoft SQL Server         standards-based language for data
2000; Microsoft .NET Framework. It is important to          exchange. They allow data to be
note that these products are used only within the           communicated across the Internet (or an
                                                            internal network) between otherwise
eCare Framework – there is no requirement for clients
                                                            unconnected sources that are enabled to
or Agency Applications to employ these products. The        host or act upon them, for example:
decision to use the Microsoft platform is that of the
                                                            Client-to-Client: so called ‘smart clients’
eCare Programme team and is in part based on the            or devices can host or apply Web Services
prevalence of the platform at eCare target deployment       that allow data to be shared
sites. No comparative evaluation of platforms has
been undertaken by Atos Origin on the eCare                 Client-to-Server: Web Services can share
Programme’s behalf.                                         data from a server application to a desktop
                                                            application or mobile device via the
                                                            Internet
The decision to deploy the platform on the Microsoft
.NET Framework was driven by the following key              Server-to-Server: Web Services provide a
concerns.                                                   common interface between existing
                                                            applications within an environment of
                                                            independent servers
Firstly, there is a strategic technical requirement to
“future-proof” (so far as reasonably possible) the          Service-to-Service: Web Services can
technical development of the project. The Microsoft         work together in sequence to create more
.NET Framework is a set of software technologies that       complex data operations
provides the building blocks to connect applications
                                                            The eCare Framework: utilises Web
via Web Services (see sidebar). It is integrated into the   Services for Server-to-Server and Service-
products that make up the Microsoft platform, and is        to-Service
the foundation of the next generation of Microsoft

001-11334N-010
eCare Conceptual Solution Overview                                                Version: 1.1 Release
                                                                                              01/09/05
                                             Page 15
platform products, tools and technologies.

The Microsoft .NET Framework is specifically designed to provide the ability to quickly and
reliably build, host, deploy, and utilise secure and connected solutions using XML Web
services. Web Services address the concern of integration with other systems, such as
Agency Applications, since they conform to open, vendor-neutral standards for the exchange
of data. Providing all systems involved comply and adhere to SOAP/WSDL standards, this
allows services and functionality developed on the Web Platform with Microsoft .NET to be
reused by other systems, regardless of the platform on which they reside; and visa-versa.

The eCare Framework will employ Web Services for Server-to-Server and Service-to-Service
use. Such services will be developed using a first class .NET supported programming
language, namely C#.NET.




001-11334N-010
eCare Conceptual Solution Overview                                        Version: 1.1 Release
                                                                                      01/09/05
                                             Page 16
5.      Conceptual Model

The diagram below shows the conceptual model for the eCare solution. This conceptual
model identifies at a high level the major system components and their relationships.

                          eCare Partnership Geographical System Boundary


        HEALTH CARE              SOCIAL CARE               EDUCATION                  other

     Systems and             Systems and               Systems and              Other systems and
     information             information               information              information
     domain employed         domain employed           domain employed          domains
     by Health Care          by Social Care            by Education
     Agencies                Agencies                  Agencies




                                               eCare ADAPTOR

                                         Enable
                                         communication
                                         between agency
                                         systems and the
                                         eCare Framework.
                                         One adaptor per
                                         agency system is
                                         required.

          Matching

     Associates records                                    eCare Framework
     from different
     systems and stores
     the reference                             MAS                 Index            Security
     numbers in the
     index                            Multi Agency             Stores cross-     Provides
                                      Store data               referencing       system and
                                                               information       application
     eCare Applications                                                          security

     eCART
     others...
                                         Messaging                 Viewer

                                      Enables                  Allows MAS
                                      communication            data to be
          Directory
                                      between the              viewed by
                                      Framework and            trusted client
     Provides user
                                      the Adaptor              applications
     store for eCare
     Applications




The above model shows the relationship between the high-level components (dotted

001-11334N-010
eCare Conceptual Solution Overview                                                   Version: 1.1 Release
                                                                                                 01/09/05
                                                 Page 17
components are optional) documented in the following section.


5.1     Component Description

5.1.1 Agency Applications

Agency Applications is the term used to refer to applications within the varying agencies that
perform client/patient/person processing functions. Agency applications include such
systems and/or processes as iSOFT PIMS, SWISS, Carenap, etc. Such applications can be
considered the source of the data that will be ultimately shared between agencies and the
primary processors of that data.

5.1.2 eCare Adaptor

This term refers to a conceptual component that enables communications between agency
systems and the eCare Framework. It is possible to specify how the eCare Adaptor will
communicate with the eCare Framework as the Framework will provide standardised XML
message protocols and agreed sharing datasets. How the component will integrate with the
Agency Applications will depend on the individual applications involved.

This component is part of the eCare solution, yet sits between the eCare Framework and the
Agency Applications. This component will sit within a local agency’s network; there will be
one instance of this component per agency system depending on network connectivity
between agencies. Note that depending on specific integration requirements, the Adaptor
can be a logical software component built into an agency system or eCare Application, or a
separate physical machine.

5.1.3 eCare Framework

The eCare Framework is a collection of services and functions enabling secure
communication between the eCare Adaptor and the Multi Agency Store. It provides a number
of additional support functions – such as indexing, matching and viewing, which are
described below.

5.1.4 eCare Safe Haven

The eCare Safe Haven is a secure perimeter network that connects the Agency networks
with the network in which the eCare Framework’s hardware is located.

5.1.5 Multi Agency Store (MAS)

At a conceptual level, the Multi Agency Store is the repository used to store consented data
for the purpose of such information being shared between different agencies. At a logical
level it also encompasses the functions of the Indexing and Matching Services, which are
necessary services to fulfil this goal, and are described in following sections. The MAS itself
will hold three main types of data: core data (in the form of person/demographic information
and the necessary indexes); shared inter-agency datasets (such as SSA data); and locally

001-11334N-010
eCare Conceptual Solution Overview                                            Version: 1.1 Release
                                                                                          01/09/05
                                            Page 18
extended data (in the form of local extensions to the core or shared inter-agency datasets).

5.1.5.1 Data Ownership and Consent

It is not currently envisaged that the MAS “owns” the shared information. Rather the
originating agency of the data remains the ‘owner’ of the data, and is the ‘data controller’ in
the terms of the Data Protection Act. It is the responsibility of the originating agencies to
ensure that local arrangements are in place such that individual consent has been granted to
share an individual citizen’s data between government agencies in different geographical
locations. In general terms, inter-agency information sharing must be supported by the
agencies extant information sharing protocols and processes, whether electronic or manual,
or such protocols must be established to enable it.

It follows that the identification of inconsistencies (in terms of data consistency) and the
propagation of updates to such information is not a core function of the MAS, but rather of
the originating agency. So saying, we would anticipate that a nationally defined physical data
model for the MAS may well introduce constraints that could introduce such functions.

5.1.5.2 Usage

It is not envisaged that the MAS be utilised as the sole repository for data supporting any
specific business process e.g. Care Assessment. Such usage is conceptually identical to that
of the Agency Applications, which are expected to provide their own data storage. This is to
say that the MAS, and its supporting services, security and infrastructure is not intended as a
platform for local, independent application development.

5.1.6 eCare Index

Multiple patient identifiers will exist within the Agency Applications connecting to the eCare
Framework. In order that these identifiers are associated, the eCare Index will hold the cross
reference information between systems. The Index will be used by eCare Framework
services in order to retrieve data about specific citizens. Given that personally identifiable
data is encapsulated by a person’s CHI number, it is envisaged that the Index will maintain
its own, universally unique and anonymous person identifier for use by the eCare
Framework. This would also allow for the Index to be extended to operate on a national
basis. Any necessary operational process and support of this internal eCare identifier would
be provided for by local partnerships. The Index is a functional component of the MAS, and
will be updated and maintained by the eCare Matching component.

5.1.7 eCare Matching

eCare Matching is a function and component that matches multiple person identities from
multiple systems to one person record in the eCare Index. This conceptual architecture
places few constraints on the operation of this component – the process may be automatic,
manual or a combination of both, dependant on local consortia requirements. Likewise how
failed matches and duplicates are to be handled will be specified in a later document. System
data integrity and the potential outcomes of failed matches are critical risks – as a result the
overall architecture is expected to define a base solution that will address these issues.
Matching may interact with Agency Applications regarding failed associations or potential
duplications. The Matching component is expected to provide a user-interface, allowing

001-11334N-010
eCare Conceptual Solution Overview                                            Version: 1.1 Release
                                                                                          01/09/05
                                            Page 19
match failures, and the eCare Index, to be manually managed by eCare administration
professionals. Matching is expected to be a function performed outside of the eCare
Framework itself, on an agency network that has connectivity to a source of national
reference data.

5.1.8 eCare Messaging Service

The eCare Messaging Service is the component that allows communication between eCare
Framework components and the eCare Adaptor, thus enabling communication to and
between Agency Applications. Future eCare Applications may potentially use this service
also. The Messaging service will ensure the validation of the authenticity of messages
received and forward such messages to the appropriate processing component within the
eCare Framework. It will also ensure the successful delivery and processing of the
messages it transmits with appropriate fail over and recovery processing. In order to
communicate with the eCare Adaptor, it will utilise XML messaging and data schema, which
must be defined for that purpose. Conceptually, the Messaging Service provides Agency
Applications with an interface to the eCare Framework.

5.1.9 eCare Viewer

The eCare Viewer is the component that enables a user of the system to view the data
stored in the MAS, using a trusted client application. It may interact with Agency Applications.

5.1.10 Security

Security is a high priority due to the sensitive and personal nature of the information being
stored. It is therefore important that no unauthorised system can access the data. This
includes ensuring that an authorised user can see only the data that they are authorised to
see and not data concerning other people. Security functions, and a security model, will
ensure this and an eCare Safe Haven will also provide defences against virus and other
attacks.

5.1.11 Directory

The Directory stores data about authorised users of the eCare Applications. It is used for
authentication of users and to decide what data a given user may view. It may also store
additional data, for example contact details. This component of the eCare architecture is
expected to be fulfilled by a directory service on the network on which the eCare Applications
reside.

5.1.12 eCare Applications

If an agency has no application of its own to interact with the eCare Framework, then it will
need to use an eCare Application for this interaction. eCare applications are therefore
conceptually identical to Agency Applications and will reside within an agency network. As
currently envisaged, there is only one main eCare Application, eCART.



001-11334N-010
eCare Conceptual Solution Overview                                            Version: 1.1 Release
                                                                                          01/09/05
                                            Page 20
5.1.13 eCART

The eCart is an Activity Recording Tool that enables the user to record the Person
information stored on the eCare Framework. The information would be entered by multiple
agencies and might cover Single Shared Assessment, Learning Disability and Child Health
Care groups among others. Information about the Person might include their personal and
professional involvements, details about their home, all activity recorded including referral,
assessments and needs, care plans, services provided and key communications between
the Person and practitioners. eCart would have the added functionality of dynamically
creating “Assessment Templates” to allow information from locally defined assessment forms
to be recorded and reported on electronically. eCart would have the ability to create ad-hoc
reports to satisfy both national and local requirements.


5.2     Conceptual Extensibility Models
This section provides models showing how the conceptual solution described above could be
future extended to provide inter-MAS communications.




Separate geographical eCare installations (the white circles in the diagram above) are
logically connected together through a Messaging Hub. This central service acts as a bridge
between each local eCare Messaging Service. This Messaging Hub is aware of and has
connectivity to each eCare installation that is to be joined together. The precise operation is
still to be defined, but there are two broad options:

    1. If an individual eCare installation wishes to communicate with other installations it
       places a ‘broadcast’ message into its local Messaging Service. The Hub will regularly
       poll the individual Messaging Services for these messages. If it finds one, it relays the
       message to the other installations which will process the relay message and place a
       reply in their local Messaging Service.

001-11334N-010
eCare Conceptual Solution Overview                                            Version: 1.1 Release
                                                                                          01/09/05
                                            Page 21
    2. If an individual eCare installation wishes to communicate with other installations its
       Messaging Service contacts the Messaging Hub. The Hub will then relay the
       message to the other installations which will process the message and reply to the
       Hub via their local Messaging Service.

There are technical trade-offs involved with both options, but at the present time the first
option most readily complies with the current thinking in terms of the solution’s security
architecture. The diagram below shows this conceptual solution in a little more detail.




001-11334N-010
eCare Conceptual Solution Overview                                             Version: 1.1 Release
                                                                                           01/09/05
                                             Page 22
6.      Derived Logical Model

The diagram below shows the derived logical view of the eCare solution. This model
identifies the major services required to deliver the solution’s functionality and the
relationships between the services. It is important to note that this model has been derived
from the conceptual model given previously – i.e. it does not incorporate further analysis and
does not detail the solution’s overall logical services. It is intended purely to give an
indication of the potential logical services that may be required.




001-11334N-010
eCare Conceptual Solution Overview                                           Version: 1.1 Release
                                                                                         01/09/05
                                           Page 23
7.      Derived Physical Model

The diagram below shows the derived physical view of the eCare solution. This model
identifies how the specific technologies will be used to create the services identified in the
logical model. It is important to note that this model has been derived from the conceptual
and logical models given previously – i.e. it does not incorporate further analysis and does
not detail the solution’s overall physical characteristics.

                                                    Agency Network


                     Agency
                     System                             eCare                      Directory
                                                        Applications
                                                                                   User and Roles
                     System Business
                                                        eCart                      Authentication
                     Logic and Data
                                                        others...




                     Client                    HTTP/S
                                                        Adaptor
                     Agency System
                                                        Integration
                     Client
                                                        Messaging
                     Applications

                     Web Browser




                                     HTTP/S                               SOAP


                                                                              eCare Safe Haven



                                   Web                                Message
                                   Viewer                             Messaging
                                   Business Logic                     Business Logic
                                                             SOAP




                                         Web Zone                       Messaging Zone



                                                SQL                     SQL



                                                      Data
                                                      Databases
                                                      Indexes




                                                       Framework Zone




001-11334N-010
eCare Conceptual Solution Overview                                                                  Version: 1.1 Release
                                                                                                                01/09/05
                                                        Page 24
Appendix A - Derived Requirements

As part of the overall eCare Architecture Description, this content of this document produces
constraints and technical requirements. All derived requirements are assumed to be at ‘Not
Agreed’ status and have no priority. These are documented below.


  Reference       Description

                  All data held within the eCare Multi Agency Store (MAS) must have the appropriate
                  and prior consent for multi-agency sharing.
                  No data – personal, sensitive personal or otherwise – should be held within the
                  store that cannot be shared by all the agencies that use the MAS.
                  The eCare MAS must include a mechanism to remove data where consent has
                  been subsequently withdrawn.
                  Finer grained consent models may be developed and implemented by local agency
                  consortia as appropriate.
                  In terms of the Data Protection Act, the originating Agency will be considered to be
                  the data controller.
                  The eCare Programme will define national data models for the sharing of data.
                  These data models will ensure consistency and allow for eCare XML messaging
                  and integration standards to be nationally defined.
                  The eCare Framework will be hosted in many different geographical locations by a
                  local partner within a consortium of local government agencies. The programme
                  will place no constraints regarding where the solution is hosted or operated – such
                  decisions will be made at the local level and may leverage local facilitates and
                  resources as appropriate.
                  The eCare Framework will employ a Safe Haven as part of the security architecture
                  to secure the solution infrastructure and communications protocols.
                  Rules will be implemented to ensure that HTTP/HTTPS are the only ports and
                  protocols permitted between the Safe Haven and its connected networks, and that
                  such communications originate from outside of the Safe Haven, i.e. no traffic is
                  initiated from within it.
                  The Local Agencies’ existing LDAP compliant user directories are expected to fulfil
                  the role of the directory service required in order to support eCare Applications. If
                  an Agency network does not have an existing directory service, Microsoft Active
                  Directory will be required to support the eCare Applications.
                  The technical platform product family for the eCare Framework will be provided by
                  Microsoft, namely: Microsoft Windows 2003 Server; Microsoft SQL Server 2000;
                  Microsoft .NET Framework.
                  There is a strategic technical requirement to “future-proof” (so far as reasonably
                  possible) the technical development of the project.
                  All systems involved must comply with and adhere to SOAP/WSDL standards




001-11334N-010
eCare Conceptual Solution Overview                                                   Version: 1.1 Release
                                                                                                 01/09/05
                                               Page 25
  Reference       Description

                  The eCare Framework will provide standardised XML message protocols and
                  agreed sharing datasets
                  The eCare Adaptor will sit within a local agency’s network; there will be one
                  instance of it per agency system depending on network connectivity between
                  agencies
                  The identification of inconsistencies (in terms of data consistency) and the
                  propagation of updates to such information is not a core function of the MAS, but
                  rather of the originating agencies
                  The MAS, and its supporting services, security and infrastructure is not intended
                  as a platform for local, independent application development.
                  The eCare Index will hold the cross reference information between systems
                  The Index will be used by eCare Framework services in order to retrieve data
                  about specific citizens.
                  It is envisaged that the Index will maintain its own, universally unique and
                  anonymous person identifier for use by the eCare Framework.
                  The matching process may be automatic, manual or a combination of both,
                  dependant on local consortia requirements
                  The overall architecture is expected to define a base solution that will address the
                  issues of system data integrity and the potential outcomes of failed matches
                  Matching may interact with Agency Applications regarding failed associations or
                  potential duplications.
                  The Matching component is expected to provide a user-interface, allowing match
                  failures, and the eCare Index, to be manually managed by eCare administration
                  professionals.
                  Matching is expected to be a function performed outside of the eCare Framework
                  itself, on an agency network that has connectivity to a source of national reference
                  data
                  The Messaging service will ensure the validation of the authenticity of messages
                  received and forward such messages to the appropriate processing component
                  within the eCare Framework.
                  The Messaging service will also ensure the successful delivery and processing of
                  the messages it transmits with appropriate fail over and recovery processing.
                  In order to communicate with the eCare Adaptor, the Messaging service will utilise
                  XML messaging and data schema, which must be defined for that purpose.
                  Security is a high priority due to the sensitive and personal nature of the
                  information being stored. It is therefore important that no unauthorised system can
                  access the data.
                  Security includes ensuring that an authorised user can see only the data that they
                  are authorised to see and not data concerning other people. Security functions,
                  and a security model, will ensure this and an eCare Safe Haven will also provide
                  defences against virus and other attacks.




001-11334N-010
eCare Conceptual Solution Overview                                                   Version: 1.1 Release
                                                                                                 01/09/05
                                               Page 26
  Reference       Description

                  The Directory stores data about authorised users of the eCare Applications. It is
                  used for authentication of users and to decide what data a given user may view. It
                  may also store additional data, for example contact details.
                  If an agency has no application of its own to interact with the eCare Framework,
                  then it will need to use an eCare Application for this interaction. eCare applications
                  are therefore conceptually identical to Agency Applications and will reside within an
                  agency network.
                  The eCart is an Activity Recording Tool that enables the user to record the Person
                  information stored on the eCare Framework.
                  eCart would have the added functionality of dynamically creating “Assessment
                  Templates” to allow information from locally defined assessment forms to be
                  recorded and reported on electronically.
                  eCart would have the ability to create ad-hoc reports to satisfy both national and
                  local requirements.
                  The Messaging Hub acts as a bridge between each local eCare Messaging
                  Service.
                  The Messaging Hub is aware of and has connectivity to each eCare installation
                  that is to be joined together




001-11334N-010
eCare Conceptual Solution Overview                                                   Version: 1.1 Release
                                                                                                 01/09/05
                                               Page 27

				
DOCUMENT INFO