Opening up local government transactions - Not just data - Mike Thacker

In some circles, the term “transparency” seems to have supplanted “open government” which might imply the objective is for government to go on doing what it is doing now but in a more transparent way.  That would be a pity because there is so much potential for improvement if people outside government can not only see what it is doing but also help do it better.

The Government Digital Service (GDS) seems to recognise this in the way it has opened up its GOV.UK developments.  Source code is published openly.  Separation between front end and back end program code (see ‘The technical bit” in the GDS blog on their Trade Tariff tool) suggests that developers can provide their own front ends to GDS applications.  It would be nice to hear of examples where this is done.

It is harder for third parties to develop apps for local government transactions that are delivered by many different councils and other organisations.  There are two main barriers to people developing such apps:

1. each organisation tends to describe its services slightly differently
2. organisations use a variety of different digital interfaces and often offer no API for third party access

How services are described

The first of these barriers is largely overcome by adopting the Local Government Service List (LGSL), which has matured over the last ten years to provide common references for a comprehensive range of local government’s services.  This list is used by Directgov to reference web pages provided by each council for a range of popular services and happily it continues to be used as Directgov migrates to GOV.UK.

Directgov makes public the list of links for each LGSL service.  In some two tier council areas (eg Hampshire and North Yorkshire), these links are used to reference services between county and district councils.  Brent uses the same approach to link to services in neighbouring London boroughs (see case studies).

How services are transacted

Overcoming the second barrier – that of differing interfaces – also relies on the emergence of standards that are widely adopted.  The main candidate for a standard for non-personal services is Open311 which has gained some traction in the USA, where 311 is the telephone number for reporting local issues (graffiti, potholes, dumped rubbish, etc).

The Lagan (now part of the Kana) CRM system can support Open311.  Accompanying apps for iPhone and Android illustrate how any developer can provide an interface for it.  Such apps can be provided by individual councils who support Open311, but their real value will only come if Open311 adoption by councils is sufficiently widespread that apps can cover many council areas.

My Society’s FixMyStreet sends an email message on each case to the relevant public sector body, identified from geographical location and type of issue.  It is, I am advised, Open311 compatible and is connected to multiple council CRMs from different vendors that use their own standards.

LoveCleanStreets is similar in ambition to FixMyStreet.  Since it originated in 2004 it has implemented a variety of different means of connecting to back end council systems to avoid the need to rekey cases from email.

Reporting service transactions

All of the above approaches help when it comes to counting actual transactions:

• Directgov can count, from web logs, its local service enquiries by LGSL service number, interaction type and council
• Open311 has standard means of enquiring on service requests made
• FixMyStreet provides an RSS stream of issues raised for a specified council
• LoveCleanStreets offers an API for reporting cases raised in any area.

By combing data from these sources we get real counts of real services transactions.  Sadly at present these means only account for a tiny proportion of council transactions and so don’t help much gleaning figures such as those recently estimated for local government by GDS.

Where do we go from here?

So at present we have one standard for consistent referencing of services used to varying degrees by councils and other public sector bodies.

We have one candidate standard (Open311) for submitting service requests and reporting on them, which is barely used in the UK.  Application specific interfaces are emerging from GDS, LoveCleanStreets and, no doubt, others.

From October 2012 GDS will take over the Electronic Licence Management System (ELMS) used by some local authorities.  Whilst initially emailing applications to authorities, the system will "provide the foundations for extracting the application data in an electronic format, so that it can be input into each authority's CRM / case management systems" (see ELMS change for more).

Standards don’t come about because someone imposes them; they emerge (as LGSL has) from people who recognise the common benefit of a consistent approach.

We need standard ways of transacting services and reporting on what has been transacted if we are to get a true picture of what local government does and give others the opportunity of improving it.

In times of austerity, councils have little room to invest in approaches which speed up standardisation.  Perhaps the best we can do at present is to highlight the approaches summarised above to smooth the path to an eventual joint better way of working.