Party Name Side Note
Total Page:16
File Type:pdf, Size:1020Kb
ISB Publication Doc Ref: ISB-000075 Party Name Side Note 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 © Crown copyright 2016 Party Name Side Note 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