1.

Enterprise Data Planning

Introduction:
Enterprise data planning is a strategy for CMS business-focused data standardization. Its objective is to
strengthen the agencys 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
CMSs 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
Architect

A. When the need arises for business alignment of the data

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

Architect

B. Schedule Business Intelligence Council work sessions.

See DM G-013 Guideline for Guidelines for Conducting
Enterprise Data work sessions.

1.1.2 Model Business Function Processes

BIC Participants:
Facilitator,
Enterprise Business Line
Architect, Business Owner /
Partner,
Data Stewards,
Data Architect

Note: This process guides the development of an

enterprise business process from Level 0, which
coincides with charted CMS agency functions as
designated in the FEA-BRM. See CMS Business
Reference Model.
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 models scope and the business
function being represented. Without this defined scope,
the model might over reach or under represent the scope
of the business-lines 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

Architect,
Data Architect

D. Based on work session analyses develop a business

process diagram to document business processes and
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 projectlevel 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
agencys 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
Architect

A. Contact the Business Intelligence Council for the

Subject Area and schedule work sessions. See DM G012 Guidelines for Assigning Data Planning
Participants.

BIC Participants:
Enterprise Business Line
Architect,
Data Architect,
Business Owner /Partner,
Data Steward

B. Collaborate to define the business line Subject Area

and the core business entities that are used in the
course of business line operation.
Follow DM G-015 Guidelines for Defining a Subject
Area.

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.

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.

All BIC participants

E. Approve the Subject Area name and definition.

Business Owner /Partner,

Business Sponsor

F. Publish Subject Area name and definition.

Data Architect

CRUDA

CRU
DA
R

PLAN

BENEFICIARY

PROVIDER

CLAIM

BENEFICIARY
ENROLLMENT
CLAIMS PROCESSING
SUPPLIER
CERTIFICATION
HUMAN RESOURCES
RESEARCH STATISTICS
FACILITIES
ADMINISTRATION

FACILITY

SUBJECT AREA

EMPLOYEE

ENTITY NAME

ENTITLEMENT

Exhibit 3. Example Hypothetical CRUD Matrix

U
R

CRUDA
R
R
CRUDA

Exhibit 4. Subject Areas: Alignment and Shared Data Architecture

Subject Areas: Alignment and Shared Data Architecture

Data Subject
New standardized
Enterprise entities,
attributes, and
relationships

Existing Enterprise
entities,
attributes, and
relationships

Search for Project

metadata from
Enterprise Data
Model

Enterprise Data
Design

reusable
meta
data

Project Logical
Data Design

project
meta
data

Data Architect
Review

Proposed new Enterprise

entities,
attributes, and relationships

Logical Data Design

Subject Area Alignment Method

Business Function A

Business Function B

Business Function C

Data Subject Area X (entity use)

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

Data Subject Area Z

(entity use)

Area Z
Entities
origin &
stewardship

Subject Area Shared Data Architecture

Area X
Entities
origin &
stewardship

The top figure shows how

Subject Areas anchor the
starting points and end points
for data architecture business
alignment.
The bottom figure shows how
Subject Areas support data
sharing across agency
business functions and
interoperability with other
organizations.

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
(Exceptions may apply)
Proper Entities
Weak Entities
Relationships
Constraints
Some Attributes
Domain Values
Normalized Entities

Enterprise Data
Model

Project Logical
Data Model

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

Search for Project

metadata from
Enterprise Data
Model

Proposed Enterprise entities,

attributes, and relationships
reusable
meta data

Project Logical
Data Design

Logical Data Design

Data Architect
Review

1.3.1 Define Enterprise Business Entities

Enterprise Business Line
Architect,
Data Architect,
Business Owner /Partner,
Data Steward

A. Qualify a core business entity using this criteria:

1.) An entity must be a person, place, thing, or event
that business personnel would recognize as an asset,
occurrence or participant of central importance in the
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:
Enterprise Business Line
Architect,
Data Architect,
Business Owner /Partner,
Data Steward

B. Definitions of Enterprise Entities must be

comprehensive, documenting all their aspects in a
manner that enables appropriate data sharing and
information exchange by multiple organizations.
See Example Enterprise Entity Definition.

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
agencys 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,

Data Steward

F. Serve as the primary arbiters and final authorities of

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
Allowable States

Title XVIII of the Social Security Act

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

State Change

Primary Identifier

MEDICARE CLAIM NUMBER (HICN)

Information Security
Categories

Confidentiality HIGH
Integrity HIGH
Availability MODERATE
Enrollment and Eligibility

Primary Subject Area

1.3.2 Define Entity Relationships

BIC Participants:
Enterprise Business Line
Architect,
Data Architect,
Business Owner /Partner,
Data Steward

A. Qualify relationships between enterprise entities using

this criteria:
1.) The relationship must be an important association
between occurrences of one or more Enterprise
Entities that has some information value for the
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,

Data Steward

D. Serve as the primary arbiters and final authorities of

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.
A resulting relationship is deleted whenever a particular PROVIDER
is deleted.

2.

State Change

N/A

Primary Identifier

N/A

Primary Subject Area

Claims & Utilization

1.3.3 Analyze and Define Entity States

BIC Participants:
Enterprise Business Line
Architect,
Data Architect,
Business Owner /Partner,
Data Steward

A. For each entity and relationship that has a possibility

of multiple states, create an entity state / transition
diagram. This helps to ensure that all possible entity
states are identified.

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

Architect

D. Provide the Data Architect with a graphical

representation of the entitys 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

Architect

E. Document the business processes that create, read,

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 entitys 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
PRIVILEGE

STATE

1.
Ineligible Part
A / Ineligible
Part B

Active
Beneficiary
Part A fit
& paid

1 year
without claim
Enrollment
renewal

Part Aprem
unpaid/
vol withdrwl
/
dsblty ends/,
qual rel ends

2.
Eligible Part
A / Ineligible
Part B

Part Aprem
unpaid/
vol withdrwl /
dsblty ends/,
qual rel
ends;
Part Bprem
unpaid/
vol withdrwl /
dsblty ends/,
qual rel ends

Inactive
Beneficiary

1 year
inactive

part B:
prem
unpaid/
vol withdrwl
/
dsblty ends/,
qual rel ends

disable
d

3.
Ineligible Part
A / Eligible
Part B

Part Aprem
unpaid/
vol withdrwl
/
dsblty ends/,
qual rel ends

part B:
prem
unpaid/
vol withdrwl
/
dsblty ends/,
qual rel ends

Part B fit
& paid

part A fit
& paid

Deleted
Beneficiary

Part B fit
& paid

4.
Eligible Part
A / Eligible
Part B

1.3.4 Determine Entity Identifiers

G. Determine the primary entity identifier that is unique,
stable, and minimal for each entity in the EDM. This
is the identifier that a business line uses to distinguish
individual occurrences of an entity.

BIC Participants:
Enterprise Business Line
Architect,
Data Architect,
Business Owner /Partner,
Data Steward

H. Do not use software generated values as enterprise

entity identifiers.

All BIC Participants

1.3.5 Define Enterprise Attributes

Participants:
Data Architect,
Business Owner /Partner,
Data Steward

All BIC Participants

A. Here are the rules-of thumb for creating an Enterprise

Attribute:
Limit Enterprise Attributes to major facts about
an entity.

Create an Enterprise Attribute when it represents

a Data Element that is essential to multiorganization 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.

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
type
Prime /
Atomic

Definition

Example

Description

A basic
business
fact

Department

Derived

A value
that can be
formulated
using
values from
other
attributes.
Attributes
that are
usually
processed
together for
business
meaning
Interface
Data

Invoice
Total

Basic
information
about the
business
Computed
from the
sum of
invoice
lines.

Cohesive

Transaction
/ Interface

Employee
First Name
and
Employee
Last Name

Neither is
very
meaningful
without the
other.

Activity
Data

Business
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 agencys list of approved standard terms.

All BIC Participants

All BIC Participants

F. Assign each new attribute a business name of the

following structure:
Position
1

Component
Object Class
Term
(Prime Word)

M/O
One mandatory
Object Class Term

Qualifier Term,
Property Term,
(Modifier Word)

One or more optional

Qualifier Term and/or Property
Term

Representation
Term
(Class Word)

Limited to one mandatory

Representation Term.

G. Verify that the new attribute name is compliant using the

full Operating Procedure for naming attributes DM OP012 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
Architect,
Data Architect,
Business Owner /Partner,
Data Steward

A.

Analyze the security categories for the Enterprise

Entities and attributes using standards and guidelines
in DM OP-021 Operating Procedure for Assigning
Information Security Categories.
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

Security
Objective
Confidentiality
Preserving
authorized
restrictions on
information access
and disclosure,
including means
for protecting
personal privacy
and proprietary
information.
[44
USC,SEC.3542]
Integrity
Guarding against
improper
information
modification or
destruction, and
includes ensuring
information nonrepudiation and
authenticity.
[44
USC,SEC.3542]
Availability
Ensuring timely
and reliable access
to and use of
information.
[44
USC,SEC.3542]

LOW

POTENTIAL IMPACTS
MODERATE
HIGH

The authorized
disclosure of
information could
be expected to
have a limited
adverse effect on
organizational
operations,
organizational
assets, or
individuals.

The authorized
disclosure of
information could
be expected to
have a serious
adverse effect on
organizational
operations,
organizational
assets, or
individuals

The authorized
disclosure of
information could
be expected to
have a severe or
catastrophic
adverse effect on
organizational
operations,
organizational
assets, or
individuals

The unauthorized
modification or
destruction of
information could
be expected to
have a limited
adverse effect on
organizational
operations,
organization
assets, or
individuals.

The unauthorized
modification or
destruction of
information could
be expected to
have a serious
adverse effect on
organizational
operations,
organization
assets, or
individuals.

The disruption of
access to or use of
information or an
information
system could be
expected to have a
limited adverse
effect on
organizational
operations,
organizational
assets, or
individuals.

The disruption of
access to or use of
information or an
information
system could be
expected to have a
serious adverse
effect on
organizational
operations,
organizational
assets, or
individuals.

The unauthorized
modification or
destruction of
information could
be expected to
have a severe or
catastrophic
adverse effect on
organizational
operations,
organization
assets, or
individuals.
The disruption of
access to or use of
information or an
information
system could be
expected to have a
severe or
catastrophic
adverse effect on
organizational
operations,
organizational
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
agencys data model management tool when work is
completed (or halted in an incomplete or unapproved status).

Data Architect

B. Confirm EDM publication.