1.

Enterprise Data Planning

Introduction:
Enterprise data planning is a strategy for CMS business-focused data standardization. Its objective is to
strengthen the agency’s ability to manage and share data and information.

NOTE: There are references within this section that refer the reader to the Operating Procedures and
Guidelines section. Please download the Operating Procedures and Guidelines section to view
these references.

The major Enterprise Data Planning products are:

‚ Enterprise data objects in the form of Subject Areas and Enterprise Data Entities (Supertypes);
and Enterprise Attributes (Data Elements); and
‚ Information Security Category settings that establish the controls for appropriate use of CMS
data resources.

The Enterprise Data Planning process diagram depicts the milestones, control points, and deliverables as
they occur during the following steps:
ƒ Initiate Enterprise Data Planning
ƒ Define Enterprise Subject Areas
ƒ Model Enterprise Data
ƒ Assign Information Security Categories
ƒ Create the EDM Metadata Repository
ƒ Publish the Enterprise Data Model

Activities in this process are directed by the CMS Enterprise Data Architecture Approach.

Key Deliverables:
The Enterprise Data Planning process creates the following deliverables:
‚ Business Process Model
‚ Enterprise Subject Area Definitions,
‚ Subject Area Create Read Update Delete Archive (CRUDA) Matrix,
‚ Enterprise Data Model,
‚ Enterprise Metadata Repository,
‚ Business Terms,
‚ Enterprise Data Architecture for Repository update.
Exhibit 1. Enterprise Data Planning process diagram

Enterprise Data Planning

Enterprise Data Planning

Initiate Enterprise Data Planning

Assign Data Planning Resources

Collaborative Enterprise Group Participants

Model Business Function Processes

Business Process Model

Define Subject Areas

Define a Subject Area

Subject Area Model
Subject Area Definitions
Subject Area CRUDA Matrix

Model the EDM

Define Enterprise Entities

Updated Subject Area CRUDA Matrix

Business Terms

Define Entity Relationships

Draft Enterprise Data Model

Analyze Entity States

Entity State-Transition documents

Determine Entity Identifiers

Unique Identifying Facts about Entities

Define Enterprise Attributes

Attributed Enterprise Data Model
Business Terms

Assign Information Security Categories

Assign Information Security Categories

Information Security Category Settings

Create Enterprise Data Dictionary

Create the Enterprise Data Dictionary

Enterprise Data Dictionary,

Publish the Enterprise Data Model

Publish the Enterprise Data Model

Enterprise Data Model

Enterprise Data Architecture
CMS Enterprise Data Architecture Approach

The CMS Enterprise Data Architecture approach is based on the anticipated direction of the Federal
Enterprise Architecture Program (FEA).

Exhibit 2 is based on information from the FEA Data Reference Model (DRM) Volume I, Version 1. The
CMS operating polices comply with this direction.

To confirm the alignment between the FEA and CMS data architectures: compare the DRM Subject Area
prototype with the CMS Subject Area; compare the DRM Super Type with the CMS Enterprise Entity;
and compare the DRM Data Element to the CMS Enterprise Attributes, which are added to the EDM to
facilitate the integrity of Information Flow across multiple business functions.

Exhibit 2. FEA Data Reference Model (DRM) Structure

1.1. Initiate Enterprise Data Planning
Introduction:

Enterprise Data Planning activities might be initiated by one of several circumstances:

1. In response to mandates from Federal Enterprise Architecture (FEA) Program Management
Office for managed data architecture;
2. In response to needs for sharing data and interoperability between internal and external
organizations;
3. On behalf of CMS management to promote the quality and integrity of business function data;
and
4. To accommodate the data architecture requirements precipitated by change in agency business
line functions.

This process describes the first step in enterprise data planning, which establishes an enterprise-level
decision making task group(s) –Business Intelligence Council (BIC)-- by assigning participants from
CMS’s EA team, business organizations, and the IT data management organization.

Analysis of the business processes starts with written descriptions and ends with diagrams to aid BIC
work session communication.

The following processes depict the participant roles, milestones, control points, and deliverables occur
during data planning activities:

ƒ Assign Data Planning Participants

‚ DM G-012 Guideline for Assigning Data Planning Participants
‚ DM G-013 Guideline for Guidelines for Conducting Enterprise Data work sessions
ƒ Model Business Function Processes
‚ DM G-014 Guideline for Creating a Business Process Diagram

Deliverable(s):
ƒ List of Business Intelligence Council Participants
ƒ Business Process Model(s)

1.1.1 Assign Data Planning Participants

Enterprise Business Line A. When the need arises for business alignment of the data
Architect architecture, contact the respective Business Intelligence
Council participant (participants shall be established for
each major CMS business line). Follow the guidelines in
DM G-012 Guidelines for Assigning Data Planning
Participants.
Update the Business Intelligence Council (BIC) Matrix to
document any newly organized groups and individual
participants.
 Enterprise Business Line B. Schedule Business Intelligence Council work sessions.
Architect See DM G-013 Guideline for Guidelines for Conducting
Enterprise Data work sessions.

1.1.2 Model Business Function Processes

BIC Participants: Note: This process guides the development of an

Facilitator, enterprise business process from Level 0, which
Enterprise Business Line coincides with charted CMS agency functions as
Architect, Business Owner / designated in the FEA-BRM. See CMS Business
Partner, Reference Model.
Data Stewards,
Data Architect A. Participate in the work session to create an enterprise
process model. This will help the business personnel
and IT architects to visualize enterprise activities.

All BIC participants B. Develop a Statement of Purpose for the enterprise

process model to ensure that the BIC participants are
fully aware of the model’s scope and the business
function being represented. Without this defined scope,
the model might over reach or under represent the scope
of the business-line’s functions.

All BIC participants C. Identify the inputs, outputs, controls, and activities that
make up the business functions to show what
information is transformed by the business functions.
Later, this information will be analyzed in terms of its
business Subject Area and the core enterprise entities the
business-line functions need to know about.

Enterprise Business Line D. Based on work session analyses develop a business

Architect, process diagram to document business processes and
Data Architect information flows. See DM G-014 Guideline for
Creating a Business Process Diagram.
1.2. Define Subject Areas
Introduction:
Subject Areas are group classifications of business data entities at their highest level of data object
abstraction. They are defined during Enterprise Data Planning and are not usually affected by project-
level changes in business data. Only on those rare occasions when CMS is chartered with a new line of
business or the charter for an existing line of business changes or ends, will a Subject Area be added,
redefined, or removed. See the current CMS Subject Area Model, CMS Subject Area Definitions, and
Business Intelligence Council (BIC) Participants.

Despite rarely being changed, Subject Areas are routinely used in the strategic management of the
agency’s data architecture. First, Subject Areas anchor the starting points and end points for data
architecture business alignment. Second, they support data sharing across agency business functions and
interoperability with other organizations. This concept is illustrated in Subject Areas: Alignment and
Shared Data Architecture.

The following processes depict the participant roles, milestones, control points, and deliverables occur
during subject area definition activities:
ƒ Define Subject Areas
‚ DM G-015 Guidelines for Defining a Subject Area

Deliverable(s):
ƒ Updated Subject Area Model and Subject Area Definition(s)
ƒ Subject Area CRUDA Matrix

1.2.1 Define a Subject Area

Enterprise Business Line A. Contact the Business Intelligence Council for the
Architect Subject Area and schedule work sessions. See DM G-
012 Guidelines for Assigning Data Planning
Participants.

BIC Participants: B. Collaborate to define the business line Subject Area

Enterprise Business Line and the core business entities that are used in the
Architect, course of business line operation.
Data Architect, Follow DM G-015 Guidelines for Defining a Subject
Business Owner /Partner, Area.
Data Steward

All BIC participants C. Define a Subject Area in a manner that: 1.) explains
the business functions that use it; 2.) represents the
entity group it contains; and 3.) identifies the business
organizations that are primarily responsible for its
upkeep.
All BIC participants D. Create an Enterprise Subject Area CRUDA Matrix and
make an entry for each core Subject Area entity. See
Example CRUDA Matrix. This matrix will be used
during entity analysis to document processes that
Create, Read, Update, Delete, and Archive the Subject
Area entities. Entity analysis activities are described
under topic Model Enterprise Data.

Business Owner /Partner, E. Approve the Subject Area name and definition.
Business Sponsor

Data Architect F. Publish Subject Area name and definition.

Exhibit 3. Example Hypothetical CRUD Matrix

ENTITY NAME

ENTITLEMENT
BENEFICIARY
EMPLOYEE

PROVIDER
FACILITY

SUBJECT AREA
CLAIM

PLAN
BENEFICIARY CRU R
ENROLLMENT DA
CLAIMS PROCESSING CRUDA R R R
SUPPLIER U
CERTIFICATION
HUMAN RESOURCES CRUDA
RESEARCH STATISTICS R R R R R R R
FACILITIES CRUDA
ADMINISTRATION
Exhibit 4. Subject Areas: Alignment and Shared Data Architecture
Subject Areas: Alignment and Shared Data Architecture

Data Subject
New standardized
Enterprise entities,
attributes, and
Existing Enterprise relationships
entities,
attributes, and
relationships Enterprise Data
Design

Proposed new Enterprise

Search for Project entities,
reusable project attributes, and relationships
metadata from Project Logical Data Architect
meta meta
Enterprise Data Data Design Review
data data
Model

Logical Data Design

Subject Area Alignment Method

The top figure shows how

Subject Areas anchor the
Business Function A Business Function B Business Function C starting points and end points
for data architecture business
alignment.

Area X The bottom figure shows how

Data Subject Area X (entity use)
Entities Subject Areas support data
origin &
stewardship sharing across agency
business functions and
interoperability with other
organizations.
Area Y Entities
origin &
stewardship

Data Subject Area Y (entity use)

Area Z
Data Subject Area Z Entities
(entity use) origin &
stewardship

Subject Area Shared Data Architecture

1.3. Model Enterprise Data
Introduction:

This process creates the Enterprise Data Model (EDM), which is a conceptual or semantic data model for
business use. Its objective is to synthesize common entity meanings across agency business functions and
to move the agency toward interoperable data architecture through stable, non-redundant shared data and
reusable information exchange structures.
‚ The EDM is a “living” model. As such, it provides reusable data artifacts to new projects
and, during the course of project logical data modeling, is updated with new and
discovered data artifacts whose make-up suggest their potential for reuse across multiple
business-line information processes.
‚ The EDM serves as the reference of the ideal description and security designation of
important business data entities.

The following processes depict the participant roles, milestones, control points, and deliverables occur
during enterprise data design activities:

ƒ Define Enterprise Business Entities

ƒ Define Entity Relationships
ƒ Analyze Entity States
ƒ Determine Entity Identifiers
ƒ Define Enterprise Attributes

Additional information related to enterprise data design is:

ƒ Contents Comparison: An Enterprise Data Model to A Project Logical Data Model
ƒ Maintaining the EDM Architecture diagram

Key Deliverables:
The Enterprise Data Design process creates the following SDLC deliverables:
‚ Entity State-Transition documents
‚ Updated Subject Area CRUDA Matrix
‚ Business Terms
‚ Draft Enterprise Data Model
Exhibit 5. Contents Comparison: An Enterprise Data Model to A Project Logical Data Model
Usual Components of a Data Model Enterprise Data Project Logical
(Exceptions may apply) Model Data Model
Proper Entities √ √
Weak Entities √
Relationships √ √
Constraints √
Some Attributes √ √
Domain Values √ √
Normalized Entities √

Exhibit 6. Maintaining the EDM

Maintaining the Enterprise Data Model / Architecture

Data Subject
New standardized
Enterprise entities,
attributes, and relationships

Existing entities,
attributes, and relationships
Enterprise Data
Design

Proposed Enterprise entities,

Search for Project attributes, and relationships
metadata from reusable Project Logical Data Architect
Enterprise Data meta data Data Design Review
Model

Logical Data Design

1.3.1 Define Enterprise Business Entities

Enterprise Business Line A. Qualify a core business entity using this criteria:
Architect, 1.) An entity must be a person, place, thing, or event
Data Architect, that business personnel would recognize as an asset,
Business Owner /Partner, occurrence or participant of central importance in the
Data Steward business function. Weak entities are typically
excluded. (A weak entity is an entity which exists only
as a subordinate part of a more fundamental entity.
For example, the weak entity Practice Location has no
meaning without the fundamental entity Provider.)
Weak entities are included when they are themselves
the focus of individual data exchanges.
2.) An entity must be something that a business
function collects and maintains information about.
3.) The business must have a way to uniquely
distinguish occurrences of the entity.
4.) Do not represent data that is only used for system
control (such as access control, interface behavior,
workflow routing, database auditing).
5.) Do not represent data that is only exchanged
between systems and never viewed by the CMS
business community or their business partners.

BIC Participants: B. Definitions of Enterprise Entities must be

Enterprise Business Line comprehensive, documenting all their aspects in a
Architect, manner that enables appropriate data sharing and
Data Architect, information exchange by multiple organizations.
Business Owner /Partner, See Example Enterprise Entity Definition.
Data Steward

Data Architect C. Before naming new entities, have the list of approved
business Standard Terms available. This information
is available in the Standard Terms and Abbreviations
List. The Standard and Abbreviations Terms List is
available from the Standards Terms page (accessible
from the Data Administration home web page). If a
needed term is not on the list, follow the procedure
outlined on the Standard Terms page.

This enterprise data analysis activity is one of the key

sources for selecting the business terms that form the
agency’s approved term glossary.
 Project Data Analyst D. Assign meaningful entity names using approved
business terms according to DM OP-009 Operating
Procedure for Naming New Data Entities. The
objective of naming standards is to foster a common
reference of CMS data.
A shortened version of the naming procedure is
available as a quick reference in DM OP-009-QR
Quick Reference for Naming Data Entities.

Data Architect E. Add each qualified entity to the EDM using the
standard data modeling tool. See Data Modeling tool
standard for Creating Conceptual Data Models

Business Owner /Partner, F. Serve as the primary arbiters and final authorities of
Data Steward Enterprise Entity definitions.
Exhibit 7. Example Entity Definition
Name BENEFICIARY

Abbreviation BENE

Type Prime

Dependency N/A

Definition A person who has been registered by CMS to receive beneficiary entitlements of
Medicare services.

Business Rules Title XVIII of the Social Security Act

Allowable States Activity States
1. Active: Beneficiary has made claims within the last (1) year.
2. Inactive: Beneficiary has made no claims within the last (1) year.
3. Inactive: Beneficiary is deceased.
Privilege States
1. Eligible for Part A: Beneficiary is able to receive paid services under
Medicare Part A.
2. Ineligible for Part A: Beneficiary is not to receive paid services under
Medicare Part A.
3. Eligible for Part B: Beneficiary is able to receive paid services under
Medicare Part B.
4. Ineligible for Part B: Beneficiary is not to receive paid services under
Medicare Part B.

Create Rules A BENEFICIARY is created upon successful completion of the enrollment process.
BENEFICIARY is created:
Activity State =Active;
Privilege States= Eligible for Part A, Ineligible for Part B.
State Change 1. A BENEFICIARY is changed from Active state to Inactive if they have made
no claims in past one (1) year.
2. A BENEFICIARY in Active state may enter privilege state Eligible for Part A
upon registration in the program
3. A BENEFICIARY in Active state may enter privilege state Eligible for Part B
if “Part B fit and paid”
4. A BENEFICIARY in Active state may re-enter privilege state Ineligible for
Part A if: voluntary withdrawal, unpaid Premium, qualifying relationship
ends, cessation of disability
5. A BENEFICIARY in Active state may enter privilege state Ineligible for Part
B if : voluntary withdrawal, unpaid Premium, qualifying relationship ends,
cessation of disability, and disabled

Primary Identifier MEDICARE CLAIM NUMBER (HICN)

Information Security Confidentiality – HIGH

Categories Integrity – HIGH
Availability – MODERATE
Primary Subject Area Enrollment and Eligibility
1.3.2 Define Entity Relationships

BIC Participants: A. Qualify relationships between enterprise entities using

Enterprise Business Line this criteria:
Architect, 1.) The relationship must be an important association
Data Architect, between occurrences of one or more Enterprise
Business Owner /Partner, Entities that has some information value for the
Data Steward business.
2.) The relationship must represent something that the
business tracks and stores.
3.) The relationship must have a name that describes
the relationship.
4.) The relationship is to represent a static association.
See Example Entity / Relationship Diagram

Data Architect B. Add each qualified relationship between entities using

the standard data modeling tool as described in Data
Modeling Tool Standard For Creating Conceptual
Data Models.

All BIC participants C. The definitions of Enterprise Relationships must be

comprehensive, documenting all their aspects in a
manner that enables appropriate shared use by
multiple organizations.
See Example Enterprise Relationship Definition.

Business Owner /Partner, D. Serve as the primary arbiters and final authorities of
Data Steward Enterprise Relationship definitions.
Exhibit 8. Example Enterprise Relationship Definition
Name FILING

Abbreviation FILG

Definition A resulting relationship indicates that a CLAIM was filed for payment of
services rendered on behalf of a Medicare BENEFICIARY.

Business Rules Only Active PROVIDER sources are recognized.

Allowable States Activity States

4. Past: Indicates that the FILING took place.

Create Rules 1. A resulting relationship is created whenever a particular CLAIM was

made as a result of qualifying services.

Delete Rules 1. A resulting relationship is deleted whenever a particular CLAIM was

deemed erroneous.
2. A resulting relationship is deleted whenever a particular PROVIDER
is deleted.

State Change N/A

Primary Identifier N/A

Primary Subject Area Claims & Utilization

1.3.3 Analyze and Define Entity States

BIC Participants: A. For each entity and relationship that has a possibility
Enterprise Business Line of multiple states, create an entity state / transition
Architect, diagram. This helps to ensure that all possible entity
Data Architect, states are identified.
Business Owner /Partner,
Data Steward

All BIC participants B. Determine whether the business function needs only
current information or if past and/or cumulative states
are also required for business operation.

All BIC participants C. Name each entity state using an adjective; name the
transition with a noun or verb phrase that describes
what is happening.

Enterprise Business Line D. Provide the Data Architect with a graphical

Architect representation of the entity’s state and transition,
using an automated drawing tool that produces a
graphical image. The documents will be electronically
stored with the EDM. See Example State/Transition
Diagram.

Enterprise Business Line E. Document the business processes that create, read,
Architect update, delete or archive the entity in the Enterprise
Subject Area CRUDA Matrix. (See related Subject
Area activities in topic Define Subject Area.)

All BIC participants F. Any subsequent Project Logical Data Entity derived
from an Enterprise Entity must comply with its
identified entity states. Any new states discovered in
project logical data analysis must be submitted to the
Business Intelligence Council and the entity’s state
transition documents appropriately updated in order
that the Enterprise Entity stays aligned with the
business-line charter and mission.
Exhibit 9. Example State Transition Diagram

Example State Transition Diagram

Purpose: To assist business analyst in identifying possible object states

Initial
Medicare
Enrollment
STATE PRIVILEGE

1.
Ineligible Part
A / Ineligible
Active Part B
Beneficiary
Part A fit part B: Part B fit
& paid prem & paid
Part A-
unpaid/
prem
vol withdrwl
unpaid/
/ disable
vol withdrwl
dsblty ends/, d
/
1 year qual rel ends
dsblty ends/,
without claim qual rel ends Part A-
prem
unpaid/
Enrollment vol withdrwl /
renewal 2. dsblty ends/, 3.
qual rel
Eligible Part Ineligible Part
ends;
A / Ineligible A / Eligible
Part B Part B- Part B
prem
unpaid/
vol withdrwl /
Inactive dsblty ends/,
Beneficiary qual rel ends
Part A-
prem
part B: unpaid/
prem vol withdrwl
unpaid/ /
vol withdrwl dsblty ends/,
/ qual rel ends
1 year dsblty ends/, Part B fit
inactive qual rel ends & paid

part A fit
& paid

Deleted 4.
Beneficiary Eligible Part
A / Eligible
Part B
1.3.4 Determine Entity Identifiers

BIC Participants: G. Determine the primary entity identifier that is unique,

Enterprise Business Line stable, and minimal for each entity in the EDM. This
Architect, is the identifier that a business line uses to distinguish
Data Architect, individual occurrences of an entity.
Business Owner /Partner,
Data Steward

All BIC Participants H. Do not use software “generated” values as enterprise

entity identifiers.

1.3.5 Define Enterprise Attributes

Participants:
Data Architect, A. Here are the rules-of thumb for creating an Enterprise
Business Owner /Partner, Attribute:
Data Steward ‚ Limit Enterprise Attributes to major facts about
an entity.

‚ Create an Enterprise Attribute when it represents

a Data Element that is essential to multi-
organization Information Flow about the entity.
(See CMS Enterprise Data Architecture Approach
to understand how Enterprise Attributes
contribute to Information Flow.)

‚ Create an Enterprise Attribute when strict

compliance to a value domain or datatype domain
is essential to a critical business line operation.

‚ The major details about an enterprise entity are

usually described by less than a dozen attributes.

All BIC Participants B. Define the new Enterprise Attribute. The definition of a
new attribute shall comply with the Operating Procedure
described in DM OP-010 Operating Procedure for
Defining Data Attributes.

The above procedure is compliant with a prerequisite

standard ISO IEC 11179-4 Rules and guidelines for the
formulation of data definitions.
All BIC Participants C. The other factors to consider when creating a new
attribute require data analysis. The purpose of that
analysis is to classify new attributes into one of the
following categories.
Attribute Definition Example Description
type
Prime / A basic Department Basic
Atomic business information
fact about the
business
Derived A value Invoice Computed
that can be Total from the
formulated sum of
using invoice
values from lines.
other
attributes.
Cohesive Attributes Employee Neither is
that are First Name very
usually and meaningful
processed Employee without the
together for Last Name other.
business
meaning
Transaction Interface Activity Business
/ Interface Data Data required
data
exchange

See DM OP-011 Operating Procedure for Analyzing Data

Attributes Types for methods that can improve how the
attributes types are best modeled.

All BIC Participants D. Determine the types of data values that the attribute will
eventually represent then identify the appropriate data
type for each new attribute. See DM G-004 Guidelines
for Designating Representation Term and Data Type.

All BIC Participants E. Before new attributes are named, it would be helpful to
have a list of approved Standard Terms and uses on
hand. The Standard and Abbreviations Terms List is
available from the Standards Terms page (accessible
from the Data Administration home web page). If a
needed term is not on the list, follow the procedure
outlined on the Standard Terms page.

This activity in the enterprise data analysis process is one

of the key sources for identifying the business terms that
form the agency’s list of approved standard terms.
All BIC Participants F. Assign each new attribute a business name of the
following structure:
Position Component M/O
1 Object Class One mandatory
Term Object Class Term
(Prime Word)

2 Qualifier Term, One or more optional

Property Term, Qualifier Term and/or Property
(Modifier Word) Term

3 Representation Limited to one mandatory

Term Representation Term.
(Class Word)

All BIC Participants G. Verify that the new attribute name is compliant using the
full Operating Procedure for naming attributes DM OP-
012 Operating Procedure for Naming Data Attributes or
the quick reference DM OP-012-QR Quick Reference for
Naming Data Attributes.

The above procedure is compliant with a prerequisite

standard ISO IEC 11179-5 Naming and identification
principles for data elements.

All BIC Participants H. Apply the following information to each new attribute:
‚ optionality
‚ length
‚ data type
‚ security category

Project Data Analyst I. Attributes that represent dates must follow the rules
outlined in DM G-006 Standard for Assigning Date
Formats.

All BIC Participants J. Consider long-term management for electronic records

when adding new attributes to record types. Appropriate
classification of data types will facilitate easier archival
for those records with federal archival mandates.
1.4. Assign Information Security Categories
Introduction:
This process provides the standards for documenting information security categories for agency data
assets.

The following processes depict the participant roles, milestones, control points, and deliverables occur
during information security definition activities:

Activities and Related Standards in this chapter:

ƒ Assign Information Security Categories
‚ DM OP 021 Standards for Assigning Information Security Categories

Deliverable(s):
Information Security Category Settings

1.4.1 Assign Information Security Categories

Enterprise Business Line A. Analyze the security categories for the Enterprise
Architect, Entities and attributes using standards and guidelines
Data Architect, in DM OP-021 Operating Procedure for Assigning
Business Owner /Partner, Information Security Categories.
Data Steward
See Levels of Impact for Security Objectives for
setting descriptions.

This procedure supports the federal government

requirements outlined in FIPS Publication 199 –
Standards for Security Categorization of Federal
Information and Information Systems.

Data Architect B. Document the security and sensitivity rules and levels
of impact (low, moderate, and high) in the EDM or
project data models [where new attributes are defined]
following the format in Data Modeling Tool Standard
for Creating Conceptual Data Models
Exhibit 10. Levels of Impact for Security Objectives

POTENTIAL IMPACTS
Security LOW MODERATE HIGH
Objective
Confidentiality The authorized The authorized The authorized
Preserving disclosure of disclosure of disclosure of
authorized information could information could information could
restrictions on be expected to be expected to be expected to
information access have a limited have a serious have a severe or
and disclosure, adverse effect on adverse effect on catastrophic
including means organizational organizational adverse effect on
for protecting operations, operations, organizational
personal privacy organizational organizational operations,
and proprietary assets, or assets, or organizational
information. individuals. individuals assets, or
[44 individuals
USC,SEC.3542]
Integrity The unauthorized The unauthorized The unauthorized
Guarding against modification or modification or modification or
improper destruction of destruction of destruction of
information information could information could information could
modification or be expected to be expected to be expected to
destruction, and have a limited have a serious have a severe or
includes ensuring adverse effect on adverse effect on catastrophic
information non- organizational organizational adverse effect on
repudiation and operations, operations, organizational
authenticity. organization organization operations,
[44 assets, or assets, or organization
USC,SEC.3542] individuals. individuals. assets, or
individuals.
Availability The disruption of The disruption of The disruption of
Ensuring timely access to or use of access to or use of access to or use of
and reliable access information or an information or an information or an
to and use of information information information
information. system could be system could be system could be
[44 expected to have a expected to have a expected to have a
USC,SEC.3542] limited adverse serious adverse severe or
effect on effect on catastrophic
organizational organizational adverse effect on
operations, operations, organizational
organizational organizational operations,
assets, or assets, or organizational
individuals. individuals. assets, or
individuals.
1.5. Create the Enterprise Metadata Repository
Introduction
The Enterprise Metadata Repository reports information about Enterprise Entities and Attributes.

The following processes depict the participant roles, milestones, control points, and deliverables occur
during Metadata Repository preparation:

ƒ Create the Enterprise Metadata Repository

‚ DM OP-022 Operating Procedure for Creating the Project Metadata Repository

Deliverable(s):
ƒ Enterprise Metadata Repository

1.5.1 Creating the Enterprise Metadata Repository

Data Architect A. Draft an Enterprise Metadata Repository following DM

OP-022 Operating Procedure for Creating the Project
Metadata Repository.

Data Architect B. Generate the Enterprise Metadata Repository using the

Custom Report - Metadata Repository report options
available in Data Modeling Tool Standard for Creating
Project Logical Data Models

Data Architect C. Validate the Enterprise Metadata Repository with the

appropriate Data Steward(s).

Data Architect D. Submit the Metadata Repository Report to Subject Area

BIC Participants: Business Owner Partner and Data
Stewards for approval, making revisions as needed until
all parties are satisfied with dictionary contents.
1.6. Publish the Enterprise Data Model
Introduction:
This process describes the change control activities that catalogs and stores the EDM in the appropriate
model library and repository.

After the development work on the EDM ends, it must be published to facilitate ongoing analysis of
business line data and future business system changes. This will be accomplished through an automated
library and a repository. As the CMS data architecture mature, different analysts will be able to view their
interests in Enterprise Data, tracing them from abstract business data concepts to actual physical data
locations.

The following processes depict the participant roles, milestones, control points, and deliverables occur
during enterprise model publication:

ƒ Publish the Enterprise Data Model

Deliverable(s):
ƒ Published Enterprise Data Model
ƒ Updated Enterprise Data Architecture (repository updates)

1.6.1 Publish the Enterprise Data Model

Data Administration Analyst A. Accept the new EDM and publish the model according to
instructions in Production Change Control for Model
Management.

Note: All models shall be appropriately stored in the

agency’s data model management tool when work is
completed (or halted in an incomplete or unapproved status).

Data Architect B. Confirm EDM publication.