1. FEADRM Person Person Harmonization Workgroup Data Architecture Subcommittee Meeting January 11, 2007

2. Thursday, January 11, 20072 Gathering Information We asked those on the workgroup to share their models of PERSON with us. We received documents from the Department of the Interior (DOI), the Veterans Administration (VA), the Federal Aviation Administration (FAA), and the Environmental Protection Agency (EPA). You can view them on CORE.gov at https://collab.core.gov/CommunityBrowser.asp x?id=10833

3. Thursday, January 11, 20073 Analyzing the Data We compared the entities and attributes from all the documentation. We created an Excel Workbook. The first sheet contains all the entities and attributes from each model. The second sheet contains a mapping of the entities from the other agencies to those of the Social Security Administration (SSA) The third sheets contains the entities, attributes, and their definitions from the SSA FEADRM Model The Excel document is named Person Entities and Attributes from Various Feds and you can view it on CORE.gov at https://collab.core.gov/CommunityBrowser.aspx?id=11682

4. Thursday, January 11, 20074 Producing a FEADRM PERSON Model We started with an extract of the SSA Enterprise Data Model (EDM). We model using entity relationship diagrams (ERD) in the ERwin tool. We adjusted it to make it less SSA-centric and to include granularity required to span agencies. We named it Federal Enterprise Architecture Data Reference Model Person and defined it as This Business Data Model (BDM) is a view of the United States Government Enterprise Data Model (EDM) containing the data required to support the characterization and relationships of a uniquely identified person. You can view it as a pdf document on CORE.gov at https://collab.core.gov/CommunityBrowser.aspx?id=11892. The ERD starts on page 3 and the subject areas are in alphabetical order. If you have ERwin, contact us and we can send you the model in that format. https://collab.core.gov/CommunityBrowser.aspx?id=11892

5. Thursday, January 11, 20075 Observations A data model should have a point of view, we should have a common one at the Federal level. Everyone should be modeling business data rather than creating logical data base models. PERSON is probably the area in which resides most of the non- administrative sharable data. This is what we at SSA call common shared. The definition of business concepts represented by entities at the top of the data model should not be in terms so rigorously tied to the business of any one agency. Data that are regulated require formal agreement to be sharable. PERSON cannot be addressed in a vacuum. The concepts of organization, party, and role should be addressed at the same time.

6. Thursday, January 11, 20076 Challenges Allowing aliases in naming without underlying concept creep Identifying an authoritative source for a concept Formalizing a vocabulary for naming Agreeing on the description notation at the Business Reference Model level Managing configurations and versions Structuring a process for DRM governance

7. Thursday, January 11, 20077 SSA Disciplines Lexicon of Terms Rigorously enforced naming standards Logical value tables Business Data Models (views of Enterprise Data Models that support specific business functions or projects.) Availability of the above on the SSA intranet website

8. Thursday, January 11, 20078 Proposed Next Steps Sponsor a conference call to discuss these artifacts Publish DRAFT Scope Statement Publish DRAFT Objectives Establish guidelines for BRM relationships Establish guidelines for SRM relationships Initiate contacts to evaluate NIEM Establish guidelines for data exchange

9. Thursday, January 11, 20079 SSA Contacts Bob Ridgely OESAE Technical Advisor for Data Administration & Enterprise Architecture 410.965.3849 Bob.Ridgely@ssa.gov Kay Sybert SSA Enterprise Data Modeler DCS, OESAE, DEADA 4-M-19-a Operations 443.514.7531 kay.sybert@ssa.gov Nicholas Martin SSA Business Data Modeler OESAE/ DEADA/ DAB nicholas.l.martin@ssa.gov 410.965.5669