Enterprise Data Planning

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

Information Security Category Settings
Create Enterprise Data Dictionary

Create the Enterprise Data Dictionary
Enterprise Data Dictionary,
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.

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

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.
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
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:
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.
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.
E. Approve the Subject Area name and definition.

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.
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,
Existing entities,
Enterprise Data
Design
Search for Project

metadata from
Enterprise Data
Model
Proposed Enterprise entities,

reusable
meta data
Project Logical
Data Design
Logical Data Design
Data Architect
Review
1.3.1 Define Enterprise Business Entities

Architect,
Data Architect,
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:
Architect,
Data Architect,
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

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:
Architect,
Data Architect,
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.
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.

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:
Architect,
Data Architect,
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.
B. Determine whether the business function needs only

current information or if past and/or cumulative states
are also required for business operation.
C. Name each entity state using an adjective; name the

transition with a noun or verb phrase that describes
what is happening.

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.

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.)
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:
Architect,
Data Architect,
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,
Data Steward
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.
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.
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.
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.
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.
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.
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.
during information security definition activities:
Activities and Related Standards in this chapter:

DM OP 021 Standards for Assigning Information Security Categories
Deliverable(s):
Information Security Category Settings
1.4.1 Assign Information Security Categories

Architect,
Data Architect,
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.
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.
during enterprise model publication:
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.

Enterprise Data Planning

Uploaded by

Copyright:

Available Formats

Enterprise Data Planning

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Enterprise Data Planning

Uploaded by

Copyright:

Available Formats

1.