View
218
Download
0
Category
Preview:
Citation preview
Citizen Information Project
Final report: Annex 4:Technical standards and
recommendations
Version Control
Date of Issue 14th June 2005
Version Number 1.0
Version Date Author Reason for Change
1.0 14/6/2005 R Carmichael Final report
Metadata
Coverage UK
Creator Office for National Statistics, GeneralRegister Office, Citizen InformationProject Team
Date Issued
Language English
Publisher Office for National Statistics, 1 DrummondGate, London, SW1V 2QQ
Status Approved by Project Manager
Subject Findings and Recommendations of theCitizen Information Project
Subject.category Public Administration
Title Citizen Information Project Final report:Annex 4: Technical Standards andRecommendations
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
Contents
1 Introduction .........................................................................................................1
1.1 Preface .................................................................................................................2
2 Summary of recommendations...........................................................................3
2.1 Main Recommendations......................................................................................4
2.2 Detailed Recommendations................................................................................4
Person name........................................................................................................... 4
Address.................................................................................................................. 4
Gender ................................................................................................................... 5
Date of birth............................................................................................................ 5
Place of birth........................................................................................................... 5
Date of death .......................................................................................................... 5
Meta data................................................................................................................ 5
3 Technical standards ............................................................................................6
3.1 Generic Technical Standards:.............................................................................7
UML: ...................................................................................................................... 7
XML:....................................................................................................................... 7
e-Government standards ......................................................................................... 7
3.2 Data Structure and Metadata Standards ............................................................9
Identity and Names:................................................................................................. 9
Addresses: ............................................................................................................. 9
Electoral data: ....................................................................................................... 11
Dates:................................................................................................................... 11
Language.............................................................................................................. 11
Metadata.............................................................................................................. 11
3.3 Data Transfer Standards ...................................................................................12
4 Comparison of data standards .........................................................................13
4.1 Name ..................................................................................................................14
Relevant standards................................................................................................ 14
Differences between standards .............................................................................. 14
Merits of standards ................................................................................................ 14
Usage................................................................................................................... 14
Recommendations and discussion.......................................................................... 14
4.2 Address..............................................................................................................15
Relevant standards................................................................................................ 15
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
Differences between standards .............................................................................. 16
Usage................................................................................................................... 17
Merits of standards ................................................................................................ 18
Recommendations and discussion.......................................................................... 19
4.3 Gender................................................................................................................20
Relevant standards................................................................................................ 20
Differences between standards .............................................................................. 20
Merits of standards ................................................................................................ 20
Usage................................................................................................................... 20
Recommendations and discussion.......................................................................... 20
Short term recommendation: .................................................................................. 21
Long term recommendation:................................................................................... 21
4.4 Date of Birth.......................................................................................................21
Relevant standards................................................................................................ 21
Differences between standards .............................................................................. 21
Merits of standards ................................................................................................ 21
Usage................................................................................................................... 21
Recommendations and discussion.......................................................................... 21
4.5 Place of Birth .....................................................................................................22
Relevant standards (refer to Appendix I for comparison) .......................................... 22
Differences between standards .............................................................................. 22
Merits of standards ................................................................................................ 22
Usage................................................................................................................... 22
Recommendations and discussion.......................................................................... 22
4.6 Date of Death .....................................................................................................23
Relevant standards................................................................................................ 23
Differences between standards .............................................................................. 23
Merits of standards ................................................................................................ 23
Usage................................................................................................................... 23
Recommendations and discussion.......................................................................... 23
5 Metadata standards...........................................................................................25
Metadata.............................................................................................................. 26
5.1 Provenance ........................................................................................................27
5.2 Event data ..........................................................................................................27
5.3 Quality characteristics ......................................................................................28
Dataset Scope ...................................................................................................... 31
Coverage.............................................................................................................. 31
Currency............................................................................................................... 31
Completeness....................................................................................................... 31
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
Formatting ............................................................................................................ 31
Internal Consistency.............................................................................................. 32
Verification............................................................................................................ 32
Validity ................................................................................................................. 32
Comparison of e-GMS with requirements of CIP...................................................... 32
5.4 Recommendations.............................................................................................37
6 Data sharing standards.....................................................................................38
Appendices..................................................................................................................40
A. Verification .........................................................................................................41
B. Name verification...............................................................................................42
C. Address verification ..........................................................................................43
D. Date of Birth verification ...................................................................................44
E. Date of Death verification..................................................................................45
F. Validation Standards .........................................................................................46
G. Date validation...................................................................................................47
H. Comparison of Name and Address standards .................................................48
I. Conversion of BS7666 addresses to postal addresses...................................51
J. List of local authorities and their NLPG status ................................................55
K. New addresses and postcodes.........................................................................63
L. Discussion on multiple occupancy ..................................................................66
M. Correct address .................................................................................................69
N. Royal Mail Discounts.........................................................................................70
O. Dataset Terminology .........................................................................................72
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
1 Preface
1 Introduction
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
2 Preface
1.1 Preface
1.1.1 The Citizen Information Project Final Report recommends the creation of anadult population register that will deliver benefits by sharing basic contactinformation (name, address, date of birth etc) across the public sector. Thereport recommends that the development of a population register isimplemented as part of the ID Cards Scheme by utilising the National IdentityRegister (NIR) and that in the interim a range of short term data sharinginitiatives are explored further.
1.1.2 This document identifies the technical standards that are relevant to thisdevelopment.
1.1.1 Section 2 identifies a number of detailed recommendations. These underpin therecommendation in the main report that departments should adopt at least the sixrelevant data elements from the Government Data Standard (GDS) for addressand personal details while considering specific, short-term arrangements forsharing contact data. We also commend the detailed recommendations below tothe ID Cards Programme team for consideration during the development and useof the National Identity Register.
1.1.2 Section 3 expands on these recommendations to:
• identify relevant standards
• contrast differences between standards
• compare the merits of each
• identify where standards are already in use
• recommend changes or additions to standards.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
3 Preface
2 Summary of recommendations
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
4 Main Recommendations
2.1 Main Recommendations
2.1.1 It is recommended that NIR and any data sharing initiatives:
• Adopt at least the six relevant data elements from the Government DataStandard (GDS) for address and personal details. This provides a commondefinition, format and structure of data so that all parties understandprecisely what information is available, its scope and limitations. In the shortterm this will enable more efficient sharing of data and in the long termensure that the NIR is of maximum benefit to the public sector. There aresome modifications to enhance the functionality of these data elementsrecommended below.
2.1.2 It is recommended that the e-GU should lead on:
• Developing a metadata standard for basic personal data based on theexisting e-Government Metadata Standard. This will be used to describecondition of the personal data stored or shared. This is described in moredetail below
• Developing a standard for data transfer; this should include developing a setof exchange protocols and standard interfaces to facilitate data sharing.
2.2 Detailed Recommendations
2.1.3 The following are the GDS data elements relating to citizen contact details anddetailed recommendations concerning particular changes or aspects of theseelements. Also described are more detailed recommendations regarding theuse of meta data.
Person name
2.1.4 Include additional functionality to GDS to support multiple names and metadataregarding the structure of names, for example GDS should identify where the‘family’ name is placed before the given name.
2.1.5 Store multiple requested names against an identity.
Address
2.1.6 Adopt BS 7666 compliant address format across the public sector, and migrateof any ‘simple address’ format to full BS 7666 addresses. In particular the useof the Unique Property Reference Number (UPRN) should be encouraged as anunambiguous and interoperable identifier for properties/households (see Annex3 “Technical Options and Solutions”).
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
5 Detailed Recommendations
2.1.7 Investigate methods for deriving addresses in a format recognised by RoyalMail from those held in BS7666 format.
2.1.8 Closely monitor developments regarding the National Spatial AddressInfrastructure, launched in May 2005 and seeks to integrate NLPG/LLPG, RoyalMail (PAF) and OS Addresspoint Data.
Gender
2.1.9 Data owners to confirm if Gender in their systems refers to ‘Current Gender’.‘Gender at Registration’ should only be held where there are specific businessreasons to do so.
Date of birth
2.1.10 Recognise the legitimate reasons for entering a ‘nominated’ or default date ofbirth and adopt a consistent ‘default’ date of birth of 1st January. If there arelegitimate business reasons why different dates are advantageous the use ofmetadata (see section 4) should be considered.
Place of birth
2.1.11 In the short term there are advantages for some systems to hold Place of Birthto provide additional differentiation between identities. When recording a ‘place’it should be unambiguous, recognisable and be precise enough to reasonablybe expected to distinguish two people with the same name and date of birth,without further geographical information being required.
2.1.12 It is recommended that this guidance is added to the GDS.
Date of death
2.1.13 Data owners should record the GDS verification standards for data of death asis necessary to ensure that date can be shared and used in other businessprocesses successfully. Where data owners do not hold record of theverification they should identify which level there data complies with. Forexample all GRO data will be at verification level 3 (when a Death Certificate isissued).
Meta data
2.1.14 In addition to the Name and Date of Birth metadata described above a schemashould be developed to describe the following attributes;
• Provenance. This should identify the originator of the data
• Event Data. This should identify temporal related data such as the date itwas added to the system (Start Date) and possibly an end date.
• Quality Characteristics. This should identify the quality of the data using theQuality Framework described in Annex 3
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
6 Detailed Recommendations
3 Technical standards
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
7 Generic Technical Standards:
3.1 Generic Technical Standards:
UML:
2.1.15 Unified Modelling Language (UML) is a standard method used to present thevarious data structures as data models. This helps to specify, visualize, anddocument models of data sets. It is also methodology-independent so thatregardless of the way that the system is implemented UML can be used toexplain the principles. This is particularly useful when comparing different datasets.
XML:
2.1.16 eXtensible Markup Language is a language for documents containing structuredinformation. This is information that contains both content and some indicationof what role that content plays. XML provides the facility to define what thecontent should be and its structural relationship. The e-GovernmentInteroperability Framework, specifies XML as the primary means for dataintegration. Hence it is necessary and desirable to consider this basic personaldata as an XML schema. For further details about WML refer tohttp://www.w3.org/TR/REC-xml/.
e-Government standardsi
2.1.17 There are a number of technical standards that comprise the of e-Governmentstrategy. These are split into 6 areas:
The Gateway:
2.1.18 This provides citizens with the opportunity to conduct secure transactions withthe public sector via the internet. Currently this is a 2 stage authenticationprocess
2.1.19 Subject to the NINO being adopted as a more genuine identifier in the shortterm or the substantial take up of ID Cards there is potential for the currentprocess to be rationalised to a single stage authentication.
The e-Government Interoperability Framework (e-GIF)
2.1.20 The e-GIF defines the technical policies and specifications governinginformation flows across government and the public sector. The policies coverinterconnectivity, data integration, e-services access and content management.Version 6.0 contains the high level policy statements, management,implementation and compliance regimes, whilst technical policies andspecifications are contained in the Technical Standards Catalogue (TSC).
2.1.21 As referred to above this identifies XML as the primary method for dataexchange. It is this aspect that is of primary importance to CIP.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
8 Generic Technical Standards:
XML Schemas
2.1.22 XML schemas have been defined for use throughout the public sectorcontaining common data definitions.
2.1.23 The UK Government Data Standards Catalogueii is most relevant to CIP as thisdescribes the core schemas, which contain the type of data required for apopulation register.
The e-Government Metadata Standard
2.1.24 The e-Government Metadata Standard (e-GMS) lays down the elements,refinements and encoding schemes needed to create metadata for informationresources or for search systems for information systems. The e-GMS forms partof the e-GIF.
2.1.25 This is relevant to CIP objectives in both the short and long term. Currentlystakeholders systems do not hold all the metadata described. Adopting thisstandard for metadata would provide a common standard for data sharing inboth the short and long term. This is discussed further in Section 5.
The Government Category List
2.1.26 The GCL (Government Category List) is a structured list of categories for usewithin the subject.category element of the e-GMS.
The e-Services Framework
2.1.27 This is a structure for developing semantic specifications and standards for e-Services. An e-Service is any electronic service involving interoperabilitybetween computer systems. It includes, but is not limited to, electronic datainterchange and messaging services and is relevant to any proposed datasharing initiatives.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
9 Data Structure and Metadata Standards
3.2 Data Structure and Metadata Standards
2.1.28 There are a number of other National and International standards as well aslocal system standards covering basic personal data, these include:
Identity and Names:
BRITISH STANDARD BS 8766:2004 Names and identifiers ofindividuals and groups — Data structure for interoperability —Specification
2.1.29 This British Standard specifies a data structure for recording names andidentifiers of individuals and groups for the purposes of interoperability betweeninformation systems. This comprises six basic classes of objects of which threeare relevant to short term data sharing and ID Cards:
• Person,
• Person name,
• Person identifier.
2.1.30 It does not prescribe any personal or group identifiers but does allow the use ofexisting identifiers such as National Insurance Number or customer referencenumber.
Addresses:
BRITISH STANDARD BS 7666-3:2000 Spatial data-sets forgeographical referencing – Part 3: Specification for addresses
2.1.31 This British standard ‘specifies a model and structure for an address andprovides a means by which an address may be constructed. The purpose of anaddress is to provide a description of a real-world object by reference to itslocation. An object for which an address may be constructed is termed an“addressable object”'.’iii
2.1.32 This method for defining an address has been adopted by a number of otherinitiatives including the GDS, National Land and Property Gazetteer and theDefinitive National Address Project (DNA) in Scotland. Pointer the addressregister initiative for Northern Ireland is moving towards providing data that iscompliant with the British Standard1.
2.1.33 This standard also accommodates the use of the Unique Property ReferenceNumber (UPRN) although it does not allocate these numbers.
1 http://www.osni.gov.uk/about/FAQ%20answers.htm
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
10 Data Structure and Metadata Standards
ROYAL MAIL Post Office Address File (PAF)
2.1.34 Royal Mail hold a database of addresses to which they deliver mail – deliverypoints – this is used to provide data to a number of other systems includingOrdnance Survey’s Address Point and QAS’s Quick Address software.
National Spatial Address Infrastructure (NSAI)
2.1.35 This is an ODPM initiative to integrate data from a variety of sources includingOrdnance Survey, Royal Mail, Valuation Office and LLPG/NLPG. The imitativehas only recently been announced (May 2005) but it is intended to migratethese data sources to a BS7666 compliant data set. Further details can beobtained at :
• http://www.odpm.gov.uk/stellent/groups/odpm_planning/documents/downloadable/odpm_plan_037965.pdf
International Address Standard UPU S42-1
2.1.36 An international standard for Addresses has been developed and approved bythe Universal Postal Union (UPU). The UPU has 190 member countries, and isthe primary forum for cooperation between postal services and helps to developa universal network of up-to-date products and services. The organisation hasan advisory, mediating and liaison role, and provides technical assistance.
2.1.37 Address templates in UPU S42 are described both in natural language andusing an XML format known as the Postal Address Template DescriptionLanguage (PATDL).iv
2.1.38 Reference to this standard is made for information and to raise awareness ofpossible methods for holding international addresses should this be necessary.There is no further discussion of this standard or PATDL.
OSIS: BT Operator Services Information System
2.1.39 The Operator Services Information System (OSIS) is the core database thatunder pins BT’s Directory Services. It holds BT and Licencesd Operatorscustomer Number Information (e.g. names, addresses and telephone numbers)and input is able to be provided from:-
• BT’s Retail divisions (for BT customer entries)
• BT DirectorySolutions (for all customer entries)
• On-Line Access to OSIS (for BT & Licencesd Operators customer entries)
2.1.40 OSIS data is extracted and used for a variety of Number Information productsand services by both BT and other organisations.v
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
11 Data Structure and Metadata Standards
Electoral data:
Election Mark-up Language (EML)
2.1.41 EML is an XML schema developed by the Election and Voter ServicesTechnical Committee of OASIS, the international XML interoperabilityconsortium. The committee’s mission statement is, in part, to:
• “Develop a standard for the structured interchange among hardware,software, and service providers who engage in any aspect of providingelection or voter services to public or private organizations….”
2.1.42 This has particular relevance as it includes specifications for:
• Voter Registration information, including eligible voter lists
• Voter Authentication
2.1.43 The standard covers both voters and candidate’s registration, we have onlyconsidered voters.v i
Dates:
ISO 8601: International Standard Date and Time Notation
2.1.44 Internationally a number of different date formats are used this internationaldefines an unambiguous date format. Also well as defining each element of thedate and time clearly the standard facilitates the ordering of dateschronologically and searching of dates.
Language
ISO 639-2:1998 Codes for the representation of names oflanguages -- Part 2: Alpha-3 code
• ISO 639 is one of several international standards that lists short codes forlanguage names. For a full list of codes seehttp://www.loc.gov/standards/iso639-2/langcodes.html
• Extensions such as sgn-GB are defined according to RFC 1766. Seehttp://www.faqs.org/rfcs/rfc1766.html for further details.
Metadata
e-Government Metadata Standard
2.1.45 As referred to above in the section describing e-Government Standards there isan e-Government Metadata Standard (e-GMS) which describes standards forMetadata within e-Government. This is discussed in more detail in Section 5.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
12 Data Transfer Standards
Verification
2.1.46 Verification of the data is key item of metadata and the following standardsprovide guidance on this;
• HMG’s Minimum Requirements for the Verification of the Identity ofIndividuals.
• Government Data Standards Catalogue. This has a list of documents thatsupport verification to different levels
• DWP’s The Departmental Verification Requirement. This catalogues DWP’sverification requirements.
2.1.47 For discussion of these standards refer to Appendix A
Validation
2.1.48 Validation of the data is important either in the business rules for a system or inthe metadata surrounding it and the following standards provide guidance onthis;
• Government Data Standards Catalogue. This gives guidance on appropriatevalidation of data.
• DWP’s The Departmental Verification Requirement. This catalogues DWP’svalidation rules.
2.1.49 For discussion of these standards refer to Appendices F and G
3.3 Data Transfer Standards
2.1.50 As described in section 3.1.7 e-GIF is the primary source of standards for thesecure exchange of data as this provides details of the technical policies forinterconnection. Within e-GIF there are also a number of standards coveringthe secure exchange of data.
• The Government Secure Intranet (GSi) for secure exchange of emails andconnection to the internet.
• The e-GIF Technical Standards Catalogue contains a number of standardsrelating to Interconnection (communication between systems) and DataIntegration.
• e-Government Strategy Framework Policy and Guidelines
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
13 Data Transfer Standards
4 Comparison of datastandards
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
14 Name
4.1 Name
Relevant standards
• Government Data Standard
• BS 8766 Names and identifiers of individuals and groups
• Election Markup Language (EML)
• BT Operator Services Information System (OSIS)
Differences between standards
2.1.51 BS 8766 holds more detailed data than GDS but GDS accommodatesunstructured items such as ‘requested name’. For example, GDS would holdGiven Name – ‘Anthony’ and Family Name – ‘Wedgewood-Benn’ andRequested Name ‘Tony Benn’. Where as BS8766 would not hold the requestedname but would hold the language that the name was given in and any numberof structured names for an individual. This is described in more detail inAppendix H
2.1.52 EML adopts the GDS standard for storing name data of voters.
2.1.53 OSIS is only intended to provide sufficient details for a telephone caller toidentify the intended person or service they wish to call and so is not rigorousenough for the purposes of CIP.
Merits of standards
2.1.54 Both standards have merits;
• BS8766 allows more data and detail (e.g. multiple names, start and enddates etc) but this must be structured.
• GDS is more flexible about what can be input but it limits input.
Usage
2.1.55 BS 8766 is a new standard published in October 2004 so its usage is limited.
Recommendations and discussion
2.1.56 It has been very clear from our discussions with DWP and other stakeholdersthat it is important to be able to correctly name people, and in the case of thosewith titles or honours these should be used where appropriate. People willquickly become upset with a system that referred to someone who wanted to beknown as Dame J. Smith as Mrs J. Smith or even Jane Smith. So it is clear thata requested name field is important. However when considering data matchingand sharing it is equally important to be able to identify that Dame J. Smith andJane Smith are the same person or that Mrs. J Smith is the same person asMiss Joanne Brown.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
15 Address
2.1.57 BS 8766’s structured approach has more to offer for data matching and datasharing and provides a useful set of metadata around the name. It also has thefacility to store any number of requested names or aliases and date stampthem. However, it does this in a structured way which may not fit with thecitizen’s requirements for a ‘requested name’ – is ‘Sting’ a given name or afamily name? This ambiguity starts to undermine a structured system as itshould be used consistently to be most beneficial. Hence, the unstructuredapproach of the GDS provides greater flexibility in storing this kind of data –here it doesn’t matter if ‘Sting’ is a given name or a family name it is simply thename the citizen prefers to be called.
2.1.58 In terms of realising benefits to the public sector the British Standard offersmore functionality than GDS and so would provide more flexibility as users ofthe data could chose to import elements they require and aliases or preferrednames can be accommodated. It also might be able to provide improved frauddetection by storing loosely associated aliases against an identity. However, itdoes not offer the same benefit to the citizen as it is more prescriptive about therequested name.
Recommendation:
2.1.59 As there is already a mechanism for adoption of GDS by departments we wouldrecommend that the GDS is modified to include some of the additionalfunctionality regarding multiple names and metadata.
• Multiple Name Changes. It is recommended that multiple structured namescan be stored against an identity. The unstructured ‘Requested Name’ and‘Full Name’ may be maintained as a single element and it may be that thiscan be achieved within the existing structure of GDS by stakeholderimplementations
• Metadata changes. Additional meta data items that are recommended toallow the correct cultural ordering of names to be identified and possibly thelanguage element from BS 8766 could be included. Further discussion ofMetadata can be found in Section 4.
4.2 Address
Relevant standards
• Post Office Address File
• BRITISH STANDARD BS 7666-3:2000 Spatial data-sets for geographicalreferencing – Part 3: Specification for addresses
• BT Operator Services Information System (OSIS)
• National Spatial Address Infrastructure (NSAI) – probable implementation ofBS7666
• NHS Address standard - NHS Data Dictionary
• Election Markup Language (EML)
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
16 Address
• International Address Standard UPU S42-1 PADL – Not discussed
Differences between standards
2.1.60 When comparing these standards care must be taken to be clear whethercomparison is being made of the structure and format of the data is held or thequality of the actual data and the method for its collection. As theimplementation of the PAF and BS 7666 can confuse discussions. Hence thissection outlines the elements that are compared.
Format
2.1.61 Both the PAF and BS7666 allow addresses to be held in a structured format.There is little substantial difference in the formats as both allow the same datato be held but using slightly different terminology. Although the PAF file doesidentify an extra level of thoroughfare and locality, it does recognise that thedependant thoroughfare element is rarely used.
2.1.62 Within the ‘PAF’ there is also an Alias File for elements not required by theactual PAF file often called ‘Vanity’ elements such as house names andcounties there is also a Welsh Mainfile for Welsh language thoroughfares andlocalities. This is discussed further in the merits below.
2.1.63 OSIS holds addresses in a less structured format but the main elements of theaddress are identifiable.
Purpose
2.1.64 PAF is primarily concerned with delivering mail and as such holds addressesstructured to provide a mailing address.
2.1.65 BS 7666 is primarily concerned with describing the geo spatial location of anobject, i.e. where a house or a flat is. It is possible to derive a postal addressfrom an address held in this format (see Appendix I).
2.1.66 OSIS provides an address for a given telephone number.
Scope of Dataset
2.1.67 The amount of the data stored is governed by the scope of the dataset. It islisted here with widest scope given first;
• BS7666 all addresses but also non addressable objects (i.e. Cash VendingMachines).
• PAF all addresses with a Delivery Point (i.e. Letter box).
• OSIS addresses where there is a telephone number.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
17 Address
Ownership
2.1.68 Both the PAF file and the OSIS are proprietary products whereas the BritishStandard was developed to provide an independent structured format toexchange and store address data to facilitate a national address register.
Usage
2.1.69 PAF is primarily used to deliver mail although the data is also used in a numberof other applications. Similarly OSIS is primarily used for identifying telephonenumbers from address information (Telephone Directories and 118 services) butits data is also used by other applications. PAF has an almost ‘complete’national address data set and has been used to provide the basis for a numberof other Address based systems as described previously.
2.1.70 BS7666 is recommended by the GDS and has been used by an increasingnumber of Local Authorities to compile Local Land and Property Gazetteers(LLPG) which are being combined into a National Land and Property Gazetteer(NLPG). It is through these implementations that the data, and hence, the datastructure is adopted elsewhere.
2.1.71 BS7666 through the NLPG has been adopted into the Valuation Office’sValuebill project.
2.1.72 It is also proposed by the UK implementation of EML that a BS7666 be used tostore addresses.
2.1.73 Currently, it is intended that the new NSAI will adopt BS7666 format.
Geographical issues
2.1.74 Geospatial data relating to addresses (i.e. grid references and GIS information)is available from the Ordnance Survey’s Addresspoint. This is based onaddress data from PAF. Geographical co-ordinates of each household/propertyare also held by LLPG/NLPG and this was originally derived from ValuationOffice Information.
Data Population and Maintenance
2.1.75 Data population and maintenance is important factor in these implementations.
2.1.76 PAF is populated and maintained primarily through the delivery network, withpostmen making reports on the end of a round of any changes to the data. Alsowhen a new housing development is planned Royal Mail are consulted on streetnaming and numbering issues. Hence, they are aware of new properties andmaintain a separate file of houses yet to be inhabited. These are transferred onto the live PAF once they start to receive mail or the postman becomes aware ofthe fact. Often Royal Mail may get notification via a query from a mail ordercompany whose copy of PAF data does yet contain the address. Royal Mailissue updates to the data on a monthly basis.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
18 Address
2.1.77 Population of BS7666’s main implementation (the LLPG’s) is carried out byLocal Authorities. Initial population of all LLPG’s Valuation Office data has beencompleted. . A unique property reference (UPRN) is allocated to each propertyby the Local Authority from a batch issued from the national set. The UPRN is atwelve digit number to uniquely identify a property with no further intelligence,i.e. no locality identification, no check digit, etc. Having collated this data in anapproved data transfer format the data can be uploaded to the NationalGazetteer (NLPG).
2.1.78 The LLPG’s are being progressively validated and cleansed by LocalAuthorities. Their subsequent maintenance comes via citizen interaction withthe Local Authority and use of the data within authority business such asplanning applications. The level of integration with authority businessprocesses is variable but the increasing implementation of CRM systems isimproving this integration. There is a range of involvement with the NLPG byLocal Authorities, some have not completed their LLPG and some update theNLPG almost daily (see Appendix J). It should be noted that the NSAI willidentify 30-50 exemplar authorities to benchmark against.
Merits of standards
2.1.79 The merits of PAF and BS7666 can be summarised thus;
PAF Merits
Merit BS7666 ApproachData StructurePostal addresses readily available,
Royal Mail maintains PAF anddetermines what constitutes acorrect postal address, Postaltown etc.
Postal address derived (see AppendixJ)
Vanity Elements,Address is an importantelement of a citizen’s sense ofidentity and a ‘correct’address may not reflect thisidentity, this allows someflexibility in the address.
Both house number and name can bestored in appropriate field.
Welsh language Elements,Allows ‘bilingual’ addresses.
Additional address elementsDependant Thoroughfare andDoubly dependant locality.
Simpler structure more concernedwith locating an address.
Data Population and MaintenanceLinked with postal delivery,
PAF is maintained bypostmen’s feedback andobservations. Updates issued
No direct link to postal services, datatypically from LA’s
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
19 Address
monthlyCurrency of postcodes,
Postcodes are part of RoyalMail’s referencing system foraddresses and can be subjectto change and reuse (seeAppendix K for discussion onPostcodes).
Holds a UPRN for each property thisdoes not change.
Monthly updates of data
BS7666 Merits
Merit PAF ApproachData StructureStructured format developed forexchange of data,
e-GIF compliant
Proprietary data files issued
Unlimited scope of addresses i.e.addresses within homes of multipleoccupancy,
Identifies all addresses with orwithout delivery points andnon addressable objects.
Only contains addresses for deliverypoints, not households. A record ofthe number of households for amultiple occupancy property isavailable and this is becomingincreasingly important, but is currentlydifficult to populate with any degree ofaccuracy. (see Appendix L fordiscussion on multiple occupancy)
Unique Property Reference Number,Identifier for each property tofacilitate cross referencing inother systems.
Postcode and delivery point suffix
Data Population and MaintenanceStatic property referencing,
Business rules for NLPG donot allow reuse of UPRN.
Royal Mail referencing system basedon delivery of mail and liable tochange as properties are built ordemolished.
Data closely linked to planning andtaxation processes,
Incentive to keep data currentand correct.
Ad Hoc updates to NLPG availableimmediately online
Recommendations and discussion
National address register
2.1.80 It is widely recognised that for e-Government to be successful and for projectssuch as CIP and NIR to succeed it is necessary to have a single high qualityNational Address Register (i.e. with high quality formatting, currency, coverageand validation). As described above there are merits to both standards and so
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
20 Gender
far the national debate regarding these has not been conclusive and so far noconsensus has been reachedvii. It is hoped hat the National Spatial AddressInfrastructure initiative will resolve this.
Short Term Recommendation:
2.1.81 In order to facilitate data sharing it is highly desirable to encourage the use ofBS 7666 compliant address data across the public sector or to adopt the use ofthe UPRN within stakeholder systems.
Long Term Recommendation:
2.1.82 The National Spatial Address Infrastructure will be an important part of any longterm recommendations but at the moment this is in the very early stages ofdevelopment so it is not possible to see precisely how this could be utilised.However, it is clear that the NSAI will utilise the Unique Property ReferenceNumber (UPRN) as an important identifier and this is consistent with CIPobjectives.
4.3 Gender
Relevant standards
• Government Data Standard
• BS 8766 Names and identifiers of individuals and groups
Differences between standards
2.1.83 BS 8766 holds less data than GDS.
Merits of standards
2.1.84 GDS distinguishes deliberate ambiguity of ‘unknown’ information and ‘notspecified’ information as well as current information from that recorded atregistration. Whereas BS 8766 only requires current gender and does not allowan ambiguous response.
Usage
2.1.85 The full scale adoption of the GDS is hampered by the lack of detailed data inexisting data sets as the GDS requires slightly more data than may have beencollected historically by stakeholders (e.g. Is gender recorded by a stakeholdersystem the one at registration or is it the current gender?). Also for certainstakeholders it is possibly unnecessary and undesirable to hold all theelements.
Recommendations and discussion
2.1.86 Despite the minor difficulties described above the approach outlined by the GDSis recommended. With time the data held will be cleansed and become more
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
21 Date of Birth
detailed. It would be necessary for any central system to hold all elements ofgender as different stakeholders may require different elements. Thereforesome business rules may need to be developed around the visibility of thisinformation as it may not be felt appropriate for certain elements to be visible toall. Also some metadata about the age of ‘Current Gender’ will be neededwhere data is shared this could result in one stakeholder updating the gender inanother’s system (see Section 5).
Short term recommendation:
2.1.87 Continue to encourage stakeholders to update and reference information inaccordance with the GDS. For example this may require clarification of whenGender was recorded and typically this will have been at time of registration.
Long term recommendation:
2.1.88 Develop fully GDS compliant set of elements for citizens and appropriate rulesaround the data definition.
4.4 Date of Birth
Relevant standards
• Government Data Standard
• BS 8766 Names and identifiers of individuals and groups
Differences between standards
2.1.89 There are no significant differences between the two standards.
Merits of standards
2.1.90 Both require the date to be held in ISO 8601 format (YYYYMMDD or YYYY-MM-DD).
Usage
2.1.91 Dates of birth are widely held across stakeholder systems and whilst they maynot all be in the proposed format this can be derived for the data held.
Recommendations and discussion
2.1.92 Difficulties arise with Dates of Birth (DoB) when the precise date is not knownby the citizen and there is no available verification for the date. Current practiceis to assume a date (say 1st January) in the year of birth, possibly alsoestimated. From the individual stakeholder’s perspective this is adequate as itbecomes the citizens ‘officially recorded’ date of birth, however difficulties arisebecause the assumed date is not consistent across departments. So the citizenhas two or more ‘officially recorded’ dates of birth this leads to problems
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
22 Place of Birth
matching data and could also present problems for the citizen where data ofbirth is used to verify identity.
Short Term Recommendation:
2.1.93 In order for data sharing to be successful a more joined up approach needs tobe given to the use of estimated dates of birth. Where there are legitimatebusiness reasons why different dates are advantageous the use of metadata(see section 5) might be considered. The data trial has provided some analysisof stakeholder data around this issue and further details can be found in Annex2
Long Term Recommendation:
2.1.94 Within a population register there should be scope for inputting estimated datesof birth and that metadata should identify those where DoB has been estimated.See Section 4 for further details regarding Metadata.
4.5 Place of Birth
Relevant standards (refer to Appendix I for comparison)
• Government Data Standard
• BS 8766 Names and identifiers of individuals and groups
Differences between standards
2.1.95 The Government Data Standard asks for the ‘town’ of birth and whereas theBritish Standard only requests the ‘place’. The GDS also gives some guidanceon the precision of the data provided to ensure that places sharing names canbe accurately identified, e.g. Bangor could be Wales or Northern Ireland.
Merits of standards
2.1.96 Both systems record the place of birth to distinguish between two people withthe same name born on the same day.
Usage
2.1.97 Stakeholders only store it where there is a business need hence it is not widelyheld across departments and where it is held it may also be optional. Its benefitin determining uniqueness of identity is only relevant until one or more uniqueidentifiers is adopted..
Recommendations and discussion
2.1.98 Place of birth is a useful identifier for uniqueness when combined with otherattributes, but is not the ideal method. It does however also provide a simplemethod for low level confirmation of identity. However the place should be:
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
23 Date of Death
• Large enough to be identifiable
• Not too large to be meaningless (London)
• Specific (Bangor, Gwynedd or Bangor, Co Down)
2.1.99 It should be precise enough to reasonably be expected to distinguish twopeople with the same name and date of birth, without further geographicalinformation being required.
Recommendation:
2.1.100 In the short/medium term Place of Birth, where captured, is useful data forresolving ambiguous matching in data sharing initiatives and initial integration ofNIR data with stakeholder data. In the longer term the usefulness of thisinformation will diminish as consistent and comprehensive unique identifiers,such as NINO, NIRNO and the NHS number, are adopted and integrated.
4.6 Date of Death
Relevant standards
2.1.101 Government Data Standard
Differences between standards
2.1.102 Only GDS stores Date of Death.
Merits of standards
2.1.103 The date is held in ISO 8601 format (YYYYMMDD or YYYY-MM-DD.
Usage
2.1.104 Dates of death are generally only held where there is a business need for thedate.
Recommendations and discussion
2.1.105 This is an area where joining up services can have a significant benefit to thecitizen as the administrative burden of dealing with the death of a relative canbe distressing and time consuming. It can also be distressing to receivecorrespondence for a deceased relative after their death has been registered.However, there are a number of administrative stages before someone can beissued with a Death Certificate (BD8) these are described in the verificationmethodology of the GDS. Stakeholders might also have different requirementsfor notification of a death
Recommendation:
2.1.106 A common approach to verification standards are necessary to ensure that datacan be shared successfully.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
24 Date of Death
i From http://www.govtalk.gov.uk/schemasstandards/schemasstandards.aspii http://www.govtalk.gov.uk/gdsc/html/frames/default.htmiii BS7666 Part 3 Forward page iiiv http://www.upu.int/index.htmlv see http://www2.btwebworld.com/btdirectorysolutions/docs/userguid.docvi Election Mark-up Language OASIS (EML) v3 see http://www.oasis-open.org/committees/election/
vii Acacia
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
25 Date of Death
5 Metadata standards
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
26 Date of Death
Metadata
2.1.107 Metadata is ‘data about data’ or ‘structured information about a resource’, forexample British Standard 8766 stores the Start Date for a ‘Name’ (see Section3.1). Although the distinction between data and metadata is not always clear,‘Start Date’ can be described as metadata as it describes when all elements ofthe name item became valid.
2.1.108 The e-Government Metadata Standard (e-GMS) identifies a number of reasonswhy metadata is important to e-Government and CIP’s short term and long termaims these include;
• Joining-up systems.
• Standardising government information systems.
• Facilitating new systems for the handling of electronic records.
• Facilitating searches and filtering records.
• Structured and consistent data across organisations.
2.1.109 Metadata is particularly important when considering the exchange of data. Itcan be used to describe many attributes of the data that will be of considerablebenefit to both the data recipient when integrating it in to their own data set andto the data provider in understanding and describing the state of their own data.It is also useful to the data user as it helps them maintain the data set. In thecontext of basic personal contact data there are three questions that are usefulto answer when considering integrating the data to another system andensuring that it is correctly maintained.
• Where did the data originate from?
• What is the age of the data?
• What is the already known about the quality of the data?
2.1.110 Considering each of these questions we can describe them by the followingattributes;
• Provenance
• Event Data
• Quality Characteristics
2.1.111 The following section describes the requirements of metadata for theseattributes and the benefits to the following groups;
• Data recipients
• Data providers
• Data users
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
27 Provenance
5.1 Provenance
Definition
• Provenance defines the original organisation that collected the data. Itenables an audit trail for the data, in a truly joined up environment. This isparticularly important where extensive data sharing takes place. It is alsoimportant in this context for data providers to hold details of who they havesupplied data to.
2.1.112 Provenance is distinct from Verification (Appendix A) Verification is the externalproof, generally provided by a citizen, to support the data. Where asProvenance is the original supplier of the data. Whilst this external proof mayhave come from a holder of data (for example, a birth certificate comes from theGRO who could also supply Birth Data) these are two are different and servedifferent purposes, for example;
• A person may provide an unverified Date of birth to the NHS – henceprovenance is the NHS and there is no verification. Alternatively they mightsupport a passport application with a birth certificate – when the provenanceis UKPS and the verification is the birth certificate, GRO do not haveprovenance unless the data was directly transferred from their system.
2.1.113 Hence, the combination of Provenance and Verification provides a completepicture of where the data came from and how it was verified.
Benefits
Data Recipient Data Provider Data User
Audit trail for externallysupplied data
Feedback on quality ofdata
Audit trail for externallysupplied data
5.2 Event data
Definition
• Event data is defined as details abut the age and life span of the data.
2.1.114 Many existing systems already store this data e.g. Inland Revenue NIRS2 has astart date and an end date for data.
2.1.115 The dates that are possibly useful are
• Date data was first entered into the system,
• Date data becomes no longer valid or expires,
• Date data was updated or reconfirmed.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
28 Quality characteristics
2.1.116 To simplify the storage of these dates and to ease maintenance these can bestored as;
• Start Date,
• End Date,
• Last updated.
2.1.117 This enables users to record the date that data was entered as the Start Date.The End Date allows historic data to be stored and identified and temporaryinformation to be recorded. Last updated allows minor changes to data andreconfirmation of data (i.e. ‘Do you still live at…..?’) to be dated.
Benefits Table
Data Recipient Data Provider Data User
Age of data isapparent.
Issuing of historic orexpired data can beminimised.
Age of data isapparent.
Expiry Date of data isapparent.
Date of expiry of datais apparent.
Receipt of historic orexpired data isoptional.
Reduced maintenance
• Temporary data,such as address, canbe flagged.
• Historic data can beheld withoutadditional attributes.
Comparison ofcurrency between datasets.
5.3 Quality characteristics
2.1.118 Annex 3 ‘Current Stakeholder processes, systems and data’ describes andexplains a recommended set of Quality Characteristics for a data set and itproposed that these be used to define the metadata to describe data quality.For this Quality Metadata to be useful some of it needs to be applied at eitherrecord level or item level (for example the overall currency of a data set is of nouse when identifying which record is most current). However, not all QualityIndicators are appropriate at record level. The following table shows howmetadata could be applied to describe quality
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
29 Quality characteristics
Quality CharacteristicsDataAttribute
Level forMetadata Degree of
duplicationScope ofDataset
Currency Internalconsistency
Coverage Completeness Formatting Validity Verification
Data Set ü ü
Data Item ü ü ü ü
UPRN
Data Attribute ü
Data Set ü ü
Data Item ü ü ü ü üName
Data Attribute ü
Data Set ü ü
Data Item ü ü ü ü ü üAddress
Data Attribute ü
Data Set ü ü
Data Item ü üGender
Data Attribute ü
Data Set ü ü
Data Item ü ü ü ü üDate ofBirth
Data Attribute ü
Data Set ü ü
Data Item ü ü üPlace ofBirth
Data Attribute
Data Set ü üDate ofDeath Data Item ü ü ü ü ü
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
30 Quality characteristics
Quality CharacteristicsDataAttribute
Level forMetadata Degree of
duplicationScope ofDataset
Currency Internalconsistency
Coverage Completeness Formatting Validity Verification
Level forMetadata
Data Attribute ü
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
31
Dataset Scope
Definition
• What is the defined population for the dataset? i.e. drivers with UK drivinglicence
2.1.119 This gives a level of quality as gives indication of both the churn and purpose ofthe data. Knowing that the record comes from a data set covering those in fulltime education gives the data user the chance to make a judgement about thesuitability of the data to their application.
Coverage
Definition
• How many records in the dataset have this attribute?
2.1.120 This gives a level of quality as gives the completeness of the data set for eachattribute, for example 85% of records hold an address.
Currency
Definition
• An indication of the time since the details were last updated
2.1.121 This is a very important when considering data sharing as the most current datais often a key requirement. It is expressed as the probability of a data itembeing current (i.e. true in the real world). For example, there is a 65%probability of any address in the dataset being associated with the currentoccupant.
Completeness
Definition
• Are there missing elements in the data item? i.e. are all the elements of theaddress complete.
2.1.122 Metadata could be used to allow estimated or incomplete data to be identified ata data item or record level.
Formatting
Definition
• What format is the data held in?
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
32
2.1.123 Providing business rules are defined and applied this can be applied at dataattribute level to describe the format of the data.
Internal Consistency
Definition
• Consistency is intended to identify data items where elements within the itemdon’t match (i.e. street does not match the Postcode).
2.1.124 If addresses are validated against a recognised register such as the PAF orNational Spatial Address Infrastructure (NSAI) they can be assumed to beconsistent.
Verification
Definition
• Demonstration that the data is what it is being claimed to be (i.e. that theperson purporting to have a particular birth day actually has this recorded).viii
2.1.125 As described in the section on Provenance this is an important item of metadatathat needs to be applied at item level. It describes how that particular data itemwas demonstrated (i.e. how did this citizen demonstrate that 23 March 1978was their birthday?). There are a number of standards describing methods ofverification as outlined in the section on Metadata Standards above.
Validity
Definition
• Demonstration that the claimed data exists (i.e. that a particular addressexists) or that the data correctly conforms to a set of rules or an agreed list ofvalid items (i.e. a date is a valid day in the year).ix
2.1.126 Validity is also an important aspect to the quality of data and it applies at thedata item level. Invalid data is generally prevented from being entered on to asystem by routines developed to comply with business rules. However, it maybe that business rules vary across systems and in data sharing invalid data mayappear. Often this can be cleansed in the importing routines (i.e. removinginvalid characters from a string of text). This can present problems whereintelligence is required to cleanse the data. Hence, another solution to thiswould be to allow the invalid data onto the system but flag it by using metadataand then correct it.
Comparison of e-GMS with requirements of CIP
2.1.127 Having identified the requirements for the metadata it is possible to investigatethe e-GMS to see which elements fit most closely. The e-GMS is meant as anoverall standard and it is possible to consider creating a ‘local standard’
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
33
consisting of a cut-down version of the e-GMS, with only the elementsconsidered useful for the CIP short term and long term objectives.
2.1.128 The following table suggests how the local standard based on e-GMS may bedeveloped; elements and refinements are shown in bold. Elements andrefinements not currently included in e-GMS are shown in italics:
.
viii Refer to Section 1.5 Terminology of HMG’s Minimum Requirements for the Verification ofthe Identity of Individuals for further definition.ix See Appendix Date Validation.
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
34 Quality characteristics
CIP Metadata Requirement e-GMS Element Refinements Notes Example
Provenance Creator
An entity primarily responsiblefor making the content of theresource
None Creator is preferredover Publisher as thedata has been collatedbut it is not ‘published’.Contributor may haveplayed an importantrole but did not haveprimary or overallresponsibility for thecontent.
creator =
“The Department of Workand Pensions”
Event Data Date e-GMS suggests a numberof suitable refinementswhich describe theinformation required byCIP ;
Start Date Date submitted
Date of submission of theresource
Date.date submitted =
“2005-02-21”
End Date End
Date on which theresource was supersededor is due to besuperseded.
Date.end =
“1998-03-12”
Lastupdateddate
Modified
Date on which theresource was changed
Date.modified =
”2003-04-30”
CIP Metadata Requirement e-GMS Element Refinements Notes Example
Quality Characteristics
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
35 Quality characteristics
CIP Metadata Requirement e-GMS Element Refinements Notes Example
DatasetScope
Coverage
The extent or scope of thecontent of the resource.
Population
i.e. the range of peoplecovered by the data
The existing spatial(geographic),temporal(time)refinements are notsuitable here, suggest a‘population’ refinement
coverage.population =“UK adults over 16”
Coverage Coverage
The extent or scope of thecontent of the resource.
Data
i.e. the proportion ofrecords with data for thisattribute.
coverage.data =
“95%”
Currency Currency
A new element is suggestedto cover currency
Probability
Probability of data beingcurrent is suggested as arefinement of currency toallow other definitions tobe included if necessary.
Currency.probability =
“78%”
Completeness Status
The position or state of theresource.
none status =
“postcode missing”
Formatting Relation
A reference to a relatedresource.
Conforms to
A reference to anestablished standard towhich the resourceconforms.
Relation.conforms to =
“BS 7666 - 3 2000”
InternalConsistency
Consistency
Data in this element isconsistent
none Suggested threeoptions
“True”
“False”
“Not known”
Consistency =
“True”
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
36 Quality characteristics
CIP Metadata Requirement e-GMS Element Refinements Notes Example
Verification Mandate
Legislative or other mandateunder which the resource wasproduced
Verification
This refinement issuggested to maintainclarity.
Mandate.verification =
“Birth Certificate supplied”
Validity Mandate
Legislative or other mandateunder which the resource wasproduced
Validation
This refinement issuggested to maintainclarity
Mandate.validation =
“Address validated usingQAS”
2.1.129 Note this table does not include certain elements that e-GMS considers necessary, these are described below;
Mandatoryelements
Mandatory if applicable Recommended
Creator Covered above Accessibility N/A Coverage Covered above
Date Suggest this will be a date when the wholedataset was issued
Identifier N/A Language Issuing Department ruleswill apply.
Subject.category Issuing Department rules will apply. Publisher N/A
Title Issuing Department rules will apply.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
37 Appendices
5.4 Recommendations
Short term
2.1.130 CIP have proposed a number of data sharing proposals for governmentorganisations to consider and implement. We recommend that the proposedmetadata schema be adopted progressively.
2.1.131 During this period CIP will encourage the sharing of data between variousstakeholders, so for example UKPS may take address data from DVLA i.e.UKPS in this instance will act as a Data Provider to DVLA the Data Recipientand eventually Data User. In this case the stakeholders systems may not holdall the metadata described below. But by identifying a standard for metadata itprovides a benchmark set for interactions between stakeholders.
Long Term
2.1.132 In the long term it is proposed that the NIR will become the Data Provider to agroup of stakeholders and we proposes that ID Cards adopt these proposals toenable stakeholders to maximise the benefit of obtaining data from NIR.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
38 Appendices
6 Data sharing standards
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
39 Appendices
2.1.133 As described in Section 2 e-GIF provides details for the exchange of data, andthat this defines XML as the format for Data Integration. In the long term asolution based on these standards can be built from the ground up. However, inthe short term data may be exchanged between one legacy system andanother. This needs to be both secure and interoperable. Detailedunderstanding of the various stakeholder systems is needed to fully describehow data sharing will ultimately take place. It will, however, be necessary forthe data provider to prepare the data for sharing and for the data user to checkand then accept the data into their system. This process will need to be carriedout irrespective of the method used to transfer the data.
• Preparation of data; Data will need to be extracted from the data providerssystem in a structure that is understood by the data recipient. The extent ofwork carried out by the provider should be minimised and the interpretationof data and application of business rules must be carried out by the recipient.It is important that data is not made to appear higher quality during thisprocess than it originally was.
• Transfer via agreed method.
• Checking; Data received should be subject to checking by the recipient. Thiscould be a quality assurance check to ensure that all the elements requestedhave been received and are in the agreed format or a more detailedverification check
• Accepted and integrated into recipient system.
2.1.134 We recommend that ID Cards develop more detailed solutions using e-GIF/XMLto facilitate exchange of basic citizen details between NIR and accreditedstakeholders.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
40 Appendices
Appendices
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
41 Appendices
A. Verification
1. ‘HMG's Minimum Requirements for the Verification of the Identity of Individuals’e-Government Strategy Framework Policy and Guidelines Version 2.0 defines‘verify’ thus:
• Verify – demonstrate that the registrant is whom they claim to be (i.e. that theperson purporting to hold these attributes is not impersonating the actual owner of theidentity).
2. It also provides levels of verification these are similar to the categories used inthe Quality Questionnaire as rather than defining documents they defineprobability.
• a) Level One – on the balance of probabilities, the registrant’s real worldidentity is verified. An example of a transaction that might merit level 1 registration is theon-line ordering of a publication using a credit card, delivery of which is being made tothe credit card account holder’s address. In this case failure of the registration process islikely to cause only inconvenience to the real world identity.
• b) Level Two – there is substantial assurance that the registrant’s real worldidentity is verified. An example of a transaction that might merit level 2 registration is thesubmission of a VAT return. There must be substantial assurance of real-world identitysince the return is legally binding.
3. c) Level Three – the registrant’s real world identity is verified beyond reasonabledoubt. An example of a transaction that might require level 3 registration is theon-line application for a passport.
4. The methods for verification used by the Quality Question are given in thefollowing appendices.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
42 Appendices
B. Name verification
1. The following verification was used for the Quality Questionnaire and is basedon the eGIF standard for Date of Birth Verification, further details can be foundat http://www.govtalk.gov.uk/gdsc/html/frames/PersonBirthDate-2-0-Release.htm.
Name Verification Category 0: Not Verified
Category 1: One or more of the following Secondary certificates:
Marriage CertificateNational Health Service Medical CardChild's Certificate of VaccinationChild's Health Record CardA certificate of Service in HM Forces or other employment under the Crown or in the MercantileMarine.A certificate of membership of a Trade Union Friendly Society or any cards or papers relating tomembership of an Approved Society or Unemployment Insurance Apprenticeship indentures.Early certificate or testimonial from employer. Aliens registration card, certificate of naturalisation, Home Office travel document or a passport.Life insurance policy.Certificate of confirmation.*Testimonial from employer. *Obtained from other Public Sector System (without record of higher Category validation)*Utility Bills
Category 2: One of the following:
Full Birth certificate.Birth certificate short form.Certificate of registry showing given names and family name.GRO copy.Adoption Order issued by the High Court, County Court or Juvenile Court.Certificate of adoption issued by the GRO.*Driving Licence*Passport*Deed Poll authorisation*Obtained from other Public Sector System (with record of high Category validation)Foreign birth certificate issued by registration authority of the foreign country
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
43 Appendices
C. Address verification
1. The following verification was used for the Quality Questionnaire and is basedon the eGIF standard for Date of Birth Verification, further details can be foundat http://www.govtalk.gov.uk/gdsc/html/frames/PersonBirthDate-2-0-Release.htm. Additional items have been included to provide to allowverification against documents issued during later stages in life (these arehighlighted with an asterisk *).
Address Verification Category 0: Not Verified
Category 1: One or more of the following: Testimonial from employer.*Utility Bills *Obtained from other Public Sector System (without record of higher Category validation)
Category 2: One of the following:
*Bank Statement*Credit Card Statements*Driving Licence*Obtained from other Public Sector System (with record of higher Category validation)
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
44 Appendices
D. Date of Birth verification
1. The following verification was used for the Quality Questionnaire and is basedon the eGIF standard, further details can be found athttp://www.govtalk.gov.uk/gdsc/html/frames/PersonBirthDate-2-0-Release.htm.This can also be used to validate Place of Birth where these details are alsorecorded on one of the following certificates.
Date of Birth Verification Category 0: Not Verified Category 1: One or more of the following Secondary certificates:
Certificate of Baptism.Marriage CertificateNational Health Service Medical CardChild's Certificate of VaccinationChild's Health Record CardA certificate of Service in HM Forces or other employment under the Crown or in the MercantileMarine.A certificate of membership of a Trade Union Friendly Society or any cards or papers relating tomembership of an Approved Society or Unemployment Insurance Apprenticeship indentures.Early certificate or testimonial from employer.Aliens registration card, certificate of naturalisation, Home Office travel document or a passport.Life insurance policy.Certificate of confirmation.School certificate or report.A birthday book or old family record.Family Bible containing a record of birth.*Obtained from other Public Sector System (without record of high Category validation) Category 2: One of the following:
Full birth certificate.Birth certificate short form.Certificate of registry showing given names and family name.GRO copy.Adoption Order issued by the High Court, County Court or Juvenile Court.Certificate of adoption issued by the GRO.Foreign birth certificate issued by registration authority of the foreign country*Obtained from other Public Sector System (with record of high Category validation)
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
45 Appendices
E. Date of Death verification
1. The following verification was used for the Quality Questionnaire and is basedon the eGIF standard, further details can be found athttp://www.govtalk.gov.uk/gdsc/html/frames/PersonDeathDate-2-0-Release.htm.
Date of Death Validation Category 0: - Not Verified / Interim Death certificate. Category 1- One of the following:
Notification from HospitalPolice Statement*Obtained from other Public Sector System (without record of high Category validation) Category 2 - One of the following:
Documented Coroners VerdictPresumption of death by a court of Law in England, Scotland or Wales. Category 3 - One of the following:
Death Certificate BD8Notification from General Registrars Office (system or clerical).Certificate of Registry showing given names and family name.GRO copy.Notification of death issued by Forces Department of the Ministry of Defence (MOD).Notification of death issued by the Registrar General of the Shipping and Seamen (MercantileMarine).*Obtained from other Public Sector System (with record of high Category validation)
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
46 Appendices
F. Validation Standards
1. ‘HMG's Minimum Requirements for the Verification of the Identity of Individuals’e-Government Strategy Framework Policy and Guidelines Version 2.0 defines‘validate’ thus:
• Validate – demonstrate that a claimed identity exists (i.e. that a person, who hascertain attributes, exists);
2. The following appendix explains the methods for validating a Date.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
47 Appendices
G. Date validation
1. The following validation was used by the Quality Questionnaire and is based onDWP rules for Date Validation.
Date Validity rulesDate must be today's date or earlier.Date must not be earlier than 29/02/1852Date of Death must not be earlier than date of birthDays must not be greater than 29 in February29 February is not valid except in a leap yearDays must not be greater than 30 in April, June, September or NovemberFirst 4 numerics in range 1852-2099, next 2 numerics in range 01-12, final 2 numerics in range01-31.
2. The following validation is used by the Government Data Standards CatalogueBased on XML Schema Part 2: Datatypes W3C Recommendation 02 May 2001.
Validations 1. Values less than 10 in the day, month or year elements, should beentered with a zero in the first position.
2. Days must not be greater than 30 in April, June, September andNovember.
3. Days must not be greater than 28 in February except when 29 isallowed for a leap year.
Values CCYY should be a valid year number.
MM in Range 01-12.
DD in Range 01-31.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
48 Appendices
H. Comparison of Name and Address standards
1. Comparison of The Government Data Standard for address and personal detailswith ‘BS8766 2004 Names and identifiers of individuals and groups — Datastructure for interoperability — Specification’
GDS ‘Address Personal DetailsSchema’ Data Elements
BS 8766 Data Elements
AddressBS7666 Address Basic Land and Property UnitPost CodePrimary Addressable Object NameSecondary Addressable Object NameStreet Descriptive Identifier Structure Administrative AreaLocalityStreet DescriptorTownUnique Property Reference NumberUnique Street Reference NumberCountry CodeInternational AddressUK Postal AddressUK Internal CodeUK Local Authority Code
AddressCls 4.1.3Optional attribute of PERSON objectclassClass ADDRESS is a structuredaddress confirming to recognisedstandard BS7666 or PAF
Contact InformationInternet e-Mail AddressUK Telephone NumberUniform Resource Locator (URL)
None
FinancialAmountAmount SterlingCurrency TypeDun's NumberPercentageUK Government Financial YearUK Tax Year
None
IdentifiersFinancial Identifiers
UK Bank Account NameUK Bank Account Number
None
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
49 Appendices
UK Bank Branch Sort CodeUK Building Society Account NumberUK Cheque Number
Person IdentifiersDriver NumberNational Insurance NumberNHS NumberPassport Number (New)Passport Number (Old)Unique Pupil NumberUnique Tax Reference Number
PersonIDCls. 3.5Object class PERSONIDExternal Identifier of the Person e.g.NINo
Technical IdentifiersGlobally Unique Identifier -GUID None
Organisation InformationCompanies House Reference NumberOrganisation NameStandardised Industrial ClassificationNumberValue Added Tax Number
Concept of GROUP set of peopleidentifiable by some criteria (family,household, company or club)
OtherDWP Service Code N/APerson InformationPerson Birth Date DateOfBirth
Cls 4.1.3Optional attribute of PERSON objectclassAttribute with comparable formatting
None Place of BirthCls 4.1.3Optional attribute of PERSON objectclass
Person Death Date NonePerson Marital Status NonePerson NamePerson Family NamePerson Full NamePerson Given NamePerson InitialsPerson Name Suffix
PersonNameCls 4.1.2Mandatory attribute of PERSONobject class.
Person Requested Name nonePerson Title Title
Cls 4.1.2Mandatory attribute of PERSONobject class.
Person Place of Birth NonePerson Sex Person Gender at Registration Gender
Cls 4.1.3Optional attribute of PERSON objectclassAttribute does not have comparableoptions
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
50 Appendices
Person Gender CurrentRelationshipsPerson Relationship Type Member of GroupTemporalDateDuration HoursPeriodicity TypePreferred Contact TimeTime
NoneBut Start and End Date s exist forName and Identifier.
BS8766 Example
Table C.1 — PersonAttribute Value
Person name Person name type registered
Title Dr
Initials J
Family name Smith
Given name John Bernard
Suffix MD
Language English
Start date 1923-09-17
End date —
Person ID Identifier LZ806502N
Person ID descriptor National Insurance Number
Start date 1924-04-17
End date —
Address Primary addressable objectname
23
Street name Acacia Avenue
Locality name Gladesville
Town name Sunbury
Administrative area name Borsetshire
Postcode SN2 8GK
Place of Birth Bognor Regis
Date of Birth 1923-09-17
Gender M
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
51 Appendices
I. Conversion of BS7666 addresses to postaladdresses
1. The following charts have been reproduced from a report ‘Local Land andProperty Gazetteer Data Entry Conventions’ NLPG Technical Working Partypublished 2001 (www.nlpg.org.uk/_public/download/dataentryv4.doc)
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
52 Appendices
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
53 Appendices
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
54 Appendices
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
55 Appendices
J. List of local authorities and their NLPG status
1. The following schedules show the various levels of usage of BS7666 Pt3compliant Property Gazetteers via the NLPG. Figure were correct at 28 April2005.
The following 223 councils (55%) in England, Scotland and Wales are ‘Linked andMaintaining’ data in NLPG – Status 1
Authority Name RCG Area Authority Name RCG Area
Bath and North EastSomerset Council South West Norwich CC East of EnglandBristol CC South West South Norfolk DC East of EnglandSouth GloucestershireCouncil South West Hambleton DC YorkshireMid Bedfordshire DC East of England Harrogate BC YorkshireSouth Bedfordshire DC East of England Ryedale DC YorkshireLuton BC East of England Scarborough BC YorkshireBracknell Forest BC South East Selby DC YorkshireWest Berkshire DC South East York CC YorkshireReading BC South East Corby BC East MidlandsSlough BC South East Daventry DC East Midlands
Wokingham DC South East
EastNorthamptonshireCouncil East Midlands
Aylesbury Vale DC South East Kettering BC East MidlandsSouth Buckinghamshire DC South East Northampton BC East MidlandsChiltern DC South East Alnwick DC North EastWycombe DC South East Castle Morpeth BC North EastMilton Keynes BC East Midlands Tynedale DC North EastCambridge CC East of England Ashfield DC East MidlandsEast Cambridgeshire DC East of England Bassetlaw DC East MidlandsFenland DC East of England Broxtowe BC East MidlandsHuntingdonshire DC East of England Gedling BC East Midlands
South Cambridgeshire DC East of EnglandNewark andSherwood DC East Midlands
Peterborough CC East of England Rushcliffe BC East MidlandsCongleton BC North West Nottingham CC East MidlandsWarrington BC North West Cherwell DC South EastMiddlesbrough BC North East Oxford CC South EastStockton-on-Tees BC North East West Oxfordshire DC South EastCaradon DC South West Bridgnorth DC West MidlandsCarrick DC South West Oswestry BC West Midlands
North Cornwall DC South WestShrewsbury andAtcham BC West Midlands
Borough of RestormelCouncil South West
Telford and WrekinCouncil West Midlands
Allerdale BC North West Mendip DC South WestBarrow-in-Furness BC North West Taunton Deane BC South West
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
56 Appendices
Carlisle CC North West South Somerset DC South WestCopeland BC North West Cannock Chase DC West MidlandsEden DC North West East Staffordshire DC West MidlandsAmber Valley BC East Midlands Lichfield DC West Midlands
Bolsover DC East MidlandsNewcastle-under-Lyme BC West Midlands
Chesterfield BC East Midlands Stafford BC West Midlands
Erewash BC East MidlandsSouth StaffordshireDC West Midlands
High Peak BC East MidlandsStaffordshireMoorlands DC West Midlands
South Derbyshire DC East Midlands Tamworth BC West MidlandsDerby CC East Midlands Stoke-on-Trent CC West MidlandsEast Devon DC South West Forest Heath DC East of EnglandSouth Hams DC South West Ipswich BC East of EnglandTorridge DC South West St Edmundsbury BC East of EnglandWest Devon BC South West Suffolk Coastal DC East of EnglandPlymouth CC South West Epsom and Ewell BC South EastTorbay BC South West Guildford BC South EastPurbeck DC South West Mole Valley DC South EastWest Dorset DC South West Runnymede BC South EastWeymouth and Portland BC South West Spelthorne BC South EastPoole BC South West Surrey Heath BC South EastChester-le-Street DC North East Tandridge DC South EastDurham CC North East Woking BC South East
Sedgefield BC North EastNorth WarwickshireBC West Midlands
Wear Valley DC North EastNuneaton andBedworth BC West Midlands
Darlington BC Yorkshire Warwick DC West MidlandsEastbourne BC South East Adur DC South EastHastings BC South East Arun DC South EastRother DC South East Chichester DC South EastChelmsford BC East of England Horsham DC South EastHarlow DC East of England Worthing BC South EastRochford DC East of England Kennet DC South WestUttlesford DC East of England West Wiltshire DC South WestCheltenham BC South West Swindon BC South West
Cotswold DC South WestBolton MetropolitanBC North West
Gloucester CC South WestOldham MetropolitanBC North West
Stroud DC South WestRochdaleMetropolitan BC North West
Basingstoke and Deane BC South EastCity of SalfordCouncil North West
East Hampshire DC South EastStockportMetropolitan BC North West
Eastleigh BC South EastTamesideMetropolitan BC North West
Gosport BC South EastWigan MetropolitanBC North West
Hart DC South EastKnowsleyMetropolitan BC North West
Rushmoor BC South East Liverpool CC North WestWinchester CC South East St Helens North West
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
57 Appendices
Metropolitan BC
Portsmouth CC South EastSefton MetropolitanBC North West
Southampton CC South EastWirral MetropolitanBC North West
Malvern Hills DC West MidlandsDoncasterMetropolitan BC Yorkshire
Redditch BC West MidlandsRotherhamMetropolitan BC Yorkshire
Worcester CC West Midlands Sheffield CC Yorkshire
Wyre Forest DC West MidlandsNorth TynesideCouncil North East
County of Herefordshire DC West MidlandsSouth TynesideMetropolitan BC North East
St Albans DC East of EnglandSandwellMetropolitan BC West Midlands
Three Rivers DC East of EnglandSolihull MetropolitanBC West Midlands
Watford BC East of EnglandWolverhamptonMetropolitan BC West Midlands
Welwyn Hatfield DC East of EnglandCity of BradfordMetropolitan DC Yorkshire
East Riding of YorkshireCouncil Yorkshire
Kirklees MetropolitanCouncil Yorkshire
North East Lincolnshire BC Yorkshire
London Borough ofBarking andDagenham Greater London
North Lincolnshire Council YorkshireLondon Borough ofBarnet Greater London
Ashford BC South EastLondon Borough ofBrent Greater London
Canterbury CC South EastLondon Borough ofCamden Greater London
Dartford BC South EastLondon Borough ofCroydon Greater London
Gravesham BC South EastLondon Borough ofEaling Greater London
Shepway DC South EastLondon Borough ofEnfield Greater London
Tonbridge and Malling BC South East
London Borough ofHammersmith andFulham Greater London
Tunbridge Wells BC South EastLondon Borough ofHaringey Greater London
Medway Council South EastLondon Borough ofHarrow Greater London
Chorley BC North WestLondon Borough ofHillingdon Greater London
Lancaster CC North WestLondon Borough ofHounslow Greater London
Blackpool BC North WestLondon Borough ofIslington Greater London
Blaby DC East Midlands
Royal Borough ofKensington andChelsea Greater London
Charnwood BC East Midlands
Royal Borough ofKingston-upon-Thames Greater London
Harborough DC East Midlands London Borough of Greater London
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
58 Appendices
Lambeth
Melton BC East Midlands
London Borough ofRichmond UponThames Greater London
North West LeicestershireDC East Midlands
London Borough ofSouthwark Greater London
Leicester CC East MidlandsLondon Borough ofSutton Greater London
Boston BC East MidlandsLondon Borough ofTower Hamlets Greater London
East Lindsey DC East MidlandsLondon Borough ofWandsworth Greater London
South Holland DC East MidlandsCardiff CountyCouncil Wales
South Kesteven DC East MidlandsDenbighshire CountyCouncil WalesPembrokeshireCounty Council WalesNeath and PortTalbot County BC WalesNewport CC Wales
NoteCC – City CouncilDC – District CouncilBC – Borough Council
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
59 Appendices
The following 106 councils (26%) in England, Scotland and Wales are ‘Linked but not yetmaintaining’ data in NLPG – Status 2
Authority Name RCG Area Authority NameRCGArea
Oadby and Wigston BC East Midlands North Somerset CouncilSouthWest
North Kesteven DC East Midlands Kerrier DCSouthWest
West Lindsey DC East Midlands North Devon DCSouthWest
South NorthamptonshireCouncil East Midlands Mid Devon DC
SouthWest
Wellingborough BC East Midlands Christchurch BCSouthWest
Bedford BC East of England East Dorset DCSouthWest
Braintree DC East of England Bournemouth BCSouthWest
Brentwood BC East of England Forest of Dean DCSouthWest
Castle Point BC East of England Tewkesbury BCSouthWest
Colchester BC East of England Sedgemoor DCSouthWest
Maldon DC East of England West Somerset DCSouthWest
Thurrock BC East of England Bromsgrove DCWestMidlands
Broxbourne BC East of England South Shropshire DCWestMidlands
Dacorum BC East of England Coventry CCWestMidlands
East Hertfordshire DC East of England Dudley Metropolitan BCWestMidlands
Stevenage BC East of England Walsall Metropolitan BCWestMidlands
Broadland DC East of England Kingston-Upon-Hull CC YorkshireGreat Yarmouth BC East of England Craven DC YorkshireBC of Kings Lynn and WestNorfolk East of England Richmondshire DC YorkshireBabergh DC East of England Barnsley Metropolitan BC YorkshireMid Suffolk DC East of England Calderdale Metropolitan BC YorkshireCorporation of London Greater London Leeds CC Yorkshire
London Borough of Bromley Greater LondonCity of Wakefield MetropolitanDC Yorkshire
London Borough ofGreenwich Greater London
Isle of Anglesey CountyCouncil Wales
London Borough of Hackney Greater London Cyngor Gwynedd Council WalesLondon Borough of Havering Greater London Ceredigion County Council Wales
London Borough of Lewisham Greater LondonCarmarthenshire CountyCouncil Wales
London Borough of Merton Greater LondonMonmouthshire CountyCouncil Wales
London Borough of Newham Greater London Powys County Council WalesLondon Borough of WalthamForest Greater London City and County of Swansea Wales
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
60 Appendices
Redcar and Cleveland BC North East Conwy County BC WalesDerwentside DC North East Bridgend County BC WalesNewcastle-upon-Tyne CC North East Caerphilly County BC Wales
City of Sunderland North EastRhondda Cynon Taff CountyBC Wales
Chester CC North West Vale of Glamorgan Council WalesEllesmere Port and NestonBC North West Wrexham County BC WalesMacclesfield BC North West Aberdeen CC ScotlandVale Royal BC North West Aberdeenshire Council ScotlandSouth Lakeland DC North West Argyll and Bute Council ScotlandHyndburn BC North West Clackmannanshire Council ScotlandPendle BC North West Dundee CC ScotlandSouth Ribble BC North West East Ayrshire Council ScotlandWyre BC North West The City of Edinburgh Council ScotlandBlackburn with Darwen BC North West Glasgow CC ScotlandBury Metropolitan BC North West Midlothian Council ScotlandTrafford Metropolitan BC North West Renfrewshire Council ScotlandLewes DC South East South Lanarkshire Council ScotlandBrighton and Hove Council South East Stirling Council ScotlandTest Valley BC South East West Lothian Council ScotlandIsle of Wight Council South EastMaidstone BC South EastSevenoaks DC South EastSwale BC South EastThanet DC South EastReigate and Banstead BC South EastWaverley BC South EastCrawley BC South East
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
61 Appendices
The following 61 councils (15%) in England, Scotland and Wales are engaged in ‘LLPGCreation’ – Status 3
Authority Name RCG Area Authority Name RCG Area
North East Derbyshire DC East MidlandsRoyal Borough ofWindsor and Maidenhead South East
Derbyshire Dales DC East Midlands Wealden DC South EastHinckley and Bosworth BC East Midlands Fareham BC South EastRutland County Council East Midlands New Forest DC South EastMansfield DC East Midlands Dover DC South EastBasildon DC East of England South Oxfordshire DC South EastEpping Forest DC East of England Vale of White Horse DC South EastTendring DC East of England Elmbridge BC South EastSouthend-on-Sea BC East of England Mid Sussex DC South EastHertsmere BC East of England Teignbridge DC South WestBreckland DC East of England North Dorset DC South WestNorth Norfolk DC East of England North Wiltshire DC South WestWaveney DC East of England Salisbury DC South WestLondon Borough of Bexley Greater London Wychavon DC West MidlandsWestminster CC Greater London North Shropshire DC West MidlandsHartlepool BC North East Rugby BC West MidlandsTeesdale DC North East Stratford-on-Avon DC West MidlandsBerwick-upon-Tweed BC North East Merthyr Tydfil County BC WalesBlyth Valley BC North East Orkney Islands Council ScotlandWansbeck DC North East Shetland Islands Council ScotlandGateshead Metropolitan BC North East Western Isles Council ScotlandCrewe and Nantwich BC North West Angus Council Scotland
Halton BC North WestWest DunbartonshireCouncil Scotland
Burnley BC North WestDumfries and GallowayCouncil Scotland
Preston CC North WestEast DunbartonshireCouncil Scotland
West Lancashire DC North West East Lothian Council Scotland
Manchester CC North WestEast RenfrewshireCouncil ScotlandFalkirk Council ScotlandFife Council ScotlandThe Highland Council ScotlandThe Moray Council ScotlandNorth Ayrshire Council ScotlandNorth LanarkshireCouncil ScotlandSouth Ayrshire Council Scotland
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
62 Appendices
The following 6 councils (1%) in England, Scotland and Wales have ‘LLPG Creationplanned within next quarter’ – Status 4
Authority Name RCG Area
Exeter CC South WestEasington DC North EastHavant BC South EastNorth Hertfordshire DC East of EnglandBirmingham CC West MidlandsPerth and Kinross Council Scotland
The following 11 councils (3%) in England, Scotland and Wales have made an‘Implementing Electronic Government (IEG) Commitment’ – Status 5
Authority Name RCG Area
Penwith DC South WestFylde BC North WestRibble Valley BC North WestRossendale BC North WestLincoln CC East MidlandsLondon Borough of Redbridge Greater LondonFlintshire County Council WalesBlaenau Gwent County BC WalesTorfaen County BC WalesScottish Borders Council ScotlandInverclyde Council Scotland
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
63 Appendices
K. New addresses and postcodes
New addressesThe numbering and naming of new streets is the responsibility of a Local Authority whowill work in consultation with Royal Mail to ensure the address is sufficiently unique andfollows agreed conventions for numbering etc. Royal Mail’s Address DevelopmentCentre allocates a post code to the address and it is identified as a new address butwhere no one is resident. New addresses are not made live on the Postal Address File(PAF) until Royal Mail have confirmed that the properties are complete and can receivemail. This information comes from a variety of sources, Royal Mail delivery staff, mailredirection requests, or by customers contacting Royal Mail directly via the PostcodeEnquiry Centre or Customer Service Centre.
PostcodesThe Postcode was introduced by the Royal Mail in 1959 and has become widely adoptedas the initial property identifier. There are two types of postcode a, large user Postcodeis where it is assigned to a single address due to the large volume of mail it receives, anda small user Postcode which identifies a group of delivery points. .On average there are15 delivery points per Postcode, however this can vary between 1 and 100. Eachdelivery point also has a Delivery Point Suffix to identify itself with the group, althoughthis is mainly used internally by Royal Mail.
Despite the widespread adoption of the Postcode it must be remembered that it is ownedand maintained by Royal Mail for the delivery of mail and that this leads to two significantdrawbacks to its use within a population register that must be noted.
Firstly it is liable to change over time. As new developments occur or delivery routeschange it becomes necessary for Royal Mail to change a postcode. The PAF Code ofPractice states the following;
“We are committed to a policy of not changing addresses or postcodes whereverpossible. We will only make changes to benefit the service we give to you, or when it isabsolutely necessary, for example:
1. a new Royal Mail delivery office is opened2. we have run out of postcodes for new homes and businesses in a developing
area3. the local council has prompted a change by re-numbering buildings or re-naming
roads”fromhttp://www.royalmail.com/portal/rm/content1?catId=400044&mediaId=9200078#3400060ftp://ftp.royalmail.com/Downloads/public/ctf/rm/Code_of_Practice.pdf
However, this means that the postcode cannot be guaranteed to be constant over time.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
64 Appendices
Postcode structureMax 8 characters.
Format Example PostcodeAN NAA M1 1AAANN NAA M60 1NWAAN NAA CR2 6XHAANN NAA DN55 1PTANA NAA W1A 1HQAANA NAA EC1A 1BB
Please note the following:-• The letters Q, V and X are not used in the first position.• The letters I, J and Z are not used in the second position.• The only letters to appear in the third position are A, B, C, D, E, F, G, H, J, K,S, T, U and W.• The only letters to appear in the fourth position are A, B, E, H, M, N, P, R, V,W, X and Y.• The second half of the Postcode is always consistent numeric, alpha, alphaformat and the letters C, I, K, M, O and V are never used.These conventions may change in the future if operationally required.*GIR 0AA is a Postcode that was issued historically and does not confirm tocurrent rules on valid Postcode formats``is however, still in use.Comments1. The Postcode is a combination of between five and seven letters / numbers whichdefine four different levels of geographic unit. It is part of a coding system created andused by the Royal Mail across the United Kingdom for the sorting of mail. The Postcodesare an abbreviated form of address which enable a group of delivery points (a deliverypoint being a property or a postbox) to be specifically identified. There are two types ofPostcode, these being large and small user Postcodes.
• A large user Postcode is one that has been assigned to a single address due tothe large volume of mail received at that address.
• A small user Postcode identifies a group of delivery points. On average there are15 delivery points per Postcode, however this can vary between 1 and 100.
Each Postcode consists of two parts. The first part is the Outward postcode, or Outcode.This is separated by a single space from the second part, which is the Inward Postcode,or Incode.The Outward Postcode enables mail to be sent to the correct local area fordelivery. This part of the code contains the area and the district to which the mail is to bedelivered.The Inward Postcode is used to sort the mail at the local area delivery office. Itconsists of a numeric character followed by two alphabetic characters. The numericcharacter identifies the sector within the postal district. The alphabetic characters thendefine one or more properties within the sector. The following characters are never usedin the inward part of the Postcode:C I K M OV.An example Postcode is PO1 3AX.• PO refers to the Postcode Area of Portsmouth.
• There are 124 Postcode Areas in the UK.• PO1 refers to a Postcode District within the Postcode Area of Portsmouth.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
65 Appendices
• There are approximately 2900 Postcode Districts in the UK.• PO1 3 refers to the Postcode Sector.
• There are approximately 9,650 Postcode Sectors in the UK.• The AX completes the Postcode.
• The last two letters define the ‘UnitPostcode’ which identifies one or more smalluser delivery points or an individual Large User.• There are approximately 1.71 million unit Postcodes in the UK.
Data from http://www.royalmail.com
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
66 Appendices
L. Discussion on multiple occupancy
The following reference material is based in information provided to the CIPProject Definition team and is intended here for completeness.
ObjectiveFor the coverage of a Population Register to be complete and to ensure that it has a lowincidence of duplication it is first necessary to correctly identify where people reside and whatis their specific address. For a number of the benefits identified it is necessary tounambiguously identify were a particular person lives (inclusion, statistical, planning, policy,social care, fraud etc).ScopeIn many cases identifying a place of residence can be done by identifying the building orelement of a building identified as a dwelling. The 2001 Census identified that 94.01% of allhousehold spaces were in accommodation that was either detached, semi-detached, terracedor flats which had been purpose-built. In the vast majority of these cases there will be a maildelivery point (or letter box) thus ensuring that the address of the dwelling is included on thePAF. Hence, the address is widely understood and can be validated.However, approximately 4.43% of household spaces were in shared or converted houses.The remainder were either part of a commercial building (1.15%) or temporary/mobilestructures (0.41%). Here it is unlikely that the dwelling or dwelling unit will have an individualmail delivery point and they are not identified as separate units on mail based addressregisters, such as PAF. These properties may still receive mail via a central delivery point(i.e. the letter box in the front door of a house divided into flats or a site address for a mobilehome site)Also within the 94.01% of purpose-built household spaces there maybe any number of hidden“households”, for examples lodgers (the 1996 English Household Condition Survey estimated253,000 lodgers in England and they may live in any type of accommodation)Required OutcomeIn order to reach the objective a Population Register needs to identify the lowest level ofaccommodation that can be uniquely referenced. This could relate to "dwelling units"identified by separate tenancy agreements. There are two major problems with this:
- it is difficult to identify hidden "households" in the 94.01% accommodation that isseparately identified in a register- it may not be possible to individually identify the "household spaces" that make up theremainder of the housing stock
Definition of TermsThe ACACIA project carried out a study on multiple occupation see;www.ordnancesurvey.co.uk/aboutus/reports/acacia/AcaciaMutioccupReportFinal11May04.pdfThe general definition of multiple occupation used was"any physical property subdivided by occupation".The specific residential categories investigated were developed from those used byNottingham CC. Other definitions of multiple occupation have been produced by DETR andCIEH. The English Household Condition Survey applies the DETR categories.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
67
Technical standards
NOTTINGHAM COUNCIL DEFINITIONS DETR RESEARCH DEFINITIONS CHARTERED INSTITUTE OF Environmental healthDEFINITION5
Within the DETR, there are six categories of HMOrecognised for research purposes. Not all of thesecategories are legally defined as HMOs, and not all aredefined as residential dwellings.
The CIEH has six categories of HMOs - Categories A toF.
A. Bed-sits with shared bathroom and/or kitchenfacilities
Group (i): Traditional HMOs (bedsits). These areconverted houses (and flats) that provide flatlets, bedsitsand rooms, each occupied by a separate household.Within these houses, two or more households share one ormore facilities (e.g. bathrooms, kitchen), or will havecommon circulation space between rooms that are for theirexclusive use.
Category A covers houses occupied as individual rooms,where there is some exclusive occupation (usuallybedroom or living room) and some shared amenities(bathroom/WC/kitchen). Each occupant livesindependently of all others. Traditional HMO buildingswould fall under this category.
B. Shared housesGroup (ii): Shared houses. These are dwellings occupiedon a shared basis, typically by students, or other groups ofpeople who club together to rent a house or flat. Onlydwellings occupied by two or more non-related adults, whoare not partners, are included within this definition.Unrelated individuals buying a house together areexcluded as it is often difficult to assess whether theindividuals are a couple or not. In addition, they are outsidethe rented sector and as such not directly relevant torented sector policy concerns.
Category B covers houses where the occupants 'share'the dwelling. Members of a defined social group, forexample students or a group of young single adults wouldnormally occupy these buildings. The occupiers eachenjoy exclusive use of a bedroom but would share otherfacilities including a communal living space.
C. Student and worker accommodationGroup (iii): Households with lodgers. These arehouseholds catering for lodgers on a small scale. Lodgerswill share one or more facilities with the main householdwithout having the facilities to prepare their own foodindependently. Meals are usually provided and/or thelodger shares a living room with the main host household.
Category C covers houses with some degree of sharedfacilities, occupied by people whose occupation of thedwelling is ancillary to their employment or education. Thehousing is made available through employer or inconnection with a recognised educational establishment.This would typically be student 'halls of residence',nurses' residences or soldiers' barracks.
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
68
Technical standards
NOTTINGHAM COUNCIL DEFINITIONS DETR RESEARCH DEFINITIONS CHARTERED INSTITUTE OF Environmental healthDEFINITION5
D. Hostels and hotels used for the homelessGroup (iv): Purpose-built HMO with shared facilities. Thisgroup is similar to group (i) but dwellings have beenpurpose-built to this specification. They are often shelteredaccommodation with private rooms but sharedkitchens/bathrooms.
Category D includes houses referred to as hostels,guesthouses, bed and breakfast hotels or the like. Theseprovide accommodation for people with no otherpermanent dwelling as distinct from hotels that provideaccommodation for temporary visitors to an area.
E. Registered care homesGroup (v): Hostels, guesthouses, boarding houses, 'bedand breakfast' establishments. These HMOs provideaccommodation on a commercial basis. Most offer mealswith the accommodation, but some provide kitchenfacilities and are self-catering.
Category E covers premises requiring registration underthe Registered Homes Act 1984. These provide boardand personal care for persons in need by reason of oldage, disability, past or present mental disorders, or drugor alcohol dependence.
F1 flats with third party access to the inside of theproperty for delivery purposes
Group (vi): Self contained converted flats. These dwellingsare fully self contained with all amenities behind their ownfront door. However, the flats were originally constructedas one house.It should be borne in mind, that the DETRclassifications were developed for research purposes tosupport policy decisions. Therefore, the groupclassifications take into account the data availability andreliability as well as policy priorities. It should berecognised that given the complexity of some housingcircumstances, the line between categories are not alwaysclear cut.
Category F covers most houses or other buildings that byerection or conversion comprise dwellings that are self-contained, but the dwellings have access via a single'front door' from a common area. Such dwellings wouldnormally contain all the standard amenities but notnecessarily. Nevertheless, there is no sharing ofamenities with the occupiers of neighbouring dwellings.
F2 where there is a single point of delivery for allresidents.G. Business premises with residential owners,managers or staff
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
69
Technical standards
M. Correct address
1. Royal Mail defines the following elements as being required for a correctlyaddressed item.
Address Is it Required? Information
Mr A Smith When applicable Addressees Name
Acme Plc When applicable Company/Organisation
Acme House Yes (except if it has anumber)
Building Name
3 High Street Yes Number of building and name
of thoroughfare
Hedle End Yes but only if a similar road
name exists within a Post
Town area
Locality Name
SOUTHAMPTON Yes Post Town please print in
capitals
SO31 4NG Yes Postcode please print incapitals
From Royal Mail website;Postcodes explainedhttp://www.royalmail.com/portal/rm/content1?catId=400044&mediaId=9200078
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
70
Technical standards
N. Royal Mail Discounts
1. What else is necessary to obtain a discount and what is the discount?
A B C D
Addressing your items Using OCR Using CBC Mixed weight mailings
Scheme Correct
Address
% of batch
Correct
when
compared
to PAF
Min no
Items
Use
OCR
Use CBC
(Barcode)
Walksort
Code
Customer
Sorting
Mixed
Weight
Approx.
Discount
1300 items
up to 100g
and next
day delivery
Mailsort 120 OCR ü 90% 4000 ü ü 45%
Mailsort 120 CBC ü 90% 4000 ü
Post
Code
areas
served by
a Mail
Centre
Up to
100g
only
46%
Mailsort 700 ü 90% 10,000 ü Sorting
Machines
in a Mail
Centre
Up to
100g
only
47%
Mailsort 1400 ü 90% 40001 Local
Delivery
Offices
ü 22%
Walksort (items to at
least 1 in 10 households
in coverage area)
ü 100%
(essential!)
40001 ü To post
delivery
walk
ü 45%
Cleanmail OCR ü 90% 1000 ü None Up to
100g
only
4%
Cleanmail CBC ü 90% 1000 ü None Up to
100g
only
37%
1 2000 if delivery in same Postcode area as postage
2. There is a database defining the areas for Mailsort batches available fordownload.
3. There is a specification for how addresses should be printed on envelopes sothey can be recognised by the Royal Mails OCR software.
4. The WALKSORT Codes are regenerated every three months and are based ona postman’s round (i.e. if a lot of new addresses added then they might change)
Citizen Information ProjectFinal Report: Annex 4:
Technical standards and recommendations
71
Technical standards
so are difficult to generate without looking them up on the database but this isavailable free of charge.
5. The CBC (Customer Bar Code) is printed onto the envelope using certainpresentational rules and contains the Postcode and a Delivery Point Suffix thatuniquely identifies a delivery point (mail box) and also a check character thatconfirms the details are correct. An algorithm is available to calculate the checksum but the Delivery Point must be either obtained from PAF or a reseller.
6. According to KNOW HOW A Users’ Manual for Mailsort, Walksort, andCleanmail page 49 a correct address is defined thus, but see also Appendix M;
“You must include one premise element, one thoroughfare element, one locality elementand the Postcode as a minimum. Other elements may be included. If there is nothoroughfare element contained in PAF© this need not be included.”
Citizen Information Project
Final Report: Annex 4:
Technical standards and recommendations
72
Technical standards
O. Dataset Terminology
ID Name Address Gender DoB PlaceofBirth
DoD
1 Data Data Data Data Data Data2 Data Data Data Data Data Data
3 Data Data Data Data Data Data
4 Data Data Data Data Data Data
5 Data Data Data Data Data Data6 Data Data Data Data Data Data7 Data Data Data Data Data Data8 Data Data Data Data Data Data
9 Data Data Data Data Data Data
10 Data Data Data Data Data Data
11 Data Data Data Data Data Data
12 Data Data Data Data Data Data
Anthony John Smith
Attributes
DataSet
DataElements
em
Recommended