NHS: NPfIT in context - Oasis

translatoryazooInternet and Web Development

Nov 12, 2013 (3 years and 9 months ago)

58 views

1

The NHS, Standards, Security & Identity
Management

Dr. Mark Ferrar

Director of Infrastructure

NHS Connecting for Health


OASIS Adoption Forum


28 November 2006


2

Agenda

NHS


NPfIT in context


Standards (
used by NPfIT
)


How do we use them?


How important are they?


Benefits & drawbacks


Security (
of Information in NPfIT
)


Overview


Standards


Identity Management


Standards


Challenges


Summary

3

NHS: NPfIT in context

Setting the context for the
National Programme for IT

4

Strategic 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

5

Where’s your medical record kept?

6

Did someone take a back
-
up?

7


Largest civil IT
project in the world


40,000 GPs


80,000 other
doctors


350,000 nurses


300+ hospitals


10 year programme


50m+ patients


1.344m healthcare
workers

South

West

North East

East

London

choose
and
book

Electronic
Prescriptions
Service

NHSmail

National & Local Care Record Services

N3

Healthspace

Scope for NHS Connecting for Health

Picture Archiving &
Communications
Service

Secure E
-
mail for all NHS workers

Web Access for Patients

Secondary
Uses Service

Analysing National Health Trends

New National Network

Patient Choice

8

Architecture Overview

9

Messaging/Integration Backbone (TMS)
LSP Data Centre
Local Application
Instance
EPR
Local Application Integration
Local Application
Instance
EPR
Local Data
Warehouse
MI
Terminology/
Decision Support
Terms &
Drug dB
LSP User Domain
Primary User
Secondary User
Tertiary User
Community User
ICRS NASP Data Warehouse
SUS
SUS
SUS
CAB NASP Domain
CAB Data
Store
E
-
Booking
Application
Booking
Management
Service
Telephone
ebXML / HL7 V3

HL7 V3

ICRS NASP Domain

SSB

PDS

PSIS

SDS

ACF

Secondary Care

Application

EPS

(

Security

&

Access

)

Enhanced Retained Legacy Systems

Primary User

Secondary User

Security

Infrastructure

Primary Care

Application

EPR

Secondary Care

Application

EPR

Event Engine/

Integration Layer

Event Engine/

Integration Layer

Integration Overview

LSP Data Centre
Local Application
Instance
EPR
Local Application Integration
Local Application
Instance
EPR
Local Data
Warehouse
MI
Terminology/
Decision Support
Terms &
Drug dB
LSP User Domain
Primary User
Secondary User
Tertiary User
Community User
LSP Data Centre
Local Application
Instance
EPR
Local Application Integration
Local Application
Instance
EPR
Local Data
Warehouse
MI
Terminology/
Decision Support
Terms &
Drug dB
LSP User Domain
Primary User
Secondary User
Tertiary User
Community User
10

In a typical NHS week…


6 million people visit their GP


Over 800,000 outpatients are treated


Over 10,000 babies are delivered by the NHS


Over 50,000 emergency journeys in NHS ambulances


District nurses make over 600,000 home visits


Pharmacists dispense ~8.5 million items


NHS surgeons performing ~1,200 hip operations,
3,000 heart operations and 1,050 kidney operations


Labs and associated services provide millions of tests
results


In other words, 3 million
critical

transactions each day!


11

National Programmes deliver…


15,642 bookings a day through Choose & Book


1.7 million bookings made so far in total


7,605,966 prescriptions have been made electronically through ETP


354,488 prescription messages in the last week


16,053 (site) connections to the N3 network


98% of GPs connected


60 PACS installations from NHS CFH now live


90,261,214 images have been stored from over 4,583,163 patient studies


797,987 messages a day over NHSmail from 213,485 users (inc. NHS
CFH)


296,526 Smart Cards issued and in use


GP payments enabled by QMAS total over £1.7billion

12

And while we’re talking about scale…


600,000 PC and 850,000 computer users in the NHS (in England)



NHSmail will have over 1.5 million users


World’s largest private, fully
-
featured, secure, single
-
domain e
-
mail service



NHSmail Relay Service processes 4,000,000 messages/day and
activity bursts of 100 messages a second.



N3 network transacts almost 100 terabytes of data each month


That’s equivalent to the entire 32 volume set of the Encyclopaedia Britannica
every 40 seconds



The processing power of the “Spine” and its test environments
would put it in the top 100 supercomputers ever built


And it has over 300 terabytes of storage
-

equivalent to the contents of a book
shelf 3000km long

13

0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
00: 00 to 00: 59
01: 00 to 01: 59
02: 00 to 02: 59
03: 00 to 03: 59
04: 00 to 04: 59
05: 00 to 05: 59
06: 00 to 06: 59
07: 00 to 07: 59
08: 00 to 08: 59
09: 00 to 09: 59
10: 00 to 10: 59
11: 00 to 11: 59
12: 00 to 12: 59
13: 00 to 13: 59
14: 00 to 14: 59
15: 00 to 15: 59
16: 00 to 16: 59
17: 00 to 17: 59
18: 00 to 18: 59
19: 00 to 19: 59
20: 00 to 20: 59
21: 00 to 21: 59
22: 00 to 22: 59
23: 00 to 23: 59
Authentications
to the SPINE by Hour and
Day

For a typical week this results in…

14

Role & Importance of Standards

The role and importance of

Standards to the NPfIT

15

Standards and the National Programme

Standards adopted as a matter of…



Policy


e
-
GIF


NHS STEP


STandards Enforcement in Procurement


W3C/WAI


NHS Information Standards Board (“ISB”)



Preference


Contractual preference to support commercial flexibility



Need


Practical need in order to support inter
-
operability


16

ISB definition of an Information Standard

"NHS Information Standards are information and communication technologies
1
,
which achieve interoperability between independent computer systems [functional
interoperability] and between independent users of data particularly patients,
clinicians and managers [semantic interoperability] when using computer systems
as part of NHS commissioned and provided care."



Focus on safety, fitness for purpose, interoperability and implementation, ensuring
both a specification and implementation guidance exist, meaning implementation is
required

before a standard is adopted or approved.






1

"Health Technology is an internationally recognised term covering any method used by those working in health services to prom
ot
e
health, prevent and treat disease and improve rehabilitation and long
-
term care. "Technologies" in this context are not confined

to new
drugs or pieces of sophisticated equipment." (
http://www.hta.nhsweb.nhs.uk/FAQ/
).


17

Examples of ISB Information Standards

Some examples of NHS Information Standards include:



Data standards such as datasets for national audits, statistics or
commissioning


Message standards such as messages communicating patient allergy
information between a GP system and the national ‘spine’


Record content standards such as the ambulance service patient report form


Interface standards such as how date and time are displayed on the
computer screen


Health related classifications and terminologies such as ICD
-
10 and
SNOMED CT


Technical standards that facilitate communication and between systems and
ensure effective operating, for example,

network standards


Information governance standards: technical and behavioural standards that
support safe, secure and confidential management of information.

18

Types & Stages of Standard

Types


Process manages each of three types with appropriate degrees of rigour.



An Operational standard

is a detailed and precisely defined standard for operational use
within a specific area of the NHS. The bulk of the standards considered by ISB are
operational standards


A Fundamental standard

is one which encompasses many distinct areas and will have
multiple instantiations of
operational

standards


A Framework standard

is an 'overarching' structure which can be employed to develop
Operational and / or Fundamental standards


Stages


Three sequential stages, each ensuring that developer and sponsor provide evidence through
testing that standard is needed, fit for purpose, can be implemented and integrated.



At
Requirement

standard stage, ISB assures a defined need within the NHS and that
development and implementation plan is funded


At
Draft

standard stage, ISB assures early evidence of benefits delivery described in the
'Requirement' through testing


At
Full

standard stage, ISB assures evidence of ability to be implemented, interoperability
and safety and is supported by a maintenance and update process


19

External Interface Specification (EIS)

Within the National Programme, interoperability and integration is specified
in the EIS, which describes interfaces for the following national services:




Electronic Transfer of Prescriptions (ETP)


eBooking

Service (EBS)


GP to GP (GP2GP)
-

EHR transfer service


Gazetteer Service


Spine Directory Service (SDS)


Spine Security Broker (SSB)


Personal Demographics Service (PDS)


Legitimate Relationship Service (LRS)


Personal Spine Information Services (PSIS)



Also provides protocol and message format standard for the exchange of
HL7/XML messages between a service client and a national service.

20

EIS references various standards

Adopts standards from various consortia as defined in their respective formal definitions.


Implementers
should
1

always refer to the standards for detailed guidance.


Where conflicts exist between specification and standard, the standard takes precedence.


The following key standards have been adopted:



HL7 Version 3.


XML family of standards, W3C.


OASIS
ebXML

Message Services Specification.


OASIS
ebXML

Collaboration
-
Protocol Profile and Agreement Specification.


SOAP, W3C Recommendation.


HTTP, IETF RFC.


XML
-
Signature, W3C Recommendation.


LDAP, IETF RFC.


Assertions and Protocol for OASIS Security Assertions
Markup

Language (SAML v1.1).



(1) The keywords MUST, MAY, RECOMMENDED, and SHOULD are to be interpreted as described in RFC2119

21

EIS relates to NASP & LSP services

EIS describes external interfaces from a technical perspective.


Targeted at architects, designers and builders responsible for delivery of Local
Service Provider (LSP) systems, national service systems and the ICRS Spine.


Assumes familiarity with:



HL7


XML


ebXML


XML Security


SOAP


HTTP


LDAP


Single Sign
-
on (SSO)


SAML


UML

22

EIS References

Ref.

Version or Doc. No.

Description

[Ballot6]

Ballot6

HL7 Version 3 Messaging Standard, Ballot6, December 2003.

[BT
-
Mbeh]

5 Draft B

2086 Message Handling Service Behavioural Patterns, Document Number, Issue 5, 18
th

January 2006.

[BT
-
CP]

2.1 Draft A

2088 Release ebXML Contract Properties, Issue 2.1 Draft A, 24
th

August 2006.

[ebXML
-
BPSS]

1.01

OASIS ebXML Business Process Specification Schema, Version 1.01, 11 May 2001.

[ebXML
-
MS]

2.0

OASIS ebXML Message Services Specification, Version 2.0, 1 April 2002.

[ebXML
-
CPA]

2.0

OASIS ebXML Collaboration
-
Protocol Profile and Agreement Specification, Version 2.0, 23
rd

September, 2002

[EIS5.5]

5.5

External Interface Specification, CDT D 0002, Issue 5.5, 22
nd

February 2006.

[EIS6.4]

6.4

External Interface Specification, CDT D 0002, Issue 6.4, 28
th

October 2005.

[ESR]

0.2

Microsoft Excel Worksheet ESR Staff Group, Sub
-
group and Job Role Codes DRAFT 0.2

[ETP
-
SS]

1.0

ETP Supplementary Specification


ETP v2 Implementation Strategy, Issue 1.0, Document Number 2052

[HL7
-
ebXML]

1

Transport Specification

ebXML, Release 1, Draft Standard for Trial Use, Candidate #1, 24
th

November 2003.

[HL7
-
WS]

1.0

Web Services

SOAP/WSDL Profile 1.0, 30
th

November 2003.

[HL7
-
WSA]

0.96

Web Services Address Profile,
Ruggeri, Cabrera, Regio.

[HTTP]

1.1

RFC 2616 HTTP, Version 1.1

[LDAP
-
1823]

The LDAP Application Program Interface

[LDAP
-
2251]

RFC 2251
Lightweight Directory Access Protocol (v3)

[LDAP
-
2252]

RFC 2252
Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions

[LDAP
-
2253]

RFC 2253
Lightweight Directory Access Protocol (v3): UTF
-
8 String Representation of Distinguished Names

[LDAP
-
2254]

RFC 2254
The String Representation of LDAP Search Filters

[LDAP
-
2255]

RFC 2255
The LDAP URL Format

[NASP
-
XML]

5 Draft F

NASPXMLPackage, Version 5F 2006
-
08
-
24

[MIM4.1.04]

4.1.04

NPfIT Message Implementation Manual, Version 4.1.04, Issue date 16/08/2006

[MIM4.1.02]

4.1.02

NPfIT Message Implementation Manual, Version 4.1.02, Issue date 05/05/2006

[MIM3.1.11]

3.1.11

NPfIT Message Implementation Manual, Version 3.1.11, Issue date 04
-
08
-
2005

[MIM3.1.10]

3.1.10

NPfIT Message Implementation Manual, Version 3.1.10, Issue date 30
-
03
-
2005

[MIM3.1.09]

3.1.09

NPfIT Message Implementation Manual, Version 3.1.09, Issue date 14
-
01
-
2005

[MIM3.1.07]

3.1.07

NPfIT Message Implementation Manual, Version 3.1.07, Issue date 29
-
10
-
2004

[MIM2.3]

2.3

NPfIT Message Implementation Manual, Version 2.3

[RBAC]

6.0

Information Governance Programme Role
-
Base Access Control Requirements (RBAC) (NPFIT NDA GEN IG0252) v6.0. 17
th

Feb

[RFC
-
2119]

Key words for use in RFCs to Indicate Requirement Levels

[SOAP]

1.1

SOAP, Version 1.1, W3C Note, 8
th

May 2000

[SOAP
-
Att]

SOAP Messages with Attachments, 11
th

November 2000.

[SSB SAML]

IG D0014 Spine Security Broker


SAML Assertion Structure

[WS
-
A]

1.0

Web Services Addressing

Core, W3C Working Draft, 15
th

February 2005, Issue 1.0

Web Services Addressing

SOAP Binding, W3C Working Draft, 15
th

February 2005, Issue 1.0

[WSI]

1.0a

Basic Profile 1.0a

Final Specification, Web Service Interoperability Organisation, 8
th

August 2003

[WSI
-
ATT]

1.0

Attachments Profile 1.0, Web Service Interoperability Organisation, 24
th

August 2004.

[XLINK]

XML Linking Recommendation, W3C Recommendation, 27
th

June 2001.

[XMLdsig]

XML
-
Signature Syntax and Processing: W3C Recommendation 12 February 2000

[XMLSchema]

XML Schema Part 1: Structures, W3C Recommendation, 2
nd

May 2001

XML Schema Part 2:
Datatypes
, W3C Recommendation, 2
nd

May 2001

23

Other standards adopted by NPfIT

NPfIT also relies on various other international standards not described by (or
relevant to) the EIS, but just as important


Medical Terminology


SNOMED
-
CT


Various other infrastructure standards (not already mentioned)


TCP/IP v4


DNS


TLS / SSL


X.509


IEEE 802.3


IEEE 802.11


3DES


AES


RC4


IMAP


Etc…


In fact, standards of one sort or another pervade most elements of the programme.

24

Standards we’re developing ourselves

HL7 NHS Extensions


Being adopted into mainstream HL7


Common User Interface (CUI)


Design Guide for components of the clinical UI


Licensed for use outside the NHS


Collaborative development via Participation Agreement


Focus on Patient Safety & Clinical Efficiency


Independent of application development environment or language


Some taken through the NHS ISB processes



Toolkit


Implementation of DG in Microsoft .NET v2



(Desktop & Infrastructure)



(Office)

25

Benefits & Drawbacks of Standards

Benefits and drawbacks to
using standards

26

Benefits

Interoperability


End to end service delivered using different brands and products


Service delivered using different versions of same products in different parts of
the organisation


Service interoperates with other organisation’s services (that use same or
compatible standards or interfaces)


Longevity


Protection against innovation obsolescence when combined with SOA


Commercial firms “innovate” to improve product (fix bugs, enhance performance)
AND

generate steady revenues (make users upgrade)


A long term (10 year) programme must manage product innovation alongside
long term sustained service delivery and stability.


Flexibility


Add or delete a product from the service mix


Add or delete a service


Avoiding vendor lock
-
in


Avoid Service Provider lock
-
in


Extend organisation or enterprise (integrate 3
rd

party business services)

27

Thanks to Patrick Gannon for the following reference:


US
DoD

Open Technology Development, A Roadmap Plan, April 2006



As software becomes increasingly networked, design and engineering
methodologies have evolved towards
services
-
based architectures

that
communicate through
open and standardized interfaces
. Often, these services
and interfaces are provided with OSS reference implementations. Once this type of
open, service based architecture is implemented, the system naturally decomposes
into a modular design ―

each service is free to improve and evolve independently
as long as it communicates through the
standard interfaces
.”


http://www.acq.osd.mil/asc/


But this should apply equally to proprietary systems built to comply with open standard
interfaces


each service is free to improve and evolve independently so long as the
interface standard remains stable and is adhered to.

Benefits

28

Drawbacks

Implementation variation


Proprietary implementations of the “standard” may fail to interoperate


Heavily customised implementations of complex applications built on equally
complex standards become bespoke (almost proprietary) solutions


E.g. Java engine variations


E.g. smart card “standards”


Implementation quality


E.g. Bluetooth used in Assistive Technology /
Telecare

/ Telemedicine


Performance disadvantage against “tuned” proprietary solutions


E.g. IMAP clients versus proprietary e
-
mail client / server protocols


Obsolescence when the standard changes


E.g. SAML v1.1 versus SAML v2.0


Competing Standards


That’s the thing about standards, there are always so many to choose from


E.g.
ebXML

business process and modelling standards overlap with HL7 standards
specific to healthcare


which should the NHS choose to implement?

29

Security Architecture of NPfIT

Security Architecture of the
National Programme

30

Key security challenges


How do you ensure only those who need access gain
access to any one of 50 million patient records?



How do you provide single sign
-
on with >10 service
providers, >50 applications and 12,000 separate NOS
installations?



How do you provide e
-
GIF Level 3 2
-
factor
authentication with 30% of your users outside your
organisation and network?

31

From patient and clinician perspectives

Who’s been
accessing my
record?

How can I be sure that
people who do have a
need to access my
medical record only get
access to what they
need?

Can I be sure
people who have no
need to see my
medical record will
not be able to see
it?

I need secure
access to
clinical systems
and patient
information

I need a single
way of proving
my identity to all
systems that I
use

32

Our Data Protection Act obligations


DPA defines much of the data held on NCRS systems as

sensitive personal data




We have a duty of care to protect data appropriately



Government guidelines say the release of “
personally … sensitive
data to third parties
” requires Registration at Level 3, via which

the registrant’s real world identity is verified beyond reasonable
doubt




Guidelines also say Registration at Level 3 should be combined
with Authentication at the same level

33

NCRS security components overview

Security Architecture

Confidentiality Architecture

Role Based Access
Control

Patient Consent

Registration and
Authentication

Legitimate

Relationships

Sealed Envelopes

Clinician

Patient

34

Role Based Access Control

“Can I be sure that people who
do have a need to access my
medical records only get access
to what they need?”

35

Why Role Based Access Control?


Well understood approach with proven success in
large business systems



The NHS is a business with complex role
-
to
-
task and
task
-
to
-
business process mapping



Most existing health applications incorporate some
form of Role Based Access Control

36

Roles Based Access Control model

Healthcare
Professional

Organisation(s)

Job Role(s)

Activity/
Business
Function(s)

xxxx

xxxx

xxxx

xxxx

xxxx

Etc.

National Care
Records Service

(NCRS)

Choose and
Book

(CAB)

Electronic
Transmission of
Prescriptions

(ETP)

Secondary Uses
Service

(SUS)

Etc.

CFH
Applications

37

However, RBAC alone is not enough…


The functions people perform can cross job boundaries



Some functions are available only to certain users in a
particular job



Some functions are not related to a user’s “day job” at
all



Different NHS organisations have different ideas about
what someone in a particular role can do


38

Enhancements to RBAC are needed


Transparent to the choice of service provider supporting
the real world “things” people do.



Uses the role concept for the majority of rights a user
has, so that Registration Authorities are not faced with
the individual nomination of every separate detailed
access right.



Provides the flexibility needed to support policy change.



Permits policy variation across the NHS, controlled in a
manner that preserves a common understanding of Job
Roles and the rights they carry.

39

Legitimate Relationships

“Can I be sure that people who
have no need to see my medical
record will not be able to see it?”

40

What is a Legitimate Relationship?


The Legitimate Relationship Service (LRS) enables systems to
verify a permitted relationship exists between the system user and
the patient before allowing access to requested data



A user cannot access a patient's clinical record without a Legitimate
Relationship (LR)



Many different types of LR, but almost all are invisible to the user
and are triggered by patient
-
related events



Legitimate Relationships have lifecycles (they can expire)



Creating Workgroups and assigning users to them is a vital function
for NHS organisations and to the LRS

41

LR Workgroups


how they work

WG

Clinician (User) permitted
access to patient record
as valid LR exists via the
Workgroup to patient

Clinician (User) is member
of the Workgroup

Additionally, there can be direct LRs between individual User Role Profiles (clinicians) and
Patients


these are ‘Self
-
claimed’ and ‘Colleague
-
granted’ LRs


e.g. in A&E.

Patient has LR with the
Workgroup, e.g. all GPs in a
given Surgery


established
when a patient registers with
a GP

42

Sealed Envelopes

“Can I be sure that people who
see my record will not be able to
see particularly sensitive
medical details which I want to
keep secret only to myself and
any specialists treating me?”

43

What is a Sealed Envelope?


Patients will be able to select parts of their record to
which they wish access to be restricted



They can require that only nominated people can see
these parts



This can be overridden (with an alert) if the patient’s
life is in danger and the patient cannot be asked



Clinicians will also be able to seal off parts of the
record from the patient (e.g. where knowledge by the
patient may lead them to harm themselves or others).

44

Authentication

“How do I know who has access
to my medical records?”

45

NHS Smartcards


A secure “Chip and Pin” card to hold a user’s unique identity
(digital certificates)



Supports 2 factor authentication required by e
-
GIF Level 3:


Something you have (the Smartcard)


Something you know (the Passcode)



Passcode only stored on the card



Certificate is validated to ensure currency as the user
authenticates



Any magnetic strip on the card is
not

used for authentication or to
hold digital signatures



Future support for biometrics and proximity

46

3
-
step registration process

Present Documents

Register User

User Registered



Smart Card Assigned


Smart Card Created

Smart Card Issued

CMS

CMS

Spine
Directory
Service

SUD

Card
Management
System

1
-

Validation of application to register



Complete an application form (RA01)


Have identity vouched for by sponsor or present suitable documentary evidence of
identity


Obtain sponsorship for appropriate job profile

2
-

Registration into the Spine User
Directory (SUD), a sub
-
component of
the Spine Directory Service (SDS)



Search for user and ensure no
duplicates created


Create a basic user profile


Associate with organisation(s)


Assign correct role(s)

3
-

Smartcard issue from Card
Management System (CMS)



Import person from SUD


Take clear image of applicant
with Webcam


Print and issue the card


Test the card

Sponsor

CA Agent

User

47

The user login experience

Insert
SmartCard
into Card
Reader

Enter
Passcode

Authentication
Confirmed

Set Session
Role

Start
Relevant
User
Application

48

Logon “behind the scenes”

1.
User inserts smart card or attempts access to a protected resource.

2.
Identity Agent (IA) prompts User for (smart card and)
Passcode
.

3.
Spine Security Broker (SSB) Service validates credentials and, if successful, establishes a Session.

SSB creates Single Sign
-
On (SSO) Token that includes:

1.
Unique User ID (UID)

2.
Token ID

3.
Session attributes, e.g.
max_idle_time

Also creates Attribute Assertion including:


Name, UID, OCS Code, Default Role, Job Role(s), Organisation(s), Business
Function(s), Area of work(s), Workgroup(s)

4.
SSB also establishes a Token


ID passed to IA, stored in memory on User’s PC and points to SSO Token held in ID Server.

5.
User starts application.

6.
Application obtains Token ID from IA

7.
Application checks validity of token with ID Server.


Applications can also retrieve session information using the Token ID to get SSO Token
values.

8.
Application Access control Decision Function (ADF) gets/parses SAML Assertion for attributes


Application ADF processes User requests in its own context based on user information in SSO
Token and Assertion.

49

Logging & auditing


Access to records & actions performed are logged against an
individual’s identity (via their smart card ID), not against the
Workgroup (which enables the RBAC)



Claiming of a LR (or attempting access without a LR) generates
an alert



Alerts are dealt with by Caldicott Guardians


an existing role
within the NHS


the safeguards of patient confidentiality



Access logs are kept as long as the EMR

50

The Identity Management Challenge

The Identity Management
Challenge

51

NHS Directories

Spine
Directory
Services

280,000
smartcard users
today growing to
over 1,000,000 in
full deployment

NHSmail
Directory

>210,000 nhs.net
entries today and
over 1,000,000
synchronised
addresses
already

12,000 separate
NOS Directories

Other
Application
Servers

Web
Application
Servers

ESR

Electronic

Staff Record

(Database)


Each “realm” contains a separate electronic identity.

Each identity must be validated and managed.


52

Multiple Directory Technologies…


Spine Directory uses Sun One


NHSmail uses CA eTrust


65% of 12,000 NOS use Microsoft AD (or NT4!)


35% of 12,000 NOS use Novell eDirectory (or NDS!)


ESR is Oracle database for most (but not all) NHS
workers



There are unknown number of application services
holding their own username & password lists


Plus ID badges and building access “swipecards”



All with different administration and standards




No realm’s membership is wholly congruent with another.


3rd parties add significantly to the total (e.g. pharmacists).


NHS is one brand across 1000’s of discrete organisations.



53

Multiple Identities
-

example


Mark Ferrar is registered in:


SPINE as 027649566234 via SmartCard


NHSMail as Mark.Ferrar@nhs.net


NOS at location A as mafe@npfit.nhs.uk


NOS at location B as
\
\
nhsia
\
markf


Local Business Application as MarFer


Etc..



On average an typical NHS user has between 5


8
electronic identities stored on different systems


(Only email & NOS A are real in this example


but this is typical!)


54

Our identity integration challenge…


Reduce user and administrator effort by integrating
multiple identities belonging to the same person


Synchronise some identity information


Federate some directory services


Deliver “self
-
administration” portals for users


Establish provision/de
-
provision links and processes


Validate identity at the highest level (e
-
GIF Level 3)


Ensure people can access the things they need to do
their jobs, but only the records to which they’ve been
granted access


Manage 5
-

8 Million User IDs


Need to prove some IDs “beyond reasonable doubt”


Challenge to and of Federation


Challenge of Data (Attribute) Synchronisation


Challenge of (Self) Administration


55

Summary


Open standards an integral part of the National
Programme for IT in the NHS


In fact, NPfIT not possible without open, accessible,
interoperable and “implementable” standards


But products that implement same standards must also
be compatible and efficient


Inefficient, incomplete or incompatible implementation are
less than useful


in fact its expensive & dangerous


FINAL THOUGHT: What responsibility does the
standards community take to ensure effective & efficient
implementation?