Prepared for the eGovernment Unit
DG Information Society and Media
European Commission
Good Practice Case
The Road Traffic Accident
Automation Project in UK
Case Study
31 March 2006
Case study prepared by Ralf Cimander and
Herbert Kubicek (ifib, Germany), in cooperation with Paul Fazakerley,
Department for Work and Pensions (DWP)
and Robin Down, EDS; both from UK.
eGovernment Unit
DG Information Society and Media
European Commission
Table of contents
1.
1.1
1.2
1.2.1
1.2.2
1.2.3
1.3
1.3.1
1.4
1.5
1.5.1
1.5.2
1.5.3
1.6
1.7
1.8
The Road Traffic Accident Automation Project in UK
Case Summary
Problem addressed
Specific Problem
General Background
Policy context and strategy
Solution
Specific Objectives
Implementation
- Workflow description
Features making it a candidate for good practice exchange
Impact
Relevance of the case for other administrations that could learn
from the experience
Transferability
Results
Learning points and conclusions
References and links
Annex 1: Assessment Questionnaire for the MODINIS Case Descriptions
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
2
2
3
3
5
6
7
7
8
9
13
13
14
15
16
17
20
21
1
1.
The Road Traffic Accident Automation Project in UK
1.1
Case Summary
The Compensation Recovery Unit (CRU), part of the Department for Work and Pensions (DWP) in
Great Britain, recovers from Insurance Compensators, on behalf of Dept of Health hospital costs
for the treatment of injuries arising from road traffic accidents (RTA) under the Road Traffic
Accident (NHS Charges) Act 1999. This was originally a high volume clerical processing operation,
dealing annually with 350,000 forms (equating to 700,000 transactions) issued between DWP CRU
and National Health Service (NHS) Hospitals. CRU, working with DoH partners and IT-service
providers EDS, BT Syntegra, and Atos Origin initiated a project to automate the electronic transfer
of data between the two government organisations including the enclosed Hospitals and the
Insurance Companies.
Through a pioneering example of cross government working, utilising an innovative solution, the
full process has been automated over the Government Secure Intranet (GSI). The data previously
issued in paper format from the CRU system is transferred to NHS Hospitals as an eXtensible
Mark-up Language (XML) schema and displayed on their web server. The required enquiry data is
input by the Hospital administration staff via a web browser and the response is transferred back
to CRU for automatic update of its system at a much-improved turn around time.
On receipt of the returned RTA forms, the CRU system automatically uploads the treatment
information into the specific case held and issue an invoice automatically to the Insurance
Company. This replaced the clerical process, which involved hundreds of CRU staff manually
entering the data onto the CRU system.
th
Initiation of the project was in 2002 and first NHS Trusts went live on a pilot basis on April 29 of
the same year. First pilots running in Scotland was in 2003. All NHS Hospitals were integrated in
the system by 2004.
The project has been a resounding success within both operational environments. DWP and
Department of Health secured joint annual efficiencies for Government of £1 million in return for
initial DWP development costs of £320K.
The project has been a genuine partnership; between not only government departments, but also
IT-service providers EDS, BT Syntegra, and Atos Origin working together to successfully deliver
modernised business processes.
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
2
1.2
Problem addressed
1.2.1
Specific Problem
A high volume clerical process between the Dept of Health (DoH)
and the Compensation Recovery Unit (CRU) needed to be automated
to reduce manual handling of data, improve data integrity and
ultimately reduce the DWP CRU cost of administrating the Road
Traffic Act (RTA) scheme on behalf of the National Health Service of
the DoH.
The challenge was to develop an automated system for the collection
and dissemination of information relating to RTA claims with the
NHS. The intention was to remove the manual issue, completion and
return of clerical transactions between DWP CRU and the national
network of NHS Hospitals. The automatic transfer of this data into
the CRU system removed the need to manually input the data
provided from the NHS Hospitals onto the CRU system. Whilst
improving the integrity of the data being returned from the NHS staff
via the provision of online validation.
Specific problems
addressed:
• Replacement of a high
volume clerical
process between two
different departments
by an electronic one
• Improvement of data
integrity by online
validation
There were further benefits due to the savings on physical storage
space and retrieval costs required for Document Retention of
completed forms within DWP CRU, as well as contributing to
environmentally friendly policies by not creating the forms for issue.
The automated system also significantly improved turn around time
of the clerical RTA2 forms (responses were provided within 2 days
compared to 2 weeks under the clerical process), whilst making a
significant contribution to Government’s targets on e-enabling
business transactions and cross government working.
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
3
Thus, the specific requirement concerning interoperability (IOP) was
to achieve IOP between the local hospitals and the Compensation
Recovery Unit via the Department of Health and also to the
insurance companies. I.e. if we think of a workflow existent between
them IOP between different stages of the supply chain had to be
achieved.
IOP requirement:
IOP between different
stages of a supply chain
producing one or more
services
CRU: Compensation Recovery Unit of the DWP
DoH: Department of Health
NHS Hospital: Local Hospitals in the Network of the
Nathional Health Service
Fig. 1 Interoperability Requirement of the RTA Automation Project
To meet this interoperability requirement, a communication model
using standardised workflows between pubic authorities on different
government levels, namely between the requesting CRU and the
responding local hospitals, now represented by one central
organisation – the DoH, has been employed. This communication
model is characterised by sequential interdependencies, i.e. the
receiveing institution (hospital) is dependent on the output of the
requesting institution (CRU) and in turn, the CRU is dependent on
the output of the hospital.
Basic organisational
model employed (1):
Bi- lateral
communication via
involved authorities
using standardised
workflows
In addition, since the previous clerical process of sending the RTA2
forms to the dispersed hospitals has been centralised by provision of
a web-service at the DoH that can be accessed from these hospitals
for filing the RTA2 forms, this web-service functions as a kind of
clearinghouse. I.e. it organises the incoming RTA2 forms, e.g.
concerning regional aspects, and informs the respective hospital that
a form is waiting. The respective hospital in turn only has to access
Basic organisational
model employed (2):
Central clearinghouse
for organisation of forms
for the dispersed
hospitals
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
4
this document via a standard web-browser and fill in the required
information. After sending back the form to the CRU, the respective
case will automatically be updated and invoices to the respective
insurance companies (automatically) issued.
To ensure almost automatic service operation, coordinated workflow
harmonisation among the involved agencies had to take place.
Though the injured person is the subject of the service, its provision
is dealt only by the public authorities and the insurance companies.
The presented service is about the exchange of information / forms
directly among the back-offices; i.e. no front-office action is required
and hence the service provision model is "back-office to back-office".
1.2.2
Service provision
model:
IOP among back-offices
General Background
CRU, a central government organisation, is tasked with recovering
amounts of Social Security benefits paid as the result of an accident,
injury or disease, where a compensation payment has been made
(under the 1997 Social Security (Recovery of Benefits) Act).
The scheme applies where recoverable benefits have been paid, or
are likely to be paid to an injured party, and where a compensator
(usually an insurance company or an agent such as solicitor acting
on their behalf) who is, or who is alleged to be, liable, makes a
compensation payment. Each year over £160 million worth of benefit
payments are recovered by the CRU through the scheme.
In addition, CRU also recovers from the Compensator, NHS Hospital
charges arising from road traffic accidents (RTA), where a
compensation payment has been made. These charges are
recovered on behalf of the Department of Health (DoH), under the
Road Traffic Accident (NHS Charges) Act 1999. The annual recovery
amounts to some £117 million, which is regenerated directly back
into the NHS for the provision of health services.
The NHS is funded by the taxpayer and managed by the Department
of Health, which sets overall policy on health issues. The NHS was
set up to provide healthcare for all citizens, based on need, not the
ability to pay and covers some 370 NHS Hospitals.
Service:
Compensation process
of hospital costs from
insurance companies
arising from treatments
resulting from road
accidents
Types and level of
agencies involved:
• About 370 local
hospitals in the
network of NHS
Hospitals
• Compensation
Recovery Unit (CRU)
of the Dept of Work
and Pensions (DWP)
• Department of Health,
responsible for the
National Health
Service
Due to the lack of suitable technology the process originally
introduced in 1999 was very high volume clerical based process. It
involved the exchange of information regarding hospital treatment
via a paper form, between CRU and the various NHS Hospitals
throughout the UK. CRU uses the information provided to calculate
the charges and issue invoices to the Insurance companies, who
have admitted liability for the road traffic accident.
The clerical process involved the exchange of over 350,000 forms
(700,000 transactions) per annum between CRU and the network of
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
5
NHS Hospitals. Often the clerical forms would go astray, would be
returned partially completed resulting in unnecessary rework for CRU
and Department of Health, or indeed be mistyped by CRU staff when
entering the data onto the CRU computer system, resulting in
incorrect invoices being issued and revenue inevitably being lost for
Department of Health.
1.2.3
Policy context and strategy
The project was initiated in line with the "Modernising Government"
White paper 2000 the Prime Minister's Government directive for all
of its services to be e-enabled by 2005. DWP is predominantly a
public citizen-facing Department across Great Britain, however, CRU
is quite different in that it presents a Government to Business
(Compensators) and Government to Government (Department of
Health) based business process. CRU took this steer a step further
by modifying it to recognise the potential in their own business
processes, even though they weren’t necessarily public facing. CRU
had previous experience of developing electronic links with the
Insurance Industry and a similar approach and technology was
adopted to modernise and improve the exchange of data between
the two government Departments involved. Both Departments were
working to the same political steer; therefore, they joined forces to
achieve this common goal. Successful delivery of the project would
generate significant savings for Department of Health, which could
essentially be used to provide a higher standard of health care
throughout the NHS.
Framework
conditions:
• Though the
collaborating
authorities adhere to
different departments
they are working to
the same political
steer
It was essential that these two diverse Government Departments
were able to "speak the same language" in technical terms to allow
the successful design, development and integration of this
automated electronic link between the dispersed hospitals and the
CRU. To this end the technical interface was designed using predetermined e-Government Interoperability Framework (e-GIF)
standards.
Legal framework:
• White paper 2000
"Modernising
Government"
• British Government
directive in order to eenable public services
by 2005
Whilst acknowledging that e-GIF is the standard for British
Government Departments, the project was also delivered in
accordance with the European IDABC programme (Interoperable
Delivery of e-Government services to Public Administrations,
Business & Citizens). We would envisage that this would allow for
transferability to other European states.
Interoperability
Framework:
• England set up its own
interoperability
framework – e-GIF
• Adherence to the EIF
of IDABC
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
6
1.3
Solution
1.3.1
Specific Objectives
The objectives of the project were:
−
Significantly
reduce
the
costs
associated
with
the
administration of the RTA recovery process between DWP and
DoH
−
Develop an automated electronic system for the collection,
translation and transfer of data relating to RTA claims with the
NHS.
−
Develop a browser based system on the NHS Web for RTA
Trusts to validate and process RTA claim forms.
−
Develop a system within DWP to automatically validate and
process incoming DoH data, through the issue of the invoice to
the insurer
−
Protect investment in existing application interfaces through
provision of middleware transformation services.
−
Enable interoperability between Government Departments
through design and implementation of XML schemas
conforming with appropriate frameworks.
−
Ensure continuation of support for legacy syntaxes through
exploitation of a common middleware transformation service
for both traditional-EDI and XML.
−
Remove the manual issue, completion and return of 700,000
clerical transactions between DWP CRU and the national
network of local NHS Hospitals.
−
Remove the requirement to manually input the data provided
from the 370 NHS Hospitals onto the CRU computer system.
−
Improve the integrity of the data being returned from the NHS
staff via the provision of extensive online validation.
−
Automate secondary enquiry letters by the CRU system from
coded responses returned by the NHS users.
−
Remove physical storage space and retrieval costs required for
Document Retention of 350,000 completed forms within DWP
CRU, as well as contributing to environmentally friendly
policies by not creating the 350,000 forms for issue.
−
Removal of postage and stationery costs associated with the
700,000 clerical transactions (i.e. 350,000 forms being issued
and posted back).
−
Improve turn around time of the clerical RTA2 forms.
−
Contribution to Government’s targets on e-enabling business
transactions.
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
Specific objectives:
• Significant reduction
of costs between DWP
and DoH
• Development of an
automated system for
exchange of RTA2
forms between CRU
and NHS Hospitals
• Development of a
browser based system
for validation and
processing of RTA
forms
• Development of a
DWP internal system
for validation of
incoming DoH data
• Protection of
investments through
provision of
middleware
transformation
services
• Enable IOP among
departments
• Continuation of
support for legacy
syntaxes
• Faster processing of
service
• Improvement of data
integrity
• Removal of physical
storage space
• Removal of postage
and stationary costs
General objective:
• Contribution to
Government targets
on e-enabling business
transactions
7
1.4
Implementation
CRU initiated a meeting with Department of Health officials in 2002
to explore the feasibility of automating a high volume clerical
process of issuing, retrieving and recording data from the 350,000
clerical RTA2 forms being issued and returned under the clerical
process. Following earlier indications that an automated Internet
based solution was feasible, a project steering committee was set up
to design, develop and implement the solution. In general, an
EDIFACT/X.400 project had to be migrated to XML. There were three
separate integrated systems to provide the overall solution. The
existing CRU system was to be developed further by the Service
Providers Atos Origin to accommodate this new activity whilst the
Department of Health were to build a new application (RTA2 system)
especially for the exchange of data with CRU. The EDS e-business
gateway team provides the facility to transfer and translate the data
between CRU and Department of Health. A data dictionary has been
established from the outset and core components derived from the
UK GovTalk repository. A schema has been centrally registered for
UK wide comment. XSLT has been used for adjustment of minor
semantic inconsistencies. For the e-Business Infrastructure see
Figure 2:
Figure 2: The e-Business Infrastructure
Both Departments managed the project under PRINCE 2
methodology. This resulted in the creation of a mutually
representative Project Steering committee, Project Board, the
construction of the appropriate Risk & Issues Logs, monthly project
manager updates provided by both CRU and Department of Health,
to ensure activities were aligned throughout.
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
8
Workflow description
It was agreed that the paper forms that were previously being
issued clerically to the Hospitals would be captured as an electronic
message by the CRU system. An amalgam of all of the day's
enquiries was to be transported as an in-house (flat) file in overnight
batch to the EDS e-Business Gateway. The Gateway would transform
the RTA2 data into XML format and transfer the data overnight to
the appropriate NHS Web Service across the Government Secure
Intranet (GSI), using Simple Message Transfer Protocol (SMTP).
Web pages would be populated with RTA2 forms on the NHS Web
Service as they are received from DWP. These were to be grouped
by their region to allow the NHS Users to find and complete their
own forms quickly and easily. When completed, the status of these
forms would be amended accordingly and the data automatically
returned as XML via an SMTP based batch interface to the EDS DWP
e-Business Gateway.
The e-Business Gateway would transform the records from XML to
the CRU application in-house file format and relay to the CRU end
system using transfer mechanisms consistent with other XML
designed activities in place between CRU and e-business gateway.
Supporting
infrastructure
employed:
• Central Web-service
which coordinates the
RTA2 forms with the
dispersed hospitals
(clearing: mainly
organisation and
routing of forms)
• Specification for
standardised bi-lateral
form exchange
between two different
authorities adhering
different policy areas
• The Government
Secure Intranet – GSI,
allowing secure
network IOP
• e-Business Gateway
connecting these
authorities and
transforming the
exchanged data
Fig. 3: Technical transfer process between CRU and the Department
of Health. Source: DWP/DoH Project
On receipt of the data, the CRU system would automatically upload
the treatment information into the specific case held and issue an
invoice automatically to the Insurance Company. This replaced the
previous process, which involved hundreds of CRU staff manually
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
9
entering the data onto the CRU system. The transfer of data in this
way has been so successful; that over 90% of cases are updated
with the relevant charges with no human intervention whatsoever.
The RTA system delivered additional features to allow CRU to
provide details of payments made by the Insurance companies on
these cases, providing valuable financial accounts to the finance
departments of the NHS Hospitals. It also provided a useful MI tool
to the Department of Health centre, which was responsible for
overseeing the provision of data by the NHS Hospitals within the
specified time-scales.
The CRU system was enhanced further to generate secondary follow
up enquiries on cases where treatment details could not be provided
by the NHS Hospitals, using a code system to generate each type of
enquiry.
Once the CRU and Department of Health systems had been
developed and rigorously tested, the electronic link was made
available to seven pilot NHS Hospitals around the country to allow
the identification and resolution of "teething problems" before being
rolled out nationally to the remaining hospitals. The only technical
requirement on the hospitals themselves was to have an Internet
connection.
Once this was confirmed they simply needed a user name and
password to be allocated by Department of Health Admin team,
before they were able to receive their enquiries electronically from
CRU.
Case capitalises
mainly on following
layers of IOP:
• Technical IOP (internet
protocol (e.g. HTTPS),
email (e.g. SMTP (+
SMIME), file transfer
(FTP (+ SSL))
• Syntactic IOP
(Transfer of RTA2
forms based on XML,
Invoices and other
information exchange
based on EDIFACT)
• Semantic IOP
(Translation of the
RTA2 forms for
transfer based on XML
and integration of
converted data into
the respective legacy
application (EDI
syntaxes)
• Organisational IOP
(introduction of the eBusiness Gateway, the
Web-service
functioning as clearing
house in the DoH,
change of business
processes)
The incremental rollout continued across the NHS until finally in April
2004, all NHS Hospitals were providing the data to CRU via the
electronic link that was available, and the issue of clerical enquiries
ceased completely.
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
10
Warrantee of security and privacy
The UK transposed the EC Data Protection Directive 95/46EC into
national law in the form of the Data Protection Act 1998 (replacing
the Data Protection Act 1984). This Act enshrines the principle that
personal data shall not be transferred to a country outside the
European Economic Area unless that country ensures an adequate
level of protection for the rights and freedoms of data subjects in
relation to the processing of personal data. The Department must
therefore be satisfied that the country it is proposed to transfer data
too can provide such assurances before an electronic transfer of data
could be agreed.
Within the UK, Government Departments interconnect using a
common UK Government network - GSI – Government Secure
Intranet, which is subject to full BS7799/ISO17799 accreditation. All
UK Government Departments connecting to this network must also
complete the same process prior to connection. GSI provides the
network platform which enables interoperability between DWP and
the Department of Health/NHS – the network is accredited to
transport RESTRICTED (EU-Restrainte) content in the clear. All
communication with external organisations is via GSI/Internet and is
subject to confidentiality and authentication services (128bit 3DES).
GSI interconnects with the IDABC TESTA II network which is subject
to the same accreditation process – this enables potential
interoperability with other EU Administrations utilising the same
infrastructure. This is currently under consideration for electronic
exchange of claims for reimbursement of the cost of medical
treatment received by a resident of one EEA state while visiting
another such state.
Awareness and Marketing
The rollout across the NHS required a huge communication and
implementation strategy across the UK. Some NHS liaison officers
had never used the Internet in the course of their duties; therefore,
there some cultural barriers to be overcome to ensure that the
project was deemed a success. The Department of Health and CRU
organised regional road shows and invited NHS representatives to
attend, so that they could hear and see the benefits of the electronic
link in comparison to the paper process. The relevant Internet
access, User guides and training material were provided to all NHS
Users before they actually went live.
GP Case: RTA Automation Project - UK
03-2006, vs. 1.0
Warrantee of Security
and Privacy:
• Data Protection
warranted by
adherence to the EC
Data Protection
Directive which has
been put in national
law
• Government
interconnection via the
Government Secure
Intranet GSI
• Authorities need
accreditation before
connection
Awareness and
Marketing:
• Huge communication
and implementation
strategy employed
• Regional road shows
with personal
invitations for
awareness and
• Provision of user
guides and training
material
11
Fig 3: Workflow of RTA Automation Project
one stage
INSURANCE COMPANY
Sends claim
concerning the
medical treatment
of a customer
involved in a Road
Traffic Accident to
CRU
DWP / COMPENSATION
RECOVERY UNIT
Fills in RTA form
and forward it for
complementation to
NHS Organisation
multi stage
DoH / NHS
Organisation
Receives form and
informs respective
NHS Hospital that
form is waiting
Validation of form
and forwarding
back to CRU
Receives invoice
HOSPITALS
Logs onto NHS Web
server and fills-in
RTA form
Receives form and
issues invoice to
Insurance
Company
: electronic flow
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
12
1.5
Features making it a candidate for good practice exchange
1.5.1
Impact
The project was a resounding success in that it completely
terminated the need to have a clerical process in place between CRU
and the 370 NHS Hospitals for obtaining details regarding hospital
treatment.
The turn around time in obtaining the data from the NHS has
reduced significantly, indeed some invoices are now issued by CRU
within 3 days of the initial claim being notified to CRU, whereas the
clerical process averaged almost 2 weeks for invoices being issued.
The risk of human error whilst entering the data onto the CRU
system has been removed, as the data provided by the NHS Hospital
is automatically uploaded into the CRU system, with no human
intervention. This has had significant positive impact in reducing the
amount of revenue lost due to typing errors etc.
The quality of the data provided by the NHS Hospitals has improved
significantly due to the extensive validation provided to ensure that
the online form is fully completed before it is returned to CRU,
resulting in the correct information being provided to CRU at the first
attempt.
Outreach:
• All 370 local NHS
Hospitals are dealing
the service online (i.e.
100% take-up of
service by full-national
roll-out
Performance:
• 350,000 paper forms,
i.e. 700,000
transactions ceased
• 22,000 clerical
reminders ceased
• Turn around time of
forms from almost 2
weeks decreased to 3
days
The manual administration of forms was removed, e.g. post
despatch, postal receipts within both Department of Health and CRU,
abolishing the extensive paper chase that previously existed. There
were also significant efficiencies secured with the related postage
and stationery costs.
The 22,000 clerical reminders that were issued under the old process
were no longer necessary, as the enquiry was displayed online until
the NHS provided the information required regarding hospital
attendance.
The project has been a resounding success within both operational
environments. DWP and Department of Health secured joint annual
efficiencies for Government of £1 million in return for initial DWP
development costs of £320K.
The working relationship between Department of Health and CRU
was enhanced by working closely together to achieve a common
goal, leading to improved communication, co-operation and
understanding of each other’s business and specific roles. The moral
satisfaction of generating efficiencies that directly improve NHS
services for all cannot be overstated. The service providers' good
working relationship was clearly visible and it was rewarding to see
two commercial bodies co-operate to successfully deliver a project
that they could quite easily have been competing against each other
under different circumstances.
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
Benefits:
• Improved cooperation
between the
authorities
• Savings of £1 million
in return for initial
DWP development
costs of £320K
• Removal of manual
administration of
forms
• Automated invoice
issuance
• Reduced postage and
stationary costs
• Quicker service
provision
• Better quality of
information, validated
data and less errors
13
1.5.2
Relevance of the case for other administrations that could learn from the experience
The success of this project was due to the joint efforts of two "likeminded" Government Departments, who both had a clear steer to
embrace electronic initiatives, as a means of modernising strategic
government services. Each Department was committed to deliver the
government steer regarding the introduction of electronic processes
from the onset. There was "buy in" at all levels, from the
Department Heads, who funded this innovative project, the project
teams who were charged to deliver the solution, down to the NHS
staff who gave a commitment to utilise the system and fully
embraced the changes being presented to them.
There were improved cross government relations, a partnership that
ultimately delivered significant efficiencies for Department of Health.
This was particularly evident in seeing two Departments and two
service providers work in partnership to develop an electronic link
that would provide mutual benefits for all. The Service Providers
utilised previously gained expertise in providing a technical solution
that was acceptable to all, embracing a partnership and co-operative
culture to deliver the clear objectives that were set from the onset.
Innovativeness:
• Joint efforts of two
different but likeminded authorities
adhering to different
government
departments
• Improved crossgovernment relations
also incl. service
providers
• Enabling co-existence
and parallel support of
legacy applications
with equivalent
Internet technology on
the same platform
• Business oriented and
real world approach by
employment of the eBusiness Gateway
All Government departments, who are required to exchange high
volume data to each other in a standardised format, e.g. Local
Authorities, Inland Revenue, or indeed European Government
Departments, should adopt this innovative approach. Each should
take the opportunity to look at their own internal processes and
embrace e-initiatives where the potential exists.
At the heart of this successful implementation is the EDS DWP eBusiness Gateway. This Gateway is based on COTS software but
internally enhanced to enable co-existence and parallel support for
legacy EDI applications with equivalent Internet technologies on the
same platform. The Gateway was procured in 2000 but has been
extended in-house, significantly adding XML transformation, AS1
based SMTP+S/MIME support and VAN connectivity within the last 3
years. The architecture combines Internet based secure messaging
and secure file transfer with legacy Value Added Network
interconnects to achieve support for in excess of fifty different
transport protocols. The combination of any to any content
conversion, global reach and autonomous control of transport
services by a small team of technicians results in a highly cost
effective implementation which removes technology barriers for DWP
business partners and thereby encourages participation. The eBusiness Gateway is thus designed to meet the primary need for any
e-Business initiative – the enthusiastic adoption by external business
partners over whom DWP business units have no direct management
control. It is this business oriented and real world approach that
distinguishes this implementation from similar but less successful
infrastructure initiatives.
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
14
1.5.3
Transferability
The input to the project was predominantly from Business users;
however, suppliers provided the technical expertise in relation to
Government interoperability. To ensure future transferability of the
development CRU adopted a technical strategy, which defines a
policy of component re-use and the removal of technology barriers
as a means to encourage participation.
There is continued support for legacy structured syntaxes such as
EDIFACT in parallel with e-GIF and e-Europe Interoperability
Frameworks based technologies such as XML and XSLT. Indeed, the
reuse element is best demonstrated by the fact that the e-Business
Gateway upon which these initiatives depends, provides parallel and
equivalent support to the UK element of the EU Migrant Worker
applications (Regulations 1408/71 and 574/72 - as presented at the
IDABC Inaugural Conference in Brussels on 17th/18th February
2005).
There has been a tangible example of re use of the original projects
methodologies within the UK. Previously there had been little or no
direct transfer of electronic data between DWP & DoH but following
the success of the RTA Project other cross department paper data
exchanges (forms) have been analysed and automations initiated. A
high volume process between DWP Disability & Carers Agency and
the national network of General practioners (doctors) to determine
medical check details is being automated. The "General Practioners
Factual Report" (GPFR) project will re use the infrastructure and
translation functionality established by the RTA project.
The e-Business Gateway comprises the TradeXpress product and
some additional messaging components to achieve secure file
transfer and secure messaging. The e-Business Gateway is a generic
transformation (XML and EDIFACT) and transport engine.
The primary transport channel is secure messaging via GSI/Internet,
- a production environment in daily use which consistent with the
aims of eEurope and IDABC, interconnecting Administrations,
Business and Citizens. This combined with a connection to the
European TESTA II network provides a low cost secure e-Business
channel for DWP with national and pan-European reach.
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
Transferability:
• Technical strategy for
component re-use and
the removal of
technology barriers
• Value proved eBusiness Gateway in
another application
• Continued support for
legacy structured
syntaxes such as
EDIFACT, e-GIF and
EIF based technologies
such as XML and XSL
• Transfer of the project
methodology already
proven to other
authorities
Transferability:
• Technical IOP: Use
of networks like GSI,
Internet, production
environment
consistent with EIF
and connection to
TESTA II
• Syntactic and
Semantic IOP: eBusiness Gateway is a
generic transformation
(XML and EDIFACT)
and transport engine
15
1.6
Results
The administration of the NHS legislation by CRU and Department of
Health has been revolutionised by the development of this
automated process. Receiving the data electronically and adopting a
"print and key" facility would have been an easier option from an IT
development viewpoint, and this would have still met the
Government steer on e-initiatives. However, we pushed the
boundaries to the limit, developing a process, which would update
the CRU system accordingly to obtain maximum efficiencies within
CRU, which were subsequently passed onto the Department of
Health.
Over 90% of cases have the NHS treatment details updated onto the
CRU record, with no manual intervention from CRU staff. This has
significantly reduced the amount of lost revenue cause by
transcription errors encountered under the clerical process. The
remaining 10% of cases have pre-determined automatic follow up
letters issued to various parties to establish further details regarding
the individuals visit to the NHS Hospital in question.
The movement of this processing activity into overnight batch has
released essential IT processing resource for CRU users, who are
required to carry out a range of other activities during the working
day.
CRU is able to issue invoices within minimal time-scales; ensuring
costs are recouped from the Insurance Industry at the earliest
opportunity.
The benefits to the NHS Users are that the form is exactly the same
as the clerical form, only it is delivered faster and is completed
online, therefore, the training requirements placed on these
individuals were minimal. The nature of their role was enhanced by
the introduction of IT based processes, thus creating a more IT
literate workforce.
Performance:
• >90% of all cases do
not require manual
intervention
• The about 10%
remaining cases have
pre-determined
automatic follow-up
• Faster processing of
service
• Reduced workload on
both sides by, at the
same time, more
qualitative work
Impact:
• Movement of this
processing into
overnight batch offers
more resources to the
users on daytime
• Creation of more IT
literate workforce
• Strategic benefits as
improved information
management can take
place with analysis
functionalities
The Dept of Health obtained strategic benefits in being able to
extract essential MI regarding those Hospitals who were not
providing the necessary data to CRU to maximise recovery on these
cases. This analysis proved to be virtually impossible under the
clerical process.
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
16
1.7
Learning points and conclusions
Critical success
factors for IOP:
Strong political support
The success of this project was reliant on the political steer to
embrace electronic initiatives, thus creating the right environment to
successfully re-engineer a high volume clerical process. CRU
embraced this steer, looked internally at our services and
approached the Department of Health, who responded positively to
our proposal, as they were also working to the same Government
steer.
Like-minded people in the different authorities
It required "like minded" positive people who picked up this steer
from Government Ministers and ensured that the correct messages
were communicated to the Local Managers, who in turn gave their
support to this innovative development. This support permeated into
a genuine action plan to introduce the link, using up to date
technology standards and a partnership culture.
e-Government Strategy and common goals as leading
guidelines
The development of the service was situated in a general
eGovernment strategy that was defined within the British
government in order to e-enable the governmental services and in
the common defined goals and the technical strategy to re-use
existing components and others. The strategic plan of the service
implementation was transparent for all involved parties from the
beginning. The existence of such a clear strategy, to which all of the
involved parties agree, is particularly a highly important success
factor in the planning of eGovernment projects.
Mutual benefits and reliable partners are still the key to
success
Mutual benefits and reliable partners are still the key to success –
winning "hearts and minds" matters most – more than technical
issues.
Good communications even in a dispersed partner-structure
Good communications were essential throughout, bearing in mind
the number of parties that had to come together to deliver the
project objectives. As a consequence the full project was delivered
on time, on target, within budget. In real terms it equates to £0.5
million pounds savings to CRU, which was subsequently passed to
the Department of Health, plus £0.5 million pounds savings
internally within Department of Health. In total £1million pounds per
annum, was saved, funds which can be better utilised in enhancing
NHS services provided throughout the UK.
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
• Strong political
support for creating
the right environment
• Like-minded people in
the different involved
authorities for
combined support
• eGovernment strategy
based on fundamental
principles and
commonly defined
goals as leading
guidelines known to all
involved parties
• Winning "hearts and
minds" matters most
• Good communications
even in a dispersed
partner-structure
17
Critical success
factors for IOP:
Overcoming technology barriers
Because of the linking of two separate Government IT-systems, it
was important to agree a common language from the onset, hence
the use of e-GIF; i.e. technology must not present barriers.
Existing structures for data exchange and/or collaboration
beforehand maybe useful
Data sharing between the agencies was already allowed and
structures in place for electronic data exchange before the new eservices have been introduced. I.e. in general, an EDIFACT/X.400
project had to be migrated to XML and hence could benefit from the
already available data structures and organisational collaborations.
So, semantic/syntactic as well as organisational interoperability is
easier to achieve when structures - electronic or non-electronic - are
already in place.
There are too many standards to choose from
Even if technology must not present barriers and interoperability
frameworks and other standards are available, there are already too
many standards to chose from.
XML and Interoperability Frameworks provide a foundation
not a panacea
Also with regard to the previous lesson learnt, certainly, there are
existing standards and there is especially XML; however, these only
provide the foundation for the developments but are not a panacea.
There is no one solution, multiple channels are required
There is no one single way to go, offering the one and only solution,
multiple channels are required to follow.
Project delivery methodology (working for the same goal)
Initially CRU and Department of Health worked to their own
departmental project management methodology. Very early in the
project, however, they recognised that there is a generic approach
needed and adopted PRINCE 2 to provide a generic framework in
which to manage the activities in both environments.
Security of sensitive personal data
As one would expect Government Departments have to be security
conscious when integrating with other IT-systems to avoid
unsolicited access to extremely sensitive personal data. They
successfully addressed all of the security issues that arose, ensuring
that the stringent Government security standards were adhered to,
and they are now the only non-DoH Department to access the
NHSNet (the Department of Health IT domain).
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
• Overcoming
technology barriers by
adhering to IOP
frameworks
• Semantic, Syntactic as
well as Organisational
IOP is easier to
achieve when
processes and/or
collaboration
structures are already
in place
• There are too many
standards to choose
from
• XML and IOP
Frameworks provide a
foundation not a
panacea
• There is no one
solution, multiple
channels are required
• Though adhering to
different authorities,
working for the same
goal
• Being security
conscious by providing
security of sensitive
personal data
18
Critical success
factors for IOP:
Co-ordination and integration of the different suppliers
It was essential that all involved parties adhered to the jointly
agreed project delivery plan, encouraging cross representation at all
project forums steering groups, project boards, user workshops etc.
to maintain good communications and a comprehensive
understanding of each other’s progress and activities.
Bottom-up initiative following the Government steer
The innovation in this project should be recognised, as whilst the
Government provided the general steer towards e-business
initiatives, this project was very much a "bottom up" initiative. Local
business managers within CRU embraced the vision, applied it to
DWP's own business processes, made an approach to the
Department of Health at a local level, and incrementally this
embryonic idea crystallised into a tangible joint delivery plan
between the two Government Departments.
Start with high volume processes in order to
subsequent development of smaller ones afterwards
• Co-ordination and
integration of the
different suppliers in
order to maintain good
communications and
comprehensive
understanding
• Bottom-up imitative
following the
Government steer can
lead to a successful
project
enable
The XML schemas were jointly developed by DWP and NHS, using
core components already registered within UK GovTalk - a central
repository supporting UK e-Government initiatives. Syntactic
compliance with the defined schema is guaranteed at the messaging
middleware layer through well-formed validation for each message
instance. Semantic interoperability is achieved through XSLT
transformation of data elements as and where necessary – in
practice this is limited but is required to ensure semantic
interoperability through legacy interfaces.
• Start with high volume
processes to reach
high benefits that in
turn enable the
implementation of
further not as much
economic business
processes for smaller
organisations
It is worth noting that initial project start-ups are not targeted at
single instances of e-forms submitted by small organisations and/or
individuals. Original data collection for the external business partner
may be in some instances Internet/browser based but this is beyond
the scope of the high volume Departmental interface exploited by
the CRU project. Nevertheless, once the business benefits have been
realised through high volume submissions, subsequent development
of a browser based submission process ensures smaller
organisations are not disadvantaged. Significantly, the return on
investment for expensive integration with the Departmental end
system will already have been achieved. Acceptance of separately
originated Internet/browser based e-forms is then a low cost
exploitation of existing e-Business Gateway interfaces. This is a
strategy which has been actively pursued by the CRU EDI project.
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
19
Critical success
factors for IOP:
Quality control
The project was managed using PRINCE2 project management
methodology, which has a clear Quality Control/Review discipline.
There are regular quality review/project checkpoint meetings held to
ensure the new system/services were meeting the customer/project
stated objectives. The pilot identified technical issues but nothing
really around the design or process flow originally agreed.
1.8
• The use of a project
management tool
(PRINCE2)enabled
regular project quality
review
References and links
No publicly accessible websites available since this is an internal project.
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
20
Annex 1: Assessment Questionnaire for the MODINIS Case
Descriptions
In order to ensure that the case descriptions meet the information needs of stakeholders in
interoperability at the local and regional level, we ask you to complete this short assessment
questionnaire. Your feedback will be used to improve the next version of the present case and will
also be taken into consideration when writing up more cases to be described in the course of the
project.
Case being reviewed:……………………………………………………………………………………………………………………….…
1.) Information content
a) Completeness of description
1
5
|-----------|-----------|-----------|-----------|
only few
all
relevant
relevant
aspects
aspects
b) Detail of description
1
3
5
3
1
|-----------|-----------|-----------|-----------|
too
right
too many
general
level
details
2.) Length of description
1
3
5
3
1
|-----------|-----------|-----------|-----------|
too
right
too
short
length
long
3.) Structure / headings
1
5
|-----------|-----------|-----------|-----------|
unclear
clear
Draft GP Case: RTA Automation Project - UK
02-2006, vs. 2.0
21
4.) Margins
1
3
5
|----------------------|-------------------- --|
misleading
not necessary
good
orientation
5.) Learning potential
1
5
|-----------|-----------|-----------|-----------|
none at all
many new insights
6.) Usefulness for your own work
1
5
|-----------|-----------|-----------|-----------|
not at all
very much
7.) Transferability of case to your country
1
5
|-----------|-----------|-----------|-----------|
not at all
very high
8.) Will you get into contact with the contact person?
1
5
|-----------|-----------|-----------|-----------|
certainly
for sure
not
Comments
______________________________________________________________________________
______________________________________________________________________________
Your affiliation
local/regional
government
national
government
Draft GP Case: RTA Automation Project - UK
IT
business
02-2006, vs. 2.0
academia
22
Prepared by:
Ralf Cimander and Herbert Kubicek
Institut für Informationsmanagement Bremen GmbH (ifib)
Am Fallturm 1, D-28359 Bremen, Germany
www.ifib.de
Tel.: (+49 421) 218 26 74, Fax: (+49 421) 218 48 94, email: info@ifib.de
http://www.ifib.de/egov-interoperability
European Institute of Public Administration (EIPA)
Centre for Research and Technology Hellas / Institute of Informatics and Telematics
(CERTH/ITI)
]
Prepared for:
European Commission
Information Society and Media Directorate-General
eGovernment Unit
Tel
Fax
(32-2) 299 02 45
(32-2) 299 41 14
E-mail
EC-egovernment-research@cec.eu.int
Website europa.eu.int/egovernment_research
