Annex 4 Technical Standards and Recommendationschris/tmp/20060422/cip-pdfs/Annex 4 Technical... · implemented as part of the ID Cards Scheme by utilising the National Identity

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





Usage................................................................................................................... 17



4.3 Gender................................................................................................................20




Usage................................................................................................................... 20


Short term recommendation: .................................................................................. 21

Long term recommendation:................................................................................... 21

4.4 Date of Birth.......................................................................................................21




Usage................................................................................................................... 21


4.5 Place of Birth .....................................................................................................22

Relevant standards (refer to Appendix I for comparison) .......................................... 22



Usage................................................................................................................... 22


4.6 Date of Death .....................................................................................................23




Usage................................................................................................................... 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



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


Final Report: Annex 4:


1 Preface

1 Introduction




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.




3 Preface

2 Summary of 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”).




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




6 Detailed Recommendations

3 Technical standards




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.




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.




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





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





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.




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




13 Data Transfer Standards

4 Comparison of datastandards




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.




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)




16 Address

• International Address Standard UPU S42-1 PADL – Not discussed


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.




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.




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




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


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




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




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.


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




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




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.


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




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)




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..


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:




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


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.


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.




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




25 Date of Death

5 Metadata standards




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




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.




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





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 ü ü ü ü ü





Quality CharacteristicsDataAttribute

Level forMetadata Degree of

duplicationScope ofDataset

Currency Internalconsistency

Coverage Completeness Formatting Validity Verification

Level forMetadata

Data Attribute ü




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?




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’




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.





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”


Quality Characteristics






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”






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.



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.



38 Appendices

6 Data sharing standards



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.



40 Appendices

Appendices



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.



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



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)



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)



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)



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.



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.



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



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



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



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)



52 Appendices



53 Appendices



54 Appendices



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



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



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



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



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



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



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



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



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.



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.



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



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.



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.



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



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



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)



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.”




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


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





Anthony John Smith

Attributes

DataSet

DataElements

em

Documents

Annex 4 Technical Standards and Recommendationschris/tmp/20060422/cip-pdfs/Annex 4 Technical... · implemented as part of the ID Cards Scheme by utilising the National Identity