Party Name Side Note

Home , List of titles, Maiden and married names, Nickname, Personal name, Stage name

ISB Publication Doc Ref: ISB-000075

Version: 2.0 Issue Date: 26/04/2016

Document Version History

Modified Version Status Issue Date by Description

1.0 Approved: 06/05/2014 ISB Guidance note for Party Recommended Name documentation

2.0 Approved: 26/04/2016 TSS Updated to align with model Recommended changes

Contents 1 Introduction ______4 1.1 Purpose ______4 1.2 Scope ______5 1.3 Business Data Architecture (BDA) Model Version ______5 2 Design Concept ______6 2.1 Business Requirements ______6 2.1.1 (Party of type) Person ______6 2.1.2 (Party of type) Organisation ______7 2.1.3 Common (to both person and organisation types of Party) ______7 2.2 Entity Definition Models ______8 2.3 Attribute Models ______9 3 How the Structure resolves the Business Requirements ______10 3.1 Multiple names ______10 3.2 Re-usable name bank ______11 3.3 Parsing a name ______12 3.4 Name components ordering ______13 3.5 Single design for all parties ______14 3.6 Context-independence ______14 3.6.1 Examples of names in contexts______16 3.7 Handling name changes______18 3.8 Generic controlled list values ______19 4 The PARTY NAME - data exchange agreements ______20 4.1 Background ______20 4.2 The Need for an ESCS wide Data Exchange Agreement ______21 4.3 Recommendation: persons ______21 4.3.1 ‘Simplification’ Recommendations for persons ______22 4.4 Recommendation: Organisations ______24 4.5 Impact of new requirements ______25 5 Conformance ______25 5.1 Background ______25 5.2 Transition and Implementation Issues ______25 5.2.1 Compliance with a Data Sharing Agreement ______26 5.2.2 Full Conformance to the ISB Party BDS standards ______26 6 Frequently Asked Questions (FAQs) ______27 7 References ______36 ANNEX A: LOGICAL WORKED EXAMPLES ______37

File: Party-Name-Side-Note- Page 2 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

ANNEX B: PARTY NAME Controlled Lists ______39 Copyright notice ______42

File: Party-Name-Side-Note- Page 3 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

1 INTRODUCTION

1.1 Purpose This Side Note provides guidance to assist implementers planning to use the Party Name and related Business Data Standards (BDS) which is published by the Information Standards Board (ISB) for Education, Skills and Children’s Services (ESCS). It describes: • the design concept behind the ISB Party Name BDS, ISB Party Relationship Name BDS and Party Relationship Contact BDS (the logical or abstract view) • how to use the data standards in a technical implementation (the physical view) • some potential implementation issues and how to manage them. The ISB standards are capable of handling any person’s or organisation’s names no matter how complex. This document gives guidance on how to apply the standards to handle any name. This document also contains, in Section 4 below, a Data Exchange Agreement between ESCS stakeholders. This is needed because there are no bounds in the logical model on the number of names or the lengths of names that a person may use. The Data Exchange Agreement serves two functions: 1. To capture and record experience as to the numbers and sizes of names handled in practice in ESCS 2. To define a minimum level of capability that all ESCS systems adhering to the Data Exchange Agreement must (eventually) possess so that fit-for- purpose names can be captured and shared throughout ESCS. Figure 1 below illustrates the design contexts/concept this guidance deals with.

Physical data Other sources Provides source Physical data content for message Physical databases Data for output data documentation

Data Exchange Agreement: Minimum implementation requirements and Dictates practical use of standards to meet current needs encoding for for

Dictates structure Logical Technical and semantics for standards standards (BDSs) (TDSs)

File: Party-Name-Side-Note- Page 4 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

1.2 Scope The scope of this Side Note is limited to: • the ISB Party Name BDS • the ISB Party Relationship Name BDS • Party Relationship Contact BDS • related ISB Controlled Lists o (a) Party Name Type, o (b) Party Name Use Type, o (c) Party Name Component Type 1.3 Business Data Architecture (BDA) Model Version This Side Note is primarily based on the BDA model created from the ESCS Entity Relationship Diagram Data Model, version 12.4.

File: Party-Name-Side-Note- Page 5 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

2 DESIGN CONCEPT

2.1 Business Requirements The ESCS BDA supports an ISB PARTY entity which is used to hold data about people and organisations. Key definitions originate in the Party BDS. Every person and every organisation has one or more names. It is clear that the primary use of party names across the ESCS is administrative. The Party Name BDS and related Party Relationship Name BDS are designed to cater for all names and usages that exist in the ESCS. They are, in particular, a response to the need to describe in logical business terminology, name data for PARTY that can be ‘physically’ exchanged using common standards that meet stated business requirements. The following requirements in this section incorporate the results of ESCS discussion (particularly the May 2013 SIWG-Suppliers meeting) and consultation feedback. It has been updated following piloting in the Data Exchange project. These requirements are often defined in terms of how data is physically stored or currently captured across the ESCS. The challenge for this document is to explain how the logically derived ISB standards actually meet the disparate (and sometimes conflicting) physical scenarios that exist in the ESCS. For clarification these requirements are categorised below by ‘person’, ‘organisation’ and ‘common to both’.

Note: A proposed solution to meet the needs is offered in the Data Exchange Agreement section of this document (see section 4). This defines, in relation to the “Full” name, that it should comprise a “preferred” given name component, a “full given names” component holding all the persons given names as they should be written and a “family name” component.

2.1.1 (Party of type) Person 1. Schools and colleges generally need and collect for their own purposes two forms of name: a. “Full” name, used for records and formal communications b. “Known as” name, recording how the individual wishes to be addressed in direct conversation 2. Schools and colleges need to hold the name to be entered on award certificates in a format prescribed by JCQ A2C. 3. For the “Known as” name, schools and colleges need only: Either a. one given name and one family name OR b. a single mononym. 4. For the “Full” name, schools and colleges need to know only: Either

File: Party-Name-Side-Note- Page 6 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

a. The family name eg for alphabetical listings of names b. A preferred given name, not necessarily the first given name, eg to use in the salutation line of a letter, c. The entire set of given names as they should be written, either in full or abbreviated to the first letter. OR d. The ‘full’ mononym. 5. For their own purposes, schools and colleges have no need to know which is the third, fourth, etc part of a person’s given names. 6. The data standard must convey name component information to a recipient when transferred. This is because a reader cannot infer from a person’s name alone which part(s) constitute the family name and which part(s) the given names. Only the person in question can state definitively which the case is. For example, the name “Iain Duncan Smith” may have a family name of “Smith” or “Duncan Smith”. 7. The data standard needs to be able to identify and separate the names a PARTY may have from their contextual use. This recognises that a person may make choices as to how they use multiple names in different contexts, eg a married woman may choose to use her married or maiden names at work and may make a different choice in each work situation encountered.

2.1.2 (Party of type) Organisation The situation regarding recording and use of Organisation names is simpler than for people. An organisation will be registered with or trade under a name. The name may comprise many words but for organisations the name is an indivisible whole. So, for example a school called “Saint Wilfred and Saint Cuthbert Primary School” will never need to be parsed into its constituent words for any purpose. Note that the words “primary school” in the name may seem like a school or provision type but where such information is needed the ISB standards will always carry the information in an explicit “Type” field and never require such data to be parsed out of a name or other field. Likewise if the registered name includes (Limited, LLP etc) then that is part of the single name component, it should not be and need not be parsed into a separate component.

2.1.3 Common (to both person and organisation types of Party) 8. It is preferable to define only fields that need to be completed (ie do not require the name to be separated out where the separation is not needed for any business purpose). This is because people often do not follow instructions when completing input forms, so there is value in keeping forms as simple as possible for any data capture that is needed. 9. The data standard must:

File: Party-Name-Side-Note- Page 7 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

• be capable of accurately conveying all names that a PARTY uses because a person or organisation may have multiple names that they use for various purposes. • enable the order of components of a name to be explicitly specified • provide a single design to hold both PERSON names and ORGANISATION names. This simplifies the standard by avoiding having different containers for the two types, and this in turn avoids having to identify the PARTY TYPE to know where to find the names data. • support implementations where ideally each name component is held once within a system. This supports best practice in data storage and data reuse by building and referencing a normalised PARTY name component data set. • be able to support exchange of previous name(s) for a PARTY (particularly to aid matching the PARTY to records of previous activities) in a way that is future proofed by minimising the data changes needed when a new name is adopted. • provide a standardised set of generic controlled list values to accommodate all of the existing variations of names and name usages in the sector.

2.2 Entity Definition Models

File: Party-Name-Side-Note- Page 8 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

2.3 Attribute Models

File: Party-Name-Side-Note- Page 9 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

3 HOW THE STRUCTURE RESOLVES THE BUSINESS REQUIREMENTS

Logical standards (BDSs) This Section addresses the context in figure 1.

3.1 Multiple names Requirement: a person may have multiple names that they use for various contextual (non-role name type) purposes. The Party_Name_Description will discriminate different ways in which names can be described. Example 1a below and further Annex A examples illustrates: Currently known administrative uses in ESCS include: • Full • Known as

File: Party-Name-Side-Note- Page 10 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

ISB Standard Party Name & Party Name Component entities 'LOGICALLY' define name component instances (or name parts)

Taken together, the following examples for these entities show the extensibility and flexibility of this part of the ISB Standards by showing a (sub)set of possible 'LOGICAL' candidate entries that the standard could support. Non-shaded entries represent new names! Shaded represents represent older versions (that are NOT active). Party_Id Party_Name_ Party_Name_ Party_Name_ Party_Name_ Party_Name_ Party_Name_Component Description Effective_Date Component_ Effective_ Component_ Order End_Date Type Consider: George Iain Duncan Smith MP, IDS, born 9 April 1954 - the British politician. 00000000000002222222222222222244 Full 11/06/1987 1 n/a (null) Given George 00000000000002222222222222222244 Full 11/06/1987 2 n/a (null) Given Iain 00000000000002222222222222222244 Full 11/06/1987 3 n/a (null) Family Duncan Smith 00000000000002222222222222222244 Full 11/06/1987 4 n/a (null) Title MP 00000000000002222222222222222244 Known As 11/06/1987 1 n/a (null) Title The Right Honourable 00000000000002222222222222222244 Known As 11/06/1987 2 n/a (null) Given Iain 00000000000002222222222222222244 Known As 11/06/1987 3 n/a (null) Family Duncan Smith 00000000000002222222222222222244 Known As 11/06/1987 4 n/a (null) Title MP 00000000000002222222222222222244 Known As 13/09/2001 1 n/a (null) Mononym IDS It is recognised that the ways in which names are described are as yet not well understood across the whole of ESCS. Therefore the Party_Name_Description is not limited to a set of controlled list values; any value that reasonably describes the name in question may be used, provided that the text does not describe a role name usage, such as for example “enrolment name” or “certificate name”. Other Party_Name_Description candidates may emerge in the future, eg Birth, Married, Alias, but these will require careful handling and further guidance given the range of interpretations and debate that has arisen from the current set of Full and Known as. The use of a particular Party_Name_Description does not in itself provide a verification that an event that may be implied by a name description (such as marriage or deed poll name change) has actually occurred. The name description only conveys a declaration by the providing PARTY. It is not intended to identify the particular ‘role name’ use via Party_Name_Description (such as work name, stage name, nom de plume) as the same Party_Name_Description name may be used in many such contexts.

3.2 Re-usable name bank Requirement: to create a name bank for a PARTY so that name information is held a limited number of times and reused as required. Example 3a below (and further Annex A examples) illustrate the way the ISB data standard could accommodate this requirement though as suggested earlier, the ‘shaded’ entries refer to ‘speculative’ content only for Party_Name_Description!.

File: Party-Name-Side-Note- Page 11 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

This is supported by the creation of Party_Name_Description values for names that are not context specific. A PERSON may have several associated names, each with a different Party_Name_Description.

ISB Standard Party Name & Party Name Component entities 'LOGICALLY' define name component instances (or name parts) Taken together, the following examples for these entities show the extensibility and flexibility of this part of the ISB Standards by showing a (sub)set of possible 'LOGICAL' candidate entries that the standard could support. Non-shaded entries represent new names! Shaded represents represent older versions (that are NOT active). Party_Id Party_Name_ Party_Name_ Party_Name_ Party_Name_ Party_Name_ Party_Name_Component Description Effective_Date Component_ Effective_ Component_ Order End_Date Type

Consider: Jean Alys Barker (married 1954), (the Rt Hon the) Baroness Trumpington (1980), DCVO, PC. Born Jean Alys Campbell-Harris (23/10/1922) - a life peer and retired politician 57777777222777222277727727277722 Birth 23/10/1922 1 31/05/1953 Given Jean Recognises 57777777222777222277727727277722 Birth 23/10/1922 2 31/05/2013 Given Alys change of name on 57777777222777222277727727277722 Birth 23/10/1922 3 31/05/2013 Family Campbell-Harris marriage 57777777222777222277727727277722 Married 01/06/1954 1 n/a (null) Given Jean 57777777222777222277727727277722 Married 01/06/1954 2 n/a (null) Given Alys 57777777222777222277727727277722 Married 01/06/1954 3 n/a (null) Family Barker 57777777222777222277727727277722 Full 01/06/1954 1 n/a (null) Given Jean 57777777222777222277727727277722 Full 01/06/1954 2 n/a (null) Given Alys 57777777222777222277727727277722 Full 01/06/1954 3 n/a (null) Family Barker 57777777222777222277727727277722 Known As 15/01/2005 1 n/a (null) Title The Rt Hon the Recognises 57777777222777222277727727277722 Known As 15/01/2005 2 n/a (null) Title Baroness peerage and additional 57777777222777222277727727277722 Known As 15/01/2005 3 n/a (null) Given Trumpington honours 57777777222777222277727727277722 Known As 15/01/2005 4 n/a (null) Title DCVO 57777777222777222277727727277722 Known As 15/01/2005 5 n/a (null) Title PC It is recommended that individual systems or groups of systems agree to common usage of the definition of Party_Name_Description values to ensure that the set of values used properly reflects real types of name in use, and does not accidentally include ‘role name’ use context.

3.3 Parsing a name “Parsing” a name means breaking a whole name into its constituent parts (eg determining that “John Frederick De La Pole” is in fact: • Given name: “John” • Given name: “Frederick” • Family name: “De La Pole” Requirement: being able to cope with the fact that a reader cannot reliably infer from a person’s name alone which part(s) constitute the family name and which part(s) are the given names. In general names can only be correctly broken down into family name and given name(s) by the name holder. For example consider non-British names and non-

File: Party-Name-Side-Note- Page 12 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

hyphenated compound family names like “Duncan Smith” – see Example 1a in Annex A. The PARTY NAME model caters for this by allowing a name to be de-composed into its various parts and allowing each part to be comprehensively labelled so that there is no question of misinterpretation by a recipient when the name data is exchanged. Thus the standard allows for full precision of expression of names where this is needed. Separately groups of users will need to create a Data Exchange Agreement to specify how the standards should be used in any situation in order to meet business needs (see Section 44 below). The PARTY NAME COMPONENT is designed to contain each part of the name and the PARTY NAME COMPONENT TYPE identifies the type of the name component. Values of PARTY NAME COMPONENT TYPE controlled list include: • Title • Given • Family • Organisation Name • Mononym

3.4 Name components ordering Requirement: being able to cope with the fact that the order of name components cannot be assumed to be given name followed by family name since some cultures present their family name first. In a name there can be multiple occurrences of the same name component type. For example a person’s first name and middle name are both encoded using the “Given” name component type. To show the order needed to express the person’s name as they use it requires a sequence number, and to create a unique identification for each Party Name Component Type requires that the sequence number be made part of the Primary Key. The Party_Name_Component_Order identifies the sequence of PARTY NAME COMPONENTs within the name, allowing for the fact that some non-British names put the family name first and others, eg most European names, put the family name last. Logically, the Party_Name_Component_Type is required to provide a clear understanding on the composition of the complete name set. Example A – “John Burt Smith” declares his name as follows:

Party_Name_ Party_Name_ Party_Name_ Component Component_Order Component_Type

John 1 Given

Burt 2 Given

File: Party-Name-Side-Note- Page 13 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

Smith 3 Family

Example B - Alternatively, “Mr Kwok Lee” (where Kwok is his family name) declares his name as follows:

Party_Name_ Party_Name_ Party_Name_ Component Component_Order Component_Type

Mr 1 Title

Kwok 2 Family

Lee 3 Given

3.5 Single design for all parties Requirement: that there should be a single design for both PERSON and ORGANISATION names. Due to the sub-typing of PARTY, if there were different containers (structures) for ORGANISATION name and PERSON name it would be necessary to identify the PARTY TYPE in order to determine the correct name. Instead, this requirement is resolved by setting the Party_Name_Component length to 255 characters thereby allowing for an ORGANISATION name to be held as a PARTY NAME COMPONENT with a PARTY NAME COMPONENT TYPE of “Organisation Name”. The alternative would be to sub-type the PARTY NAME so that there was a single level design for ORGANISATIONs and the component based design for a PERSON. However, this would add little value to the standard and would require extra coding to load or consume the specific sub-type.

3.6 Context-independence Requirement: to separate names a PARTY may have from their contextual use. The PARTY NAME structure is intended to resolve the above requirements and to provide a bank of names that a person uses. It recognises the origin or derivation of names but does not identify which name to use in a particular context. Whilst it may appear an obvious approach to use the Party_Name_Description to define the context of ‘role’ use there are three reasons why this is not a suitable approach: 1. A PARTY generally only has a few names that they declare but there are many instances where those names are used such as on different application forms (eg as Pupil Name, Child Name, Account Name, Borrower Name, etc). If the Party_Name_Description was used to

File: Party-Name-Side-Note- Page 14 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

indicate context each time then the same name would be repeated against each context. If a PERSON completed ten application forms then it would appear that the PERSON had ten different names when in fact they used exactly the same name on every application.

2. If it were pre-defined that the name used at work is the “Work Name” a married woman who chooses to use her maiden name in one work context and to use her married name in another work context would appear to be changing her work name whereas she actually wanted to use two names at work, one in one context and the other in a different context.

3. Finally, designers typically simplify applications by building hard links between processes and name descriptions. For example, if the context allows the assumption that the majority of people use their birth name at work, then a supporting application can validly label all names supplied as birth names. However where it is a valid choice for a woman who marries to use their married name at work, such applications will mislabel the name of such a woman as her “Birth” name. The resolution to these problems is to define a structure that identifies a use context separately to the PARTY NAME and then links a particular name to that context: • The names that a Party uses are recorded in a set of Party Name entities. When a Party enters a relationship with another (for example a Learner enrolling at a Learning Opportunity Provider), the name declared will be recorded in the form of a Party Relationship Name which links a name in the name bank to the Party Relationship. • Sometimes third parties must be recorded – for example the details of a person to contact in case of an emergency. These third parties are not in a direct relationship to the recording organisation. Their details are held using a Party Relationship Contact entity. These considerations have led to the data structure in the BDA and an extract is reproduced in the figure below:

File: Party-Name-Side-Note- Page 15 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

3.6.1 Examples of names in contexts A very simple example is a Pupil enrolling at a school. The School (Party 1) records data about the pupil (Party 2), including the fact of the relationship using the Party Relationship with an identifier (UPN in his case) and the name given by the pupil to the school. In the example below, the pupil is known formally as Frederick and informally as Freddie. The name Frederick is given to the school, so that Party Name entity is joined to the Party Relationship entity that links the pupil to the school, as shown in the diagram below:

File: Party-Name-Side-Note- Page 16 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

Party 1 Party 2

Party Relationship [Party1,Party2] “UPN”

Party Party Name Relationship Freddie Name

Party Name Frederick

Extending this example, the school also needs to know who to contact in case of emergency and is given the Mother’s name. The Party Relationship Contact links to a locator (a telephone number in the example below) and to a Party (the mother) who is to be contacted. As the name will only be used in telephone calls, the mother gives her preferred name “Pat”, and this is recorded as below:

Party 1 Party 2

Party Relationship [Party1,Party2] Party “UPN” Relationship Contact “mother” Party Party 3 Party Name Relationship Freddie Name

Party Name Party Name Party Name Frederick Pat Patricia

Another example of a contextual use of a name is the Award Certificate Name. The Award name is required by the CENTRE on the PARTY RELATIONSHIP

File: Party-Name-Side-Note- Page 17 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

between the CENTRE and LEARNER. To support this, the following Business Data Standards are required: • a PARTY NAME with a PARTY NAME DESCRIPTION of “Full” is required for the LEARNER; • A PARTY RELATIONSHIP between the CENTRE and LEARNER; • A PARTY RELATIONSHIP NAME between the CENTRE and LEARNER with a PARTY NAME USE TYPE of “Award”.

3.7 Handling name changes Requirement: to be able to support exchange of previous name(s) for a PARTY in a way that is future proofed. Many systems adopt the ‘physical’ view of current and previous name by identifying them with suitably named fields such as “current name”, “previous name”. Whilst this has the advantage of being simple, it misses out the following important facts: 1. If two systems collect the same name from a person and one labels it as a “current” name and the other labels it as a “previous” name, which was correct at a particular moment in time? This question can only be answered if the date and time on which the name change occurred is recorded.

2. What happens if there is more than one previous name?

3. If I need to know which person acted under the name of John Smith on date X then I need to know the dates between which each person was using the name John Smith.

4. Is “previous” name really a previous name or actually a name with a different name description such as when a person marries and adopts the spouse’s name? Both names may be in current use in different contexts.

5. A name collected as “current name” may over time in fact become a “previous name” and so will be wrongly labelled. The Party Name BDS uses an effective date of the name to allow for one or more previous names for the same name description. This allows infinite versions of the same name description. The field in PARTY NAME used for this is Party_Name_Effective_Date and is part of the identifying attributes. The effective date of the name may not appear to be directly stored in a system but the data is often available elsewhere in the system. If not, a substitute date can be used. However, in the case of past and previous names, before simply adding two substitution effective dates to a single name description, it is essential to determine whether in fact the “past” and “previous” names are both in current

File: Party-Name-Side-Note- Page 18 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

use, as is often the case with maiden and married names. This requires an understanding of the person’s situation. Where a past and previous name are two names both in current use, the correct resolution would be to store two current names using two different name descriptions to distinguish them (eg a name description of “maiden” or “birth” and a name description of “married” etc). The date for both can be the same as the only known fact is that the past and previous names were really two name descriptions. Example 3a in Annex A illustrates the way the ISB data standard accommodates this requirement. The options for completing the Party_Name_Effective_Date field will depend on what is known about the person and the name: 1. For example, if a “Birth” name as on a birth certificate were recorded as such with name description “birth” – the effective date to use is the Date of Birth. This field is generally held in most systems that deal with people.

2. For a “Full” name or “Known as” name, where the provenance of the name is unknown (ie it is not known if the name given is a birth, married, deed poll, recently anglicised by custom & practice etc) use the date when the name was captured.

3. Where there is no date available such as date the person started to use the name a suitable substitute needs to be provided. One approach is to use a substitute date that is just prior to the current date. This will allow the data to reflect that it is the current value and not a future value. It should be noted that the Party Name Effective Date is never intended to be used to indicate when the person acquired the name. It only indicate a date from which it is known that the name was in use. The Party_Name_Effective_Date in the PARTY NAME COMPONENT is the inherited effective date from the PARTY NAME and so it is the effective date of the whole name description.

3.8 Generic controlled list values Requirement: to provide a standardised set of generic controlled list values to accommodate all of the existing variations in the sector. Consider a scenario where the current system includes various labels or description for the components of a name such as first name, forename, surname, given name, middle name, etc. The Party Name BDS and the Party Name Component Type controlled list provide a set of controlled list values such that there is a single instance of a type. This ensures that any system interfacing to the Party Name BDS will send/receive data using a common set of controlled list values that any other system can understand from the definitions provided against each controlled list value.

File: Party-Name-Side-Note- Page 19 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

Unless and until a system’s internal design exactly aligns to the ISB BDA, it will need to convert from each of its internal field definitions to the appropriate matching Party Name Component Type controlled list value. This is simply done during the data export (ETL – Extract Transform and Load) process. When receiving data in the Party Name BDS format it carries out the reverse process to map data received in ISB conformant format to its internal storage format. In the case of Party_Name_Description, useful exchange of data can only take place when the sender and all recipients understand the values placed in the attribute. Considerable discussion has led to agreement on the use of two default description values: “Full” and “Known As” (see the data exchange agreement recommendation in Section 4.3 below). However many ESCS sector stakeholders have not been party to these discussions and other needs may emerge.

Thus the Party_Name_Description attribute is currently a text field, whose values (new or existing) must be proscribed and constrained within a data exchange agreement, ie systems must not make up name Party_Name_Description(s) in isolation.

This requires each system to identify the mapping from its internal format to the PARTY NAME format and types. Once this mapping has been implemented then any exchange using the Party Name BDS will operate in the same manner. The system will no longer have to behave differently depending upon which other system it is sending data to or receiving data from.

4 THE PARTY NAME - DATA EXCHANGE AGREEMENTS

This section addresses the

…. that underpins any actually transmitted.

4.1 Background The details of the recommended Data Exchange Agreement (DEA) in this section presents the agreements reached in the Suppliers Special Interest Group/

File: Party-Name-Side-Note- Page 20 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

Supplier Implementation Working Group joint meetings to date and wider consultations on the subject of names.

4.2 The Need for an ESCS wide Data Exchange Agreement Section 3 above explains how the Party Name BDS handles the full complexity of names that exist in the real world. However it is also recognised that each organisation will make a decision about how much detail of a Party’s name is needed for their own business purpose and, when data is to be exchanged, how much detail of the name is needed in the exchange. Thus the granularity of a PARTY NAME as exchanged via ISB standards is defined by the Data Exchange Agreement between the organisations. Across ESCS, there are many different business needs for party names. Awarding Organisations need to hold a precise form of the name required by examination candidates to appear on awards certificates. Other organisations in ESCS need a different level of precision of names in order to support accuracy of name matching between data sets. Schools need to know how to address pupils in class, and also must be able to supply “award names” to Awarding Organisations. As a result, there is the potential for many very different data exchange agreements to develop across ESCS. This in turn could lead to a reduction in the ability to share data across ESCS and thus an inability to achieve the full potential of service and efficiency improvements. Hence there is value in trying to reach a single Data Exchange Agreement covering the whole of ESCS and designed to optimise a (future, integrated) ESCS as a whole, rather than achieving local optimisations that frustrate global optimisation. When a single Data Sharing Agreement has been achieved, there may be a transition period before all systems conform to it, during which there may be temporary agreements to use different Data Exchange Agreements for local purposes as part of a transition plan.

4.3 Recommendation: persons Based on the observations of data interfaces in current use, and also of project requirements, the default recommendations for handling PARTY[person] names are that systems complying with this data exchange agreement:

1. Must support Party name descriptions of “Full” and “Known As” and be able to store at least one name of each description.1

1 Note: ESCS Awarding Organisations requirement is for full name only.

File: Party-Name-Side-Note- Page 21 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

2. Must support name components of up to 255 UTF-8 characters.

3. Must use sequence numbers to order name components in the order the person defines as being their name where there is no name concatenation.

4. Should not transmit Party_Name_Description(s) other than “Full” or “Known As”. 2

5. May support (be able to capture and store if received) additional name component types (eg Title) and/or more name components of each type.

6. Where a system truncates name components (for example systems that only store initials for middle names or systems that can only handle 35 characters for each name component) and/or where some name components are discarded on receipt, then the data exchange conformance statement must state the limitations of the system.

In addition to the above recommendations, a short proposal to ‘simplify’ the original recommendations surrounding the treatment of “Full” and “Known As” names was sent out for consultation to SIWG members in March 2014. As this proposal was favourably received its recommendations are now included in the next section.

4.3.1 ‘Simplification’ Recommendations for persons This proposal stems from the observation that logically if we have a given name component in a "Known As" name, then it tells us the preferred given name for the person so we do not need the preferred given name in the “Full” Name. Also it is anomalous to have in the “Full” name a preferred given name component and then the full set of given names concatenated into a second component and a sequence ordering between them because they will never be written in that sequence! So it is proposed to meet the business needs via a simplification to what is contained in the Data Exchange Agreement, ie to agree to exchange the following:

2 Because the ‘Party_Name_Description’ is NOT a constrained list the original ‘must not’ recommendation is not actually enforced by the logical data model underpinning the ISB Party Name standard. If a particular ‘Data Exchange Agreement’ between two organisations wants to adopt an additional rule limiting content of this component to “Full” or “Known As” (or anything else for that matter) then that rule does not contravene the standard, it merely constrains it.

File: Party-Name-Side-Note- Page 22 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

• A “Full” Name having just the concatenated given names in one given name component and the family name component (or the single mononym component) • A “Known As” name having the person’s preferred given name and the preferred family name (or the single mononym component) For addressing the person, eg in letters, the given name can be selected from the “Known As” name and for expressing the name in full eg on certificates, the “Full” name can be used. Additionally, we propose to clarify that: 1. The intention of the “Full” name is to hold a legal name as recorded, eg on a birth certificate, marriage certificate or passport. However practice in ESCS is that names are often not verified as being a “birth certificate” name or a “marriage certificate” name etc. Therefore the “Full” name is to hold what is supplied in response to the question “What is your full (legal) name?” 2. Where a name does not correspond to a Full name eg in the case of Iain Duncan Smith, whose Full or legal name is actually George Iain Duncan Smith, we would expect that the Full name would contain: a. Given name(s): George Iain b. Family: Duncan Smith And we would expect there to be a Known As name of c. Given name: Iain d. Family name: Duncan Smith on the basis that Iain Duncan Smith is not the full legal name, but it is the name that the gentleman prefers to be known by. This allows, for example, an award certificate to hold the full name of George Iain Duncan Smith and for letters to be addressed “Dear Iain”.

The Data Exchange Agreement sets out a minimal set of requirements. If a system does collect and hold a fully-parsed name, with given name components duly separated out, then it should send this information. A receiving system that only holds concatenated given names may concatenate received given names, and may if necessary discard them should they overflow the receiving systems storage facilities.

File: Party-Name-Side-Note- Page 23 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

Examples:

4.4 Recommendation: Organisations An organisation’s name should be recorded in a single component of Type “Organisation” and should record full Latin based characters from the Unicode Character dictionary. Systems must be capable of receiving and sending up to 255 character organisation names. The name should include all part of a registered or used name, including “LTD”, “LLP”, “plc” etc. See example 6c below.

File: Party-Name-Side-Note- Page 24 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

4.5 Impact of new requirements Section 3.0 identifies new requirements that are yet to be included in the Party Name design. The impact of these requirements on the data exchange agreement is that the exchange of the “Known As” name should be considered as the “Known As” name for a PARTY at the particular ORGANISATION from which the data is sent. Therefore, if the same PARTY is registered at two LEARNING PROVIDERs during the same time period, the “Known As” name may not be the same and should be stored separately against each LEARNING PROVIDER.

5 CONFORMANCE

5.1 Background The following guidance must be read and understood in conjunction with the general guidance on conformance in the document “Achieving Conformity with ISB Data Standards” which is published on the ISB Website.

5.2 Transition and Implementation Issues The intention of the Party Name BDS and Party Name Relationship BDS is to be able to hold and exchange the various name descriptions and constituent parts of a name at the lowest level of granularity (full conformance). However, for a transitional period when initially implementing the standard it may not be possible to achieve this aspiration because: • The internal system design may preclude being able to hold or identify all of the various name descriptions or name component types defined by the standard.

• A system may hold data collected earlier where the party disclosing the name did not provide all of their name components or did not clarify the name description or which components are family and given names. For example, if a name that has been declared is “Duncan Smith”, it should not be assumed that “Duncan” is the given name and “Smith” is the family name as it could be a double barrelled family name. When exporting such

File: Party-Name-Side-Note- Page 25 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

a name in ISB format, the system will have little option but to include “Duncan Smith” as a single name component. In these cases, the system is exporting incorrect information, which may nevertheless be of use to the recipient. However, the sooner the system can upgrade to collect and store correct information, the sooner it will stop exporting poor quality data to its peers. Also, the standards say nothing about limitations. For example, the standard imposes no limits on how many name components may be received when a name is transferred nor on how many names may be received for a person or organisation. In reality, all systems will have limits, and there is value in agreeing a minimal requirement for all systems in a sector. Recognising these factors, systems wishing to claim that they are using the ISB name standards may make one or both of the following claims:

5.2.1 Compliance with a Data Sharing Agreement A supplier may state that their system complies with a data exchange agreement such as that recommended for education and skills in Section 4.3 above.

5.2.2 Full Conformance to the ISB Party BDS standards A supplier may wish to show that their system has the full flexibility and future- proofing conferred by full conformance to the ISB Party Name BDS and ISB Party Name Relationship BDS, in addition to meeting the minimum requirements of a data exchange agreement. For a specification of what full conformance to ISB standards requires, the BDS must be read in conjunction with the document “Achieving Conformity with ISB Data Standards” which is published on the ISB Website.

File: Party-Name-Side-Note- Page 26 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

6 FREQUENTLY ASKED QUESTIONS (FAQS)

This section on FAQs largely emanate from the context.

1. Why is it incorrect to use “Previous” as a name description? This question is answered by section 3.7 above. Essentially the concept of ‘previous’ would always be derived via Party_Name_Effective_Date as there would be a later set. 2. How do I know what name descriptions and name components a PERSON uses? For name components, the only reliable method is to ask the PARTY at source what they recognise as their Family name and what Given name(s), in order, they admit to. For name descriptions, the only reliable methods are to ask the PARTY at source to supply the name that aligns with a quoted name description, for example Full or Birth or Married as required. Remember, it is not the contextual role name description (Party Name Use Type) that is in question, rather it is the fundamental name description and Party Name Component Types that are required. It is acknowledged that systems that have collected name data in the past under a variety of circumstances and processes may not necessarily have the opportunity to question the source PARTY. In these cases the following guidance should be considered: • Where a system purely records “name” then the definition of the field and the business context in which the name is collected and used will typically provide the necessary additional information such as “in our business we ask for the “Known As” name. In this case then the default name description to use is “Known As”. Where the person’s name is prefixed with “Mrs”, then the “Married” description could (with careful consideration) be inferred. If there is no information in either the system or the name itself that may indicate the name description then default to “Full”.

• For an organisation name where the specific name description is not already held then if the name ends with “Ltd” or “Limited” then

File: Party-Name-Side-Note- Page 27 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

“Incorporated” description can be applied. Otherwise apply “Trade” description.

• Where the system specifically records former name and can state definitively “this is the person’s maiden name” then use the name description “Birth” could be inferred or, if “Birth” is not a name description in use, then “Full” must be used with an effective date of the person’s birth date.

• Where the system specifically records former name but without explanation as to the reason for there being a former name then use the name description “Birth” or, if “Birth” is not a name description in use, then “Full” should be used with an effective date of the person’s birth date.

• Where the system specifically records married name and can state definitively “this is the person’s married name” then use the name description “Married”, or, if “Married” description is not a name description in use then “Full” should be used with an effective date after the birth date (eg just before the date of data capture).

• Where the system specifically records preferred name and states “this is the persons preferred name” then use the name description “Known As”.

3. Do I need a different name description for all the variants of a particular name such as Mr Fred Jake Smith, Mr Fred Smith, F Smith, F J Smith etc? No. All of the above are forms of the same name description. As such, they are the name components of a single name description that should be declared for a particular purpose. Example: A party wishes to purchase a product online and is asked for their full name and the system is able to supply the following data in ISB compliant format: • Party_Name_Description – “Full” • Title (Component Order 1) – “Mr” • Given (Component Order 2) – “Fred” • Given (Component Order 3) – “Jake” • Family (Component Order 4) – “Smith” The Party Role Relationship being formed then adds the Party Name Use Type declared as follows: • Party_Name_Use_Type – “Award Name” • Party_Name_Description – “Full”

File: Party-Name-Side-Note- Page 28 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

When the supplier communicates with the customer they make a decision as to how to address the applicant and may choose to use one of the following example forms: • Fred Smith • Mr F Smith • F Smith The above does not require the PERSON to declare a new name, it is the receiver of the name who makes the decision as to how to address the provider based on the declared “Full”. Should it be required to address a party in a consistent way that they have requested, no new name description is to be applied but rather the context use of a name should also have a “Party Name Address Form” attribute populated”. The following are some rules of name description selection: • If the particular name to use is an extract from an already declared name description then use that name description again but select the particular components as appropriate. Do NOT create a new name. • If the particular name is not an extract from an existing name then a new name description has been declared – create a new name and specify the Party_Name_Description. • The name components declared must be the full name by which the person could be referred to. In the above example you could not create a name description with both Fred and Freddy as components of one name, because the “Full” name would then be Mr Fred Freddy Jake Smith - Freddy is a “Known As”. Do not mix name Party_Name_Description(s)!

4. Do I have to store all of the name components that a person uses for one name to be ISB conformant? In reality, a system can only hold and exchange what PERSON declares to them. So if a person with 5 given names only tells you one of them, this does not mean you are not compliant. However, what you capture and store must be exported using the correct ISB-compliant component types. So if you capture details of Mr John Smith, where Smith is the family name, and export the name component “Smith” as a component of type “Given” then you would not be ISB compliant. It is rarely possible to force a PERSON to give you their “Full” name or to correctly partition their name correctly into ISB component types if they choose not to do so. If the PERSON will only give you their first name and family name then you can only hold these as Given and Family name component types.

File: Party-Name-Side-Note- Page 29 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

5. What happens if I am not able to supply a Party_Name_Description or Party Name Component Types as I do not hold the level of detail required in my system? This question is answered by section 5.2 above. 6. Does my system’s internal data design need to be conformant with the Party Name BDS as a pre-requisite to conformity of data exchanges with other systems? No. Implementing the standard, for the purpose of data exchange with other systems does not require the source or the receiving system to implement the Party Name BDS structure internally at full granularity in order to achieve data exchange conformance. The transformation from the source or receiving system to/from the Party Name BDS can be carried out during export or import during ETL (Extract Transform and Load). That said, the more divergent a system’s internal data design is from an ISB data standard the more likely that the transform part of ETL will be more complex and/or difficult! Example 2c below attempts to show some of the variations that could reasonably be expected to exist in existing systems across ESCS.

Changes to systems to fully support the level of granularity that the PARTY NAME can support should be driven by business need. Note that system data transfers in or out may need to change the length and type (physical data type) of attribute used as part of any transform to conform to the standard or comply with the data sharing agreement. 7. What if I hold a number of ISB equivalent name components within one field? Many systems hold multiple names in one field. In certain cases the systems are able to extract values from one field accurately. In this case there can be

File: Party-Name-Side-Note- Page 30 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

an advantage to extracting into multiple name component types. Apart from those indicated in Example 2c above, common examples are:

Existing System Party_Name_Component Party_Name_Component Field _Type and _Type and Party_Name_Component Party_Name_Component

First Name = “Mr Title (Order 1) = “Mr” Given (Order 2) = “Joe” Joe”

Surname = “Smith” Family (Order 3) = “Smith”

In the above there is minimal risk in extracting the title as the list of titles can usually be clearly defined. Extracting the data in this way ensures the ISB data standard is used correctly. The system should be careful when extracting meaning from one field in the following scenario BUT in order to meet the ISB data standard for data exchange will probably need to make a call to treat as either …

Existing System Party_Name_Component Party_Name_Component Field _Type and _Type and Party_Name_Component Party_Name_Component

First Name = Joe Given (Order 1) = “Joe” Given (Order 2) = “Ian” Ian

Surname = Smith Family (Order 3) = “Smith”

Existing System Party_Name_Component Note Field _Type and Party_Name_Component

First Name = Joe Given (Order 1) = Joe Ian Both Joe and Ian are Ian placed in the one name component because it is unclear if they are two given names and the call has been made to treat as a single double barrelled given name

Surname = Smith Family (Order 2) = “Smith”

See also FAQ 12 (When should I split a ‘Family’ name?).

File: Party-Name-Side-Note- Page 31 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

The rule is that if the meaning of a name value in a concatenated field is clear and unequivocal then it should be extracted. This normally applies to titles but a system may already have an approved algorithm or derivation rule to extract concatenated components currently stored and this should be used when converting to the ISB PARTY NAME format. 8. What if I hold or can extract a higher level of granularity than the data sharing agreement requires? If a system is able to hold or extract more PARTY NAME COMPONENT TYPES than is required by the data sharing agreement it should do so. The receiving system is free to discard fields that it cannot handle correctly. The Data Exchange Agreement informs a minimum requirement, not a maximum requirement. Note that correct handling of party names includes being able to export data received in ISB format exactly as received. A system that cannot do this must discard or suppress export of any data received that it cannot export accurately. Due to the variety of system designs it is not possible to provide a standard recommendation. However, the following are two examples of how a receiving system may be able to fulfil the requirements:

Example C

Party_Name_ Party_Name_ Existing System Field Component_ Component_ Type and Type and Party_Name_ Party_Name_ Component Component

Title (Order 1) = “Mr” Given (Order 2) = “Joe” First Name = “Mr Joe” Note: these two component types can be concatenated acceptably because the receiving system can reliably partition this concatenated field on export

Given (Order 3) = Middle Name = “Ian” “Ian”

Family (Order 4) = Surname = “Smith” “Smith”

File: Party-Name-Side-Note- Page 32 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

Example D

Party_Name_ Party_Name_ Party_Name_ Existing System Field Component_ Component_ Component_ Type and Type and Type and Party_Name_ Party_Name_ Party_Name_ Component Component Component

Title (Order 1) Given (Order Given (Order 3) First Name = “Mr Joe Ian” = “Mr” 2) = “Joe” = “Ian” Note – concatenating these 3 component types is only acceptable if upon export the system can partition them back into their 3 component types

Family (Order Surname = “Smith” 4) = “Smith”

9. Why is there no “Given Names” (plural) or “Full” Party Name Component Types? To provide a canonical3 model the BDA has to standardise the structure, behaviour and consistent pattern of the particular model. A user of the standard has to always be certain that they deal with data in a consistent manner. The standard identifies that there is a Party Component Type of “Given”. Within that type, depending upon what is declared by the name owner or the source system method of holding data, there may be one or multiple names. The fact that they are all in one “Given” type field declares that that is the lowest level of certain granularity for the contents provided. A system that only holds a field name called “Given Names” (plural) is not ensuring that there will always be multiple given names in that field. It is stating that there may be one or more but it is not certain that there will be in every case. Introducing a Party Component Type called “Given Names” would result in the standard effectively providing two versions of the same field. The

3 Definition of “canonical”: where there can be many ways to represent a single meaning, a canonical form consists in the choice of a specific choice of representation. The BDA is a canonical model because it is developed to follow rules in the choice of representation of data structures.

File: Party-Name-Side-Note- Page 33 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

standard would no longer be a canonical model and users of the standard would see a mixed behaviour pattern. The reason for not including a Party_Name_Component_Type of “Full” is the same as for “Given Names” considered above because "Full" does not define exactly what level of detail is in the field just that it contains everything declared by the PARTY for a particular name. The “Full” name in one name component field would be unlikely to support the entire range of business processes and has therefore not expressed the required parts of a PARTY NAME that would suffice to meet all business needs in a single design. 10. What if I receive a name that has different name component values to a name with the same name description that I already have? This situation can arise as a result of either: • a change of circumstances recorded by a system; • or because two different systems supplies the same name description but with different component values (ie because the person supplied different component values to the two systems). In the first instance the effective date will allow this new version of the name to be held separately from the original. Any existing use of the name description will still point to the original name. New uses of the name description should use the latest value. If the existing value should be discontinued then the systems will need to be altered internally to use the new value instead. In the second instance, it is now unclear as to which is the correct value. The source of the original name and the source of the new name need to be consulted to establish the correct version. The source that supplied the incorrect version needs to be updated accordingly so that all systems use the same values. It should be noted that altering existing data needs to be managed carefully. For example, system A has “Mr J Smith” stored and declared it to be "Birth” name description, and now receives from system B "Mr Jake Smith" as the birth name and this has been verified as the correct birth name. System A should now replace “Mr J Smith” with “Mr Jake Smith” and this will impact System A’s uses of the name. If System A in fact has embedded reliance that it’s names are all of the form Mr J Smith, System A may need to truncate the first name before use or hold a truncated local version of the name so as to leave existing code alone. 11. What component order sequence number should I use if I do not hold that data? Without the declared order by the owning party, any ordering would have to be an assumption. If the name appears to be European then it can be assumed that the family name will follow the given name(s). However, for some cultures that is not the case. Chinese names usually reverse this and

File: Party-Name-Side-Note- Page 34 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

put the family name before the given name. Therefore, any assumption must be made carefully and the accurate ordering must be obtained from the person as soon as possible. 12. When should I split a ‘Family’ name? Consider an example focusing on a double barrelled Surname:

Existing System Party_Name_ Note Field Component_ Type and Party_Name_ Component

First Name = Joe Given (Order 1) = “Joe”

Surname = Family (Order 2) = Family name should not attempt Harrington Smith “Harrington Smith” to be split up as each part has no meaning without the other in terms of the PERSONs identity

The rule is that if the meaning of a name value in a concatenated field is clear and unequivocal then it should be extracted. This normally applies to titles but a system may already have an approved algorithm or derivation rule to extract concatenated components currently stored and this should be used when converting to the ISB PARTY NAME format. Other seemingly obvious examples where a family name should not be split up on extraction (ie retained as single ordered name component ) are: • “O’Toole” • “MacDonald” • “Del La Rue” • “Ranald-Smythe” The above examples sometimes have spaces inserted before any uppercase letters. The individual parts of these names have no meaning when separated from the other parts. To split or not to split requires an understanding of default normal usage and an understanding of how the real family name should be represented. Unfortunately the ISB data standard cannot provide that insight. The above four examples however are a ‘reasonable indicator of default normal usage which could be factored into an algorithm. The example “Harrington Smith” given above (with a space separator) is more contentious and requires a definite understanding of how the real family name should be represented. If an inappropriate algorithm is applied you could end up with data quality issues.

File: Party-Name-Side-Note- Page 35 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

7 REFERENCES

The following references relate to this document: • ESCS ISB Business Data Standard, Party Name

• ESCS ISB Business Data Standard, Party Relationship Name

• ESCS ISB Business Data Standard, Party Relationship Role

• ESCS ISB Controlled List, Party Name Component Type

• ESCS ISB Controlled List, Party Name Use Type

• ESCS ISB Standards Overview and Context

• ESCS ISB “System“ Enterprise Architecture - Business Data Architecture

• ESCS ISB Business Data Architecture Data Types

• ESCS ISB BDA Data Architecture Modelling Standards

• ESCS ISB Achieving Conformity with ISB Data Standards

File: Party-Name-Side-Note- Page 36 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

ANNEX A: LOGICAL WORKED EXAMPLES

These worked examples show the flexibility of the ISB Party data standards. There are additional examples shown as well as some previously used in the main body of this document

ISB Standard Party Name & Party Name Component entities 'LOGICALLY' define name component instances (or name parts)

Consider THAT Consider: Fiona Elizabeth Bruce (born 25 April 1964) - the British journalist, newsreader and television presenter. each 'Party_Name_D escription' set 12345678901234567890123456789012 Full 25/04/1964 1 n/a (null) Given Fiona of rows per 12345678901234567890123456789012 Full 25/04/1964 2 n/a (null) Given Elizabeth 'Party_Id' can have 0, 1 or 12345678901234567890123456789012 Full 25/04/1964 3 n/a (null) Family Bruce more 12345678901234567890123456789012 Known As 25/04/1964 1 n/a (null) Given Fiona 'Party_Name_T 12345678901234567890123456789012 Known As 25/04/1964 2 n/a (null) Family Bruce

Consider: George Iain Duncan Smith MP, IDS, born 9 April 1954 - the British politician.

00000000000002222222222222222244 Full 09/04/1954 1 n/a (null) Given George 00000000000002222222222222222244 Full 09/04/1954 2 n/a (null) Given Iain 00000000000002222222222222222244 Full 09/04/1954 3 n/a (null) Family Duncan Smith 00000000000002222222222222222244 Full 09/04/1954 4 n/a (null) Title MP 00000000000002222222222222222244 Known As 11/06/1987 1 n/a (null) Title The Right Honourable Nickname 00000000000002222222222222222244 Known As 11/06/1987 2 n/a (null) Given Iain used by 00000000000002222222222222222244 Known As 11/06/1987 3 n/a (null) Family Duncan Smith close family from birth 00000000000002222222222222222244 Known As 11/06/1987 4 n/a (null) Title MP 00000000000002222222222222222244 Known As 13/09/2001 1 n/a (null) Mononym IDS

Consider: Edson Arantes do Nascimento, nicknamed Dico & Pele, born 21 October 1940 - the retired Brazilian footballer

90911111111111111567722277111181 Full 21/10/1940 1 n/a (null) Given Edson 90911111111111111567722277111181 Full 21/10/1940 2 n/a (null) Family Arantes 90911111111111111567722277111181 Full 21/10/1940 3 n/a (null) Family do Nascimento Nickname 90911111111111111567722277111181 Known As 21/10/1940 1 n/a (null) Mononym Dico used by 90911111111111111567722277111181 Known As 01/12/1952 1 n/a (null) Mononym Pele

File: Party-Name-Side-Note- Page 37 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

57777777222777222277727727277722 Birth 23/10/1922 1 31/05/1953 Given Jean Recognises 57777777222777222277727727277722 Birth 23/10/1922 2 31/05/2013 Given Alys change of name on 57777777222777222277727727277722 Birth 23/10/1922 3 31/05/2013 Family Campbell-Harris marriage 57777777222777222277727727277722 Married 01/06/1954 1 n/a (null) Given Jean 57777777222777222277727727277722 Married 01/06/1954 2 n/a (null) Given Alys 57777777222777222277727727277722 Married 01/06/1954 3 n/a (null) Family Barker 57777777222777222277727727277722 Full 01/06/1954 1 n/a (null) Given Jean 57777777222777222277727727277722 Full 01/06/1954 2 n/a (null) Given Alys 57777777222777222277727727277722 Full 01/06/1954 3 n/a (null) Family Barker 57777777222777222277727727277722 Known As 15/01/2005 1 n/a (null) Title The Rt Hon the Recognises 57777777222777222277727727277722 Known As 15/01/2005 2 n/a (null) Title Baroness peerage and 57777777222777222277727727277722 Known As 15/01/2005 3 n/a (null) Given Trumpington additional honours 57777777222777222277727727277722 Known As 15/01/2005 4 n/a (null) Title DCVO 57777777222777222277727727277722 Known As 15/01/2005 5 n/a (null) Title PC

Consider: {a fictitious person} Mr Fred Jake Smith

12345600000000000000000000000001 Birth 01/01/1984 1 n/a (null) Given Frederick Recognises 12345600000000000000000000000001 Birth 01/01/1984 2 n/a (null) Given Jake change of title 12345600000000000000000000000001 on becoming an Birth 01/01/1984 3 n/a (null) Family Smith adult - perhaps 12345600000000000000000000000001 Full 01/01/1984 1 n/a (null) Given Fred not strictly 12345600000000000000000000000001 necessary as this Full 01/01/1984 2 n/a (null) Given Jake can be inferred 12345600000000000000000000000001 Full 01/01/1984 3 n/a (null) Family Smith by calculating age of majority 12345600000000000000000000000001 Known As 01/01/1984 1 31/12/1999 Title Master and gender of 12345600000000000000000000000001 Known As 01/01/1984 2 31/12/1999 Given Freddie person 12345600000000000000000000000001 Known As 01/01/1984 3 31/12/1999 Family Smith 12345600000000000000000000000001 Known As 01/01/2000 1 n/a (null) Title Mr 12345600000000000000000000000001 Known As 01/01/2000 2 n/a (null) Given Fred 12345600000000000000000000000001 Known As 01/01/2000 3 n/a (null) Family Smith 00000000000002222222222222222244 Known As 06/06/2005 1 n/a (null) Title Mr 00000000000002222222222222222244 Known As 06/06/2005 2 n/a (null) Given Fred 00000000000002222222222222222244 Known As 06/06/2005 3 n/a (null) Given Jake 00000000000002222222222222222244 Known As 06/06/2005 4 n/a (null) Family Smith

Consider: {a fictitious person} John Burt Smith declaring his name as follows:

123456733333555577 Full 25/05/1999 1 n/a (null) Given John 123456733333555577 Full 26/05/1999 2 n/a (null) Given Burt 123456733333555577 Full 27/05/1999 3 n/a (null) Family Smith

Consider: {a fictitious person} Mr Kwok Lee (where Kwok is the family name) declaring his name as follows:

775599673333512096 Full 25/05/1999 1 n/a (null) Title Mr 775599673333512096 Full 26/05/1999 2 n/a (null) Family Kwok 775599673333512096 Full 27/05/1999 3 n/a (null) Given Lee

File: Party-Name-Side-Note- Page 38 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

ANNEX B: PARTY NAME CONTROLLED LISTS

The controlled list values are provided in the individual ISB Controlled List documents. However, for the purposes of this side note the controlled list values at the time of the publication of this side note are included for clarity. For the latest controlled list values please refer to the individual ISB Controlled List documents on the ISB Website.

Party Name Component Type

Value Meaning example

Title A prefix or suffix added to a PERSONs name to Mr, Mrs, Mr, signify either veneration, an official position or a Master, Prof, professional or academic qualification. In some Dr, Sr, Jr, Ph. languages, titles may even be inserted between D., M.D., B.A. a first and last name (for example, Graf in etc German). Some titles are hereditary. Note, the title should be recorded as provided whether this is abbreviated or not is a decision of the name provider.

Given A given name is a personal name that specifies John, and differentiates between members of a group Margaret, of individuals. Ellie May, Mary-Kate In Western contexts the given name is often referred to as a first name or Christian name. In most European (and Europe-derived) cultures, the given name usually comes before the family name (though generally not in lists and catalogs), and so is known as a forename or first name; but the family name traditionally comes first in Hungary, parts of Africa and most of East Asia (eg China, Japan, Korea and Vietnam). In China, even part of the given name may be shared among all members of a given generation in a family and the family's extensions, to differentiate those generations from other generations.

Family A family name is typically a part of a person's Smith, name which has been passed, according to law or custom, from one or both parents to their children. The use of family names is common in many cultures around the world. Each culture

File: Party-Name-Side-Note- Page 39 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

has its own rules as to how these names are applied and used. In Western contexts the family name is often referred to as a surname or last name. In many cultures the family name is normally the last part of a person’s name. However, in some cultures (often referred to as the Eastern Order) the family name comes first.

Organisation The name of the Organisation. Name

Mononym A single name for a PERSON that is given or Sting, Plato adopted instead of a Given Name and Family Name combination. The Mononym may either be adopted by a PERSON or may be determined by the custom of a country.

Notes In the UK a married name can be either: • A family name or surname adopted by a person upon marriage. When a person assumes the family name of his or her spouse, this name replaces the person's original family name, which then becomes a maiden or birth name. The marriage certificate does not state what name will be adopted by the parties. • After marriage where the chosen family name adopted may be a double barreled name combining both the husband and wife’s name, a change by deed poll will be necessary in order to be able to furnish evidence of your identity under the adopted family name.

Helpful External References (1) http://en.wikipedia.org/wiki/Title (2) http://en.wikipedia.org/wiki/Given_name (3) http://en.wikipedia.org/wiki/Family_name (4) http://en.wikipedia.org/wiki/Married_and_maiden_names

File: Party-Name-Side-Note- Page 40 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

Party Name Use Type These name use types are dependent upon the name Party Roles identified in the various Business Use Cases but need to reflect real world examples. The below are the generically known Party Name Use Types extracted from the Business Use Cases at the time of writing this side note.

Value Meaning example

Award Name The name that a PERSON chooses to use on an Award certificate

Subject Name The name a PERSON chooses to use when they are the subject of, for example, an application

Preferred Name The name a PERSON chooses to declare that is different to the legal name used on, for example, an enrolment

Applicant Name The name a PERSON chooses to use when they are the requestor, for example, on an application

Notes Although the term 'Preferred Name' is contained in this 'Party_Name_Use_Type' it should be noted that this CL is not actually part of the published ‘Party Name BDS’. The requirement is however addressed in the ‘Party Name BDS’ by an unconstrained entry of 'Preferred' in the 'Party_Name_Description' attribute.

File: Party-Name-Side-Note- Page 41 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016

Party Name Side Note

© Crown copyright 2016 The Information Standards Board (ISB) is an advisory body to the Department for Education (DfE) and the Department for Business, Innovation and Skills (BIS). The information it produces is subject to Crown copyright, which is administered by the National Archives. The Crown copyright protected information in this document (other than ISB or Departmental logos) may be reproduced free of charge in any format or medium under the terms of the Open Government Licence, available from the National Archives website. Any reuse is subject to the material being reproduced accurately and not used in a misleading context. It must be acknowledged as being protected by Crown copyright and the title of the source material must be supplied with the ISB named as the corporate author. Authorisation to reproduce any information in this standard which is identified as being the copyright of a third party must be obtained from the copyright holders concerned.

File: Party-Name-Side-Note- Page 42 of 42 Version: 2.0 v2-0 Status: Approved: Recommended Issue Date: 26/04/2016