Government And IT - "A Recipe For Rip-Offs": Time For A New Approach - Public Administration Committee Contents

Written evidence submitted by Open Rights Group

ORG's response concentrates on these four questions:

—  How well is IT used in the design, delivery and improvement of public services?

—  What role should IT play in a "post-bureaucratic age"?

—  What skills does Government have and what are those it must develop in order to acquire IT capability?

—  How appropriate is the Government's existing approach to information security, information assurance and privacy?

How well is IT used in the design, delivery and improvement of public services?

ORG would like to make some general points relating to government and IT. Firstly, viewing IT as a standalone area for policy is a bad idea. A lot of modern work on systems practice shows such an approach leads to problems.

ORG's seminar project—the "Database State Seminars"[58]—involved practitioners across government IT projects. Although the starting point for our involvement was that several projects were potentially in breach of fundamental privacy rights, and others had substantial privacy risks relating to scale, access or data management, a constant theme of the participants was that IT was not being used in a coherent way to deliver the services and results that was expected.

In health, for instance, participants observed:

A … concern is Government at all levels' tendency to make arbitrary decisions. Researchers and advisors are simply unable to provide constructive solutions if problems are deemed politically infeasible. If their managers, particularly those popularly elected, are decided on a course of action there is a preference to tinker at the edges …

This conservatism is evident in official responses to the broadly constructive comments made as part of Government-commissioned studies of health systems. Evidence-based concerns identified by information security researchers are typically ignored if they do not fit the political view of a project's development.

Another explanation for this failing is that competing interests—healthcare professionals, suppliers, civil servants and patient groups—forces projects in too many directions. Without appropriate coordination, these divergent interests encourage money-wasting stasis rather than clear decision-making.[59]

Similarly, the Children and personal data seminar participants concluded:

The basic concern then is that these systems do not however actually lead to better outcomes. In practice they encourage carers to defer responsibility to the technology and colleagues. In the US, studies tentatively suggest the systems' main use is to allow carers to shift the blame for their failings. …

What is clear is that [systems such as ContactPoint] reduce the amount of face-to-face time that carers actually spend with vulnerable children. The systems mandate an over-reliance on data entry and pooling, which means time with a machine rather than care recipients. The emphasis should instead be on quality, timely interventions. Ensuring the right information is available to the right people is one fact that enables such interventions, but these computer systems are only one tool of the trade and not a total solution.

In most cases, gathering the data is useless, because most children will not require an intervention. Whereas those most at risk may not exhibit any clear indicators that serve to show which low level problems will escalate into the most serious matters. It is in these cases that carers should be speaking to the children, their families and teachers to get a sense of what they can do to help.

The data that is stored is largely subjective, relying on individual conceptions of appropriate or inappropriate behaviour.

The impression we are left with is that in both health and child care, databases have been built to answer a problem, rather than as part of a coherent system. We conclude that:


You don't want a policy on shovels when your actual problem is gardening—you need a policy on gardening. Therefore, the question isn't how to use IT the question is "How do we manage problem this problem, and does IT fit into this case."

Recommendation 1: the review considers ways to and learn from modern systems practice and allow government systems to focus on the needs of whole systems.


We recommend that government tries to encapsulate the notion of "Evolution not revolution". UK policy in our view suffers from a political imperative that "Something must be done" and reacts with "big announcements", as opposed to an approach best encapsulated by a response to a problem such as:

"It's already on the version 3.14 roadmap for 2012, testing in late 2011."

Recommendation 2: Adopt incremental improvements as the strategy for improvement of services.


Many government systems seem to be designed around the needs of government departments or officials, rather than real users, either as staff or citizens. These symptoms can be seen in relation to the health and children's database projects outlined in the Database State Seminar project.

One example ORG has been involved with is the NHS Summary Care Records. There have been many problems with this project, which seem to stem from:

1.  A likelihood they are not needed in real life emergency medical situations.

2.  A lack of understanding of how they might be used and therefore how to implement the system.

Our briefing pack highlights two contrasting projects that demonstrate these issues:

An example of good practice in this area was the former Public Health Laboratory Service, which allowed public health doctors to log individual cases of infectious disease to monitor epidemic spread, but that identifiable case data was not shared with information systems outside the PHLS. This approach assured confidentiality: there were no recorded cases of data leaks.[60]

Summary Care Records in England and Scotland give a contrast between bad and relatively good practice, according to our speaker at the seminars:

The English Summary Care Record (SCR) has never had a clearly defined use case. It was designed with no idea who the users would be or what tasks they would use it for. It was built on what might uncharitably be called a Field of Dreams brief: "If you build it, they will come." Connecting for Health maintain that SCR will grow over time and meet a number of, as yet unspecified, needs. Nobody knows what it will grow into nor whether the is the right kernel from which to grow.

The designers don't understand how the record will be used. As a result the system in general, and the security measures in particular, have some obvious design flaws. For example, the system mandates that individuals will have their own access controls and passwords, based on their roles. These security measures are not fit for purpose: sign on takes up to 90 seconds each time, and there is no guarantee that the role-based access will allow doctors and nurses to see the patient information that they need. Faced with a choice between loss of data and loss of life, in 2007 the A&E department of South Warwickshire General Hospitals Trust declared that they would knowingly break the rules and leave one senior -level smartcard in the computer for the whole shift.

In contrast, the Scottish Emergency Care Record (ECR) started with a specific use case in mind: emergency medicine. There is a small number of users, and specific settings in which the data is used: telephone triage nurses use it to provide medical advice, and to determine whether a patient should be sent to hospital. The nurse must ask the patient permission to view the record, and notification of each access is automatically sent to the patient via their GP. Security measures operate on the principle that the patient should be informed every time their record has been viewed, and by whom.

Recommendation 3: the review considers ways to allow government systems to focus on actual use cases and the needs of end users and citizens rather than be driven by Whitehall or narrow political decisions.

Recommendation 4: the review reinforces to government that IT and databases do not solve social issues by themselves.

What role should IT play in a "post-bureaucratic age"?

Creating a Big Society through open systems

While we recognize that no single approach will work for all circumstances, there are social and economic advantages to favouring an open approach. Furthermore, government spending creates a great deal of economic leverage, and should be used to the maximum public benefit.

We understand the "post bureaucratic age" to be an essential component of the thinking behind the "Big Society"; that is, that information and citizen action are essential in the society we develop, as opposed to relying on top-down government projects.

The government must specifically enable:

—  Engagement and creation of new value through making data available.

—  Use and promotion of open standards.

Systems should be designed to benefit the whole of our Big Society, which means thinking about public interfaces, not just in terms of user interfaces, but data sets, APIs and giving people the ability to write their own interesting tools to do cool stuff with the data and to interact with government.

Don't just give pdfs of consultations or an index page think about how that index could be open standard (RSS/RDF) and how society can work with powerfully.

—  Government should use publically protocols and exchange mechanisms when possible, both to fight vendor lock-in, and to enable efficient interfacing with the outside world.

—  Where it can't use existing ones it should ensure anything it creates is public or at least controlled by Government so it can be kept open for big society use and again avoid lock-in.

What skills does Government have and what are those it must develop in order to acquire IT capability?

Current levels and diversity of innovation in the IT sector make it impossible to predict what particular technical knowledge will be necessary to develop in house for the government to acquire IT capability. The in house skills to develop will probably be high level systems integration, strategic technology assessments, etc.

Each department will need to assess which particular skill they would need to strengthen. The potential list could be open ended: web services, geo-data, linked data, identity, usability, encryption and security, networks, etc.

However, given the size of government and the diversity of evolving challenges it is impossible to develop every skill and capability. The government should develop capacity for open innovation strategies that capture independent ideas and go beyond simple outsourcing to large providers.

The best example of open innovation is Procter and Gamble Connect and Develop, but even within government there are already initiatives such as ideas competitions and crowdsourcing. However these are currently experiments amounting to a negligible fraction of the large ICT contracts. We welcome the recent announcement of a new "Crown Commercial Representative" to help innovative small and medium sized enterprises (SMEs) pitch their services to government.[61]

However, a wider transformation will be required to ensure changes beyond tokenistic initiatives. If the government officials responsible for assessing the new innovations of these SMEs are not capable to make informed technical decisions they will avoid the risk by default.

Transparency and an open process of decisions to arrive at particular technical solutions is paramount, and these should be decoupled from the tendering and commercial contracting of the services to provide those solutions.

This would allow the government to tap a large pool of technical expertise that would be very unlikely to be attracted to a civil service or ancillary state service job.

Skills in departments and policy makers to understand technical challenges

ORG frequently encounters levels of technical ignorance that suggest that government departments may be easily misled my salespeople or simply not understand the policy challenges they face. To give some examples from our work:

Electronic and Internet voting

During the Labour government, a policy of electoral modernization was pursued, with an underlying assumption that more accessible means of voting would drive electoral turn out up. ORG wrote policy briefings and observed the counts.[62] Thus methods varying from postal voting through to internet voting were examined. Electronic voting trials were conducted.

1.  The underlying challenge of delivering secure, anonymous but transparent and verifiable voting was not understood or examined. Academic study has for a long time viewed this problem as currently practically insoluble. Policy however was conducted on the basis that there was no fundamental problem with the technology.

2.  The trials were badly run. This was not purely a question of the providers; government did not properly handle the process through its own lack of knowledge and rigour. The pilot providers were deeply unhappy with pressure they were put under as the result of late contract signings while the delivery date—an election—was immovable. Results were not comparable or useful.

3.  A fundamental but mundane problem around the accuracy of voter registration became obvious, but could have been identified at the start of the process, if electoral modernization had been thought of as a question of a system rather than ways to add technology.

4.  The Electoral Commission played a very useful role in identifying tasks such as standard setting, criteria and insisting that cost is an element in current questions such as the use of electronic counting.

5.  At all levels, a lack of technical expertise seems to add to the problem of understanding and evaluating technologies, and resisting the simplistic sales pitch of vendors.

Information Commissioner

The Information Commissioner operates a data protection regime which is based on principles enshrined in law. It may be supposed, therefore, that their role is technology neutral and advice need not consider technical aspects of implementation. However, in practice the ICO needs a great deal of expertise. There is a need for technical expertise to, for instance:

1.  Undertake investigations of datasets when breaches occur.

2.  Understand the implications of the use of a specialist technology like cookies, or new technologies such as RFIDs or biometrics.

3.  Understanding the potential of privacy-enhancing technologies and encryption methods.

The ICO has recognized that technology has become central to their work, but we have yet to see how they build in this expertise, or what effect it has on their advice and guidance. It is remarkable that it has taken over a decade for the ICO to recognize the problem, and we believe this is parallel to many government departments.

How appropriate is the Government's existing approach to information security, information assurance and privacy?

Security and privacy should be considered at the start of the process

In IT, the security and privacy of individual users is closely linked. Privacy relies on security, and both needs have to be considered early.

A number of government IT projects seem to have either underspent on security and privacy, or have ignored them until very late, when meeting requirements becomes very difficult. In relation to road pricing, one commercial developer at our seminar project observed:

Time-Distance-Position road pricing is potentially—but does not have to be—highly invasive. From what we can see so far, the DoT is reluctant to take on board the privacy issue as something that needs to be considered from the outset.

Anything that involves technology and money, especially in the public space, deserves to be thoroughly scrutinised through a security and privacy study, as we have tried to get DoT to do with respect to TDP. A lot of people try to tack on security and privacy at the end of system design, but the earlier you think about them the better.[63]

The impact of government IT systems on people's privacy can be very large and disproportionate. For instance, ORG examined the impacts of Oyster cards in London, where travel data is retained for two months, well beyond genuine business need. This clearly has a major impact on users' privacy and is in effect an extension of police surveillance powers.

Similarly, NHS Care records, DNA databases and ID cards each had considerable impacts on individuals' privacy. While the coalition has correctly identified the poor results in several of these cases, the purpose of this review is to ask how these problem may be avoided.

Furthermore, work by No2ID via FOI requests in the wake of the Database State report has revealed that many departments have little idea about what databases they are maintaining and what data therefore they are keeping. The scale of privacy impacts and risks is therefore impossible to understand.

ORG's seminar project—the "Database State Seminars"[64]—involving practitioners across government IT projects. To enhance privacy, the seminar attendees recommended these principles:

—  Minimise data: collect only what is needed, and keep it no longer than necessary. Central systems should be simple and minimal and hold sensitive data only when both proportionate and necessary;

—  Share data only where proportionate and necessary: Government should only compel the provision or sharing of sensitive personal data for clearly defined purposes that are proportionate and necessary in a democratic society;

—  Give subjects ownership of their data: By default sensitive personal information should be kept on local systems and shared only with the subject's fully informed consent; and

—  Build for anonymity: Citizens should have the right to access most public services anonymously.

Recommendation: mandatory privacy impact assessments for any IT scheme affecting large numbers of users.

Recommendation: clear retrospective mapping of government data held on individuals, and transparency over who is holding what data.

Recommendation: accept the principles of data minimization, limiting data sharing, giving users ownership of their data and building systems that allow access of government services anonymously.

February 2011

58 Back

59   See Database State Seminar report, attached as appendix (not printed) Back

60   Database State Seminar Briefing Pack, Guest Speaker notes (not printed) Back

61 Back

62 Back

63   See Database State Seminar Transport report in Appendix (not printed) Back



previous page contents next page

© Parliamentary copyright 2011
Prepared 28 July 2011