MetaVista Proposal HBE-DA-2011-01 Vol I Final

A Proposal For
California Department of Health Care Services
Information Technology Services Division
Enterprise Architecture Program
MS 6300, P.O. Box 997413
Sacramento, CA 95899-7413
May 17, 2011
Submitted By
MetaVista Consulting Group
2411 15th
Street, Suite A
Main Office: (916) 296-2290
Fax: (916) 443-4830
Health Benefits Exchange Project (HBE)
Senior Data Architect
RFO # HBE-DA-2011-01
Vol I: MetaVista Response

2 4 1 1 1 5
T H
S T R E E T • S U I T E A • S A C R A M E N T O • C A L I F O R N I A • 9 5 8 1 8 - 2 2 6 4
M e t a V i s t a C o n s u l t i n g G r o u p
.
w w w . m e t a v i s t a . c o m
.
( 9 1 6 ) 2 9 6 - 2 2 9 0
May 17, 201
California Department of Health Care Services
Information Technology Services Division
Enterprise Architecture Program
MS 6300, P.O. Box 997413
Attn: Ben Word
Re: Request for Offer (RFO) HBE-DA-2011-01
Mr. Word:
The MetaVista Consulting Group is pleased to submit this Proposal in response to RFO HBE-
DA-2011-01 for one Senior Data Architect for the Information Technology Services Division
(ITSD) Enterprise Architecture Program (EAP).
We understand the importance of this position as DHCS works toward developing a Health
Benefits Exchange in response to federal and state legislation, particularly since California is
taking the lead among states in the implementation of a Health Benefits Exchange. We further
realize that architectural decisions made during this phase of the HBE Project will have a
significant impact on the success of the project in coming years.
Our proposed Senior Data Architect has exceptional qualifications for performing the work
described in the RFO. His services have ranged from architecting complex enterprise systems
to developing individual components of n-tiered B2B, B2C & B2C architecture. He has
supported Business Intelligence exploration from the user experience to the system realization
and real-time operations. He strives to employ best practices and principals to maintain
accountability as well as seeking optimization to meet stakeholder goals.
We are confident that our resource and our approach will meet or exceed DHCS’ requirements,
and that our services will provide the best overall value to the State.
The information in the table below is provided per instructions in the RFO.
Company name, contact and address as
listed on the DGS contract
Jay M. Jackson
2411 15th
Street, Suite A
Sacramento, CA 95818
Name and email address of the contract
person
Jay M. Jackson
jjackson@metavista.com
DGS CMAS Contract Number 3-09-70-1454C
Small Business Number 17002
DVBE Certification Number N/A

Formal Offer for RFO HBE-DA-2011-01
Senior Data Architect
i i
Total Offer Amount $203,000
Signature of an individual authorized to
enter into contracts for the contractor
See below
We appreciate very much the opportunity to assist DHCS with this project, and we look forward
to contributing to its success. If you have any questions about our proposal, please contact me
at 916-549-1800 or by email at critchie@metavista.com. Or, contact Jay Jackson at 916-295-
6074 or by email at jjackson@metavista.com.
Sincerely,
Charles A. Ritchie, PMP
CIO and Principal Consultant
The above signed is authorized to bind MetaVista contractually.

Formal Offer for RFO #HBE-DA-2011-01
Data Architect Services
iii
Table of Contents
Table of Contents .........................................................................................................................iii

Understanding and Description of the Tasks to be Performed ..................................................... 1

Introduction ............................................................................................................................... 1

Mapping of RFO Services to MetaVista’s Response ................................................................ 1

Mapping of RFO Deliverables to MetaVista’s Response .......................................................... 3

Task Group 1: Data Architecture, Metadata, Methodology, Analysis, Modeling, and
Documentation ...................................................................................................................... 5

Task Group 2: Business Analysis, Stakeholder Requirements, and Team Leadership ...... 19

Task Group 3: Project Management, Coordination, Road Mapping, Scheduling, and
Meetings .............................................................................................................................. 21

Methods and Tools ..................................................................................................................... 23

Reference Methodologies, Processes and Standards................................................................ 24

Assumptions ............................................................................................................................... 27

Cost Data Sheet ......................................................................................................................... 28

Offer Totals ............................................................................................................................. 28

Amendments ........................................................................................................................... 28

Work Samples ............................................................................................................................ 29

Work Sample #1...................................................................................................................... 29

Work Sample #2...................................................................................................................... 29

Work Sample #3...................................................................................................................... 29

Work Sample #4...................................................................................................................... 29

Work Sample #5...................................................................................................................... 29

Work Sample #6...................................................................................................................... 29

CMAS Contract........................................................................................................................... 31

About MetaVista ......................................................................................................................... 32

Representative Projects .......................................................................................................... 32

Page 1 of 33 MetaVista Consulting Group Updated: 2011-05-17
Understanding and Description of the Tasks to be Performed
Introduction
MetaVista’s understanding of the work to be performed, and a description of the tasks we
propose in support of that work, appears in the material on the following pages.
MetaVista’s response organizes the tasks and deliverables into three Task Groups:
1. Data Architecture, Metadata, Methodology, Analysis, Modeling, and
Documentation. We estimate that these topics represent approximately 50% of the
overall effort described in the RFO.
2. Business Analysis, Stakeholder Requirements, Team Leadership. We estimate that
these topics represent approximately 30% of the effort associated with the RFO.
3. Project Management, Coordination, Road Mapping, Scheduling, and Meetings. We
estimate that these topics represent the remaining 20% of the effort associated with the
RFO.
To assist the reader in assessing our proposal, the tables below map each item identified in the
RFO under Description of Services, and maps the item to the relevant Task Group in
MetaVista’s response.
Mapping of RFO Services to MetaVista’s Response
Description of Services Reference
Develop an enterprise data model reflecting the data currently housed in
DHCS’ systems that represents DHCS’s Business Model by aligning with
the Information Architecture within the MITA Framework:
• Data Management Strategy
• Conceptual Data Model
• Logical Data Model
• Data Standards
Task Group 1
Establish the roadmap between the current data feeds to the future data
feeds as described in the CMS Pilot Project Medicaid and CHIP
Business Information Solution (MACBIS) Automated Data Management
project.
Task Group 3
Guide the creation and monitoring for the usage of data and information
as vital department assets.
Task Group 2
Review and provide comments for design of Logical Data models during
the Health Benefit Exchange (HBE) requirement analysis phase.
Task Group 1
Collaborate with industry and government data exchange leaders about
data integration techniques and methods needed to support new
payment and care coordination models.
Task Group 2
Introduce new data management methods and tools to manage provider
and beneficiary data at a state and national level
Task Group 1

Create a design for an Enterprise Master Person Index (EMPI) that can
be adopted by the CHHS as a standard.
Task Group 1
Lead core and extended EDA teams through the process of defining
EDA requirements, principles and models. This includes developing a
charter that is based on goals and objectives, and defining roles and
responsibilities.
Task Group 2
Participate in the development of data governance processes and
procedures.
Task Group 1
Develop and/or support existing data change request management
processes.
Task Group 1
Publish standardized data naming conventions automated tools for
enforcement of naming standards.
Task Group 1
Establish an Enterprise Data Model (EDM) containing common and
reusable data objects as well as standardized data modeling templates
for jump-starting new software development projects or re-engineering
legacy applications.
Task Group 1
Create documentation for administration and maintenance of an
Enterprise Metadata repository.
Task Group 1
Provide data and impact analysis services in conjunction with new and
ongoing application development efforts.
Task Group 1
Provide a plan for maintaining the inventory of DHCS’s data assets. Task Group 2
Facilitate the understanding of the meaning, accuracy and timeliness of
data assets.
Task Group 2
Promote the reuse of standardized data names, definitions, elements
and values.
Task Group 1
Identify areas for improvement based on assessment of DHCS’ data
needs.
Task Group 2
Develop data specifications for new DHCS HBE solutions. Task Group 1
Provide technical oversight and/or guidance to developers in the
development and implementation of the data migration, data integration,
and testing plans associated with the release of new applications and
major application upgrades.
Task Group 1
Lead and participate in planning sessions with intra- and inter-
departmental workgroups to define the data requirements for the HBE
and to identify and evaluate various solution alternatives.
Task Group 3
Provide oversight of health care reform activities to ensure compliance
with federal, state, and departmental policies.
Task Group 3
Facilitate and coordinate the communication and information sharing
between departmental staff, business partners, the governor’s task
force, other state entities, and key stakeholders. The communication role
will be especially critical as the federal government provides additional
guidelines and decisions are made for system interfaces and web portal
Task Group 3

development.
Develop the governance structure for effective management and
approval of the data architecture developed during the planning and
analysis stage of this effort.
Task Group 2
Maintain an integrated project schedule that reflects the major activities
of all data architecture for the DHCS HBE project planning effort.
Task Group 3
Advise the Project Director and Project Sponsor on issues that arise
during the course of the DHCS HBE project planning efforts.
Task Group 3
Advise the Project Director and Project Sponsor on issues that arise
during the course of the DHCS HBE project planning efforts.
Task Group 3
Make presentations to committees and other internal and external
stakeholders, as required by the Project Director.
Task Group 3
Attend and participate in regularly scheduled meetings and ad hoc
meetings with Agency stakeholders, other State Department
stakeholders, DHCS Executive Management, the DHCS Chief
Information Officer, the DHCS Planning and Project management
Branch Chief, and the DHCS Contracting Officer.
Task Group 3
Prepare reports and white papers, as required by the Project Director. Task Group 3
Prepare reports and white papers, as required by the Project Director. Task Group 3
Provide briefings as requested to DHCS management with information
and recommendations for training and transfer of knowledge to State
staff as well as recommendations for inclusion of additional outside
Stakeholders impacted or affected by the DHCS HBE project planning
efforts.
Task Group 3
Mapping of RFO Deliverables to MetaVista’s Response
Description of Services Reference
1. Prepare a weekly status report documenting the accomplishments for
the week, planned accomplishments for the coming week, a list of all
projects and activities currently assigned, and any issues related to
assigned projects
Task Group 3
2. Documentation of all processes and procedures required to support
the daily activities of the consultant in a format approved by the state
Task Group 3
3. Act as the Subject Matter Expert (SME) for application and system
support; and provide guidance for management as requested
Task Group 2
4. Develop, implement training plans and provide training and
knowledge transfer to DHCS staff
Task Group 3
5. Provide reports, diagrams, tables and analysis as required Task Group 3
6. Provide documentation and technical specifications for supporting the
web development environment

7. Weekly oral report to the consultant’s supervisor on the status of all
projects and activities currently assigned to the consultant
Task Group 3
8. Provide logical, and physical Network diagrams of systems, as
planned and as-built for all systems the consultant is assigned to
research
Task Group 1
9. Attend any DHCS Standards meetings to obtain approval of projects
assigned to the consultant
Task Group 3
10. Attend all DHCS Unit staff meetings and be prepared to discuss the
current status of all projects
Task Group 3
11. Submit required time sheets in a timely manner Task Group 3
12. Project plans and schedules, in a work breakdown structure format,
for all assigned projects
Task Group 3
13. Complete Infrastructure Change Request form and attendance at
weekly meetings for all changes to the Enterprise.
Task Group 3
14. Evaluate the capabilities of new products and be able to recommend
various solutions to management.
Task Group 2
15. Assess legacy system integration challenges and opportunities
based on Health Care Reform (HCR) regulations, and document
recommended methodologies of going about this system integration.
Presentations of these findings to senior leadership in form of a
PowerPoint presentation
Task Group 1
16. Assess and document where synchronous data exchange and
processing opportunities are available and where this will not be
feasible. Present these findings in the form of a PowerPoint presentation
to senior leadership.
Task Group 1

Task Group 1: Data Architecture, Metadata, Methodology,
Analysis, Modeling, and Documentation
Relevant Activities from Description of Services
• Develop an enterprise data model reflecting the data currently housed in DHCS’ systems
that represents DHCS’s Business Model by aligning with the Information Architecture within
the MITA Framework:
1. Data Management Strategy
2. Conceptual Data Model
3. Logical Data Model
4. Data Standards
• Review and provide comments for design of Logical Data models during the Health Benefit
Exchange (HBE) requirement analysis phase.
• Introduce new data management methods and tools to manage provider and beneficiary
data at a state and national level.
• Create a design for an Enterprise Master Person Index (EMPI) that can be adopted by the
CHHS as a standard.
• Participate in the development of data governance processes and procedures.
• Develop and/or support existing data change request management processes.
• Publish standardized data naming conventions automated tools for enforcement of naming
standards.
• Establish an Enterprise Data Model (EDM) containing common and reusable data objects as
well as standardized data modeling templates for jump-starting new software development
projects or re-engineering legacy applications.
• Create documentation for administration and maintenance of an Enterprise Metadata
repository.
• Provide data and impact analysis services in conjunction with new and ongoing application
development efforts.
• Promote the reuse of standardized data names, definitions, elements and values.
• Develop data specifications for new DHCS HBE solutions.
• Provide technical oversight and/or guidance to developers in the development and
implementation of the data migration, data integration, and testing plans associated with the
release of new applications and major application upgrades.
MetaVista’s proven rationale for modeling and creating blueprints:
• Models provide abstractions of a physical system that allow engineers to reason about that
system by ignoring extraneous details while focusing on relevant ones.
• All forms of engineering rely on models to understand complex, real-world systems.
• Models are used in many ways: to predict data and system qualities, reason about specific
properties when aspects of the system are changed, and communicate key system
characteristics to various stakeholders.

• The models may be developed as a precursor to implementing the physical system, or they
may be derived from an existing system or a system in development as an aid to
understanding its behavior.
1. MetaVista’s views on model transformation
Because many aspects of a data system and network might be of interest, MetaVista uses
various modeling concepts and notations to highlight one or more particular perspectives, or
views, of a system, depending on what is relevant at any point in time.
Furthermore, in some instances MetaVista augments the models with solution hints, or
business rules, that assist in transforming them from one representation to another.
It is often necessary to convert to different views of the system at an equivalent level of
abstraction (e.g., from a conceptual, logical, behavioral, dimensional view to a structural
and/or physical view), and a cohesive set of model transformations in the form of electronic
blueprints in standard formats such as XML facilitates this.
In other cases by adding more detail as supplied by the transformation rules from the
functional analysis, MetaVista will be able to create transformation converting static models
to offering a particular dynamic perspective from one level of abstraction to another, usually
from a more abstract to less abstract view or more concrete view, enabling design
integration in any number of implementation solutions.
2. MetaVista’s models, modeling, and MDA approach and success
Models and model driven data and software architecture development are at the heart of the
MDA approach. So to better understand MDA, it is appropriate to first look at how enterprise
data and application developers take advantage of modeling.
In the data and software engineering world, modeling has a rich tradition established as
Computer Aided Software Engineering or CASE, dating back to the earliest days of
programming.
The most recent innovations have focused on notations and tools that allow users to
express system perspectives of value to data and software architects and developers in
ways that are readily mapped into the programming language metadata rules and code that
can be compiled for a particular operating system platform.
The current state of this practice employs Entity-Relationship Models (ERM) and the
Unified Modeling Language (UML) as the primary modeling notations. The ER and UML
models allow development teams to capture a variety of important characteristics of a data
system in corresponding and cohesive model families of blueprints that can be forward
engineered in to pseudo tables, metadata and code.
In MetaVista’s model-centric approach, the system models will have sufficient detail to
enable the generation of a full data system implementation from the models themselves. To
achieve this, the models may include, for example, representations of the persistent and
non-persistent data, business logic, and presentation elements.
If there is any integration with legacy data and services, the interfaces to those elements
may also need to be modeled. The metadata code generation process may then apply a
series of patterns to transform the models to code, frequently allowing the data programmer
some choice in the patterns that are applied (e.g., among various deployment topologies); in
all cases the models are the primary artifact created and manipulated by developers.
A MetaVista’s model-only approach can be used purely as aids to understanding the

business or solution domain, or for analyzing the architecture of a proposed solution.
MetaVista frequently uses models as the basis for discussion, communication, and analysis
among teams within a single organization, or across multi-organizational projects.
Additionally MetaVista’s well organized blueprints and models are highly product oriented.
The State IT partners will be able to outsource the implementation, deployment and
maintenance of their systems. In practice, the implementation of a data system, whether
from scratch or as an update to an existing solution, may be disconnected later from
MetaVista’s models and blueprints, once they are completed as they will be concise enough
to hand off, without analysis, in that they are a product themselves.
3. MetaVista’s MDA practice is a growing consensus for successful development
Modeling data and software has had a major impact on engineering, and it is critical to the
success of every enterprise-scale solution. However, MetaVista is aware that there is great
variety in what the models represent and how they are used. MetaVista is always interested
in which of these approaches can we describe as successful model-driven development and
not just models for the sake of modeling.
MetaVista supports the growing consensus that MDA is more closely associated with
approaches in which code is (semi-) automatically generated from more abstract models,
and that employ standard specification languages for describing those models.
MetaVista focuses its strategy, standards, and positioning to support the MDA approach. It
is continually promoting and improving MDA as a way to develop data systems that more
accurately satisfy customers' needs, and that offer more flexibility in system evolution. The
MetaVista MDA approach builds on earlier system specification standards work, and it
provides a comprehensive interoperability framework for defining interconnected systems.
4. MetaVista’s principles of MDA
Four principles that underlie MetaVista’s view of MDA:
1. Models expressed in a well-defined notation are a cornerstone to understanding data
systems for enterprise-scale solutions.
2. The building of data systems can be organized around a set of data models by imposing
a series of transformations between models, organized into an architectural framework
of layers and transformations.
3. A formal underpinning for describing data models in a set of metamodels facilitates
meaningful integration and transformation among data models, and is the basis for
automation through tools.
4. Acceptance and broad adoption of this model-based approach requires industry
standards to provide openness to consumers, and foster cooperation and commonality
among other vendors.
To support these principles, MetaVista defines a specific set of layers and transformations
that provide a conceptual framework and vocabulary for MDA. Notably, MetaVista identifies
a selection of types of models:
• Computation Independent Model (CIM)
• Platform Independent Model (PIM)
• Platform Specific Model (PSM)
• Platform Model (PM)

• Implementation Specific Model (ISM)
5. MetaVista transformation practices
MetaVista’s MDA practitioners recognize that transformations can be applied to abstract
descriptions of aspects of a system to add detail, make the description more concrete, or
convert between representations. MetaVista aims to constantly distinguish among the
different kinds of models that allow us to think of data system development as a series of
refinements between different model representations. These models and their refinements
are a critical part of the development methodology for situations that include refinements
between models representing different aspects of the system, addition of further details to a
model, or conversion between different kinds of models.
Three ideas are important here with regard to the abstract nature of a model and the
detailed implementation it represents:
• Model classification: We can classify data system models in terms of how explicitly
they represent aspects of the platforms being targeted. In all data system development
there are important constraints implied by the choice of languages, hardware, network
topology, communications protocols and infrastructure, and so on. Each of these can be
considered elements of a solution "platform." MetaVista’s MDA approach helps focus on
what is essential to the business aspects of a solution being designed; separate from the
details of that "platform."
• Platform independence: The notion of a "platform" is rather complex and highly context
dependent. For example, in some situations the platform may be the operating system
and associated utilities; in some situations it may be a technology infrastructure
represented by a well-defined programming model such as a middleware framework,
SOA or web services; in other situations it is a particular instance of a hardware
topology. In any case, it is more important to think in terms of what models at different
levels of abstraction are used for what different purposes, rather than to be distracted
with defining the "platform."
• Model transformation and refinement: By thinking of data system development as a
set of model refinements, the transformations between models become first class
elements of the development process. This is important because a great deal of work
takes places in defining these transformations, often requiring specialized knowledge of
the business domain, the technologies being used for implementation, or both.
MetaVista can improve the efficiency and quality of systems by capturing these
transformations explicitly and reusing them consistently across solutions. If the different
abstract models are well-defined, we at MetaVista prefer to use standard
transformations.
Underlying these model representations, and supporting the transformations, we rigorously
develop a set of metamodels giving us the ability to analyze, automate, and transform
models in a clear, unambiguous way to describe the semantics of the models. Hence, the
models intrinsic to a modeling approach must themselves be described in a model, which
we call a metamodel.
MetaVista recognizes the importance of metamodels and formal semantics for modeling,
and it has adopted a set of metamodeling levels as well as a standard language for
expressing metamodels: the Meta Object Facility (MOF). MetaVista uses A metamodel MOF
to formally define the abstract syntax of a set of modeling constructs.

Deliverables - Models and Blueprints
Enterprise Architecture is Relative BUT it is not Arbitrary – Zachman:
MetaVista chooses and emphasizes the best set of models that will suffice for each project. All
are useful depending on the stage of the project. A Greenfield project can be more demanding
on the conceptual level, whereas a Brownfield project maybe more focused on the solution end
especially with behavioral and physical changes. MeteVista takes a Zachman-Hybrid approach
to modeling and apportions the emphasis based on resources, budget and levels of intellectual
property through out the team.
Many of the deliverables below were not included in Section IX, Deliverables, in the RFO but
are proposed here by MetaVista.
1. Enterprise Data Model (EDM):
The Enterprise Data Model (EDM) is a series of entity relationship (ER) diagrams or blue
prints that builds on the Concepts, explores the Logic and adds additional Dimension finally
representing the Physical expectations. The most common are show below even though the
Dimensional is considered a Hybrid and addition to the Physical.
a. Conceptual Data Model (CDM)
b. Logical Data Model (LDM)
c. Dimensional Data Model (DDM)
d. Physical Data Model (PDM)
2. Network Topology:
MetaVista will create physical and logical network topologies in layout pattern of
interconnections of the various elements (links, nodes, etc.) of the required computer network.
MetaVista will divide the models into two categories:
1. Physical Topology: represents the physical design of a network including the devices,
location and cable installation.
2. Logical Topology: refers to how data is actually transferred in a network as opposed to its
physical design. In general physical topology relates to a core network whereas logical
topology relates to basic network.
MetaVista will treat the logical topology models as a virtual shape or structure of a network,
which does not correspond to the actual physical design of the devices on the computer
network.
MetaVista will also treat the physical representation of computers on an Enterprise network as
arranged in a circle, however it does not necessarily mean that it represents a ring topology.
MetaVista will identify particular network topologies, which will be determined only by the
graphical mapping of the configuration of physical and/or logical connections between nodes
possibly using graph theory. It will be essential to document distances between nodes,
physical interconnections, transmission rates, and/or signal types as they may differ in two
networks and yet their topologies may be identical.

MetaVista’s network expertise will identify any given nodes that may have one or more links
to one or more nodes in the network and map them in graph results in a geometric shape that
may be used to describe the physical topology of the network. Likewise, MetaVista will
integrate the mapping of the data flow between the nodes in the network determines the
logical topology of the network. The physical and logical topologies may or may not be
identical in any particular network.
Standard Data Modeling:
MetaVista focuses mainly on the three standard Zachman levels of data modeling; conceptual
data model, logical data model, and physical data model:
The complexity increases from conceptual to logical to physical. This is why we at MetaVista
always first start with the conceptual data model (so we understand at high level what are the
different entities in our data and how they relate to one another), then move on to the logical
data model (so we understand the details of our data without worrying about how they will
actually implemented), and finally the physical data model (so we know exactly how to
implement our data model in the database of choice). In a data warehousing project,
sometimes the conceptual data model and the logical data model are considered as a single
deliverable.
a. Conceptual Data Model (CDM): A conceptual data model identifies the highest-level
relationships between the different entities and is made up of important entities and the
relationships among them, whereas no attributes or primary keys need to be specified.

b. Logical Data Model (LDM): A fully attributed entity relationship diagram (ERD), which
shows each entity, its relationship to other entitles and specifies the applicable business
rules. A logical data model describes the data in as much detail as possible, without
regard to how they will be physical implemented in the database. Features of a logical
data model include all entities and relationships among them, all attributes for each entity
are specified, as well as the primary keys for each entity and all the foreign keys (keys
identifying the relationship between different entities).
The steps for designing the logical data model are as follows:
• Specify primary keys for all entities.
• Find the relationships between different entities.
• Find all attributes for each entity.
• Resolve many-to-many relationships.
• Normalization.
The Normalization [Denormalization] Process:
The normalization process of efficiently organizing the data occurs in the LDM. There are
two goals of the normalization process; both of these are worthy goals as they reduce the
amount of space a database consumes and ensure that data is logically stored:
1. Eliminating redundant data (for example, storing the same data in more than one
table)
2. Ensuring data dependencies make sense (only storing related data in a table).
MetaVista incorporates in its database designs a series of guidelines for ensuring that
databases are normalized. These are referred to as normal forms and are numbered from
one (the lowest form of normalization, referred to as first normal form or 1NF) through five

(fifth normal form or 5NF). In practical applications, you'll often see 1NF, 2NF, and 3NF
along with the occasional 4NF. Fifth normal form or 5NF is very rarely seen. There are
also two hybrid normalization styles Non-normal 1NF and or 3.5NF. A higher normal form
was defined in subsequent years, the Sixth Normal Form (6NF), introduced in 2002.
Normal form Defined by Brief definition and selection criteria
1NF Codd (1970),
Date (2003)
Table faithfully represents a relation and has no repeating groups
Non-first
normal form
(NF² or
N1NF)
Schek (1982) In recognition that denormalization can be deliberate and useful, the
non-first normal form is a definition of database designs which do not
conform to first normal form, by allowing "sets and sets of sets to be
attribute domains"
2NF - Codd (1971) No non-prime attribute in the table is functionally dependent on a
proper subset of a candidate key
3NF Codd (1971);
Zaniolo (1982)
Every non-prime attribute is non-transitively dependent on every
candidate key in the table
3.5NF - BCNF Boyce; Codd
(1974)
Every non-trivial functional dependency in the table is a dependency
on a superkey
4NF – Forth
Normal Form
Fagin (1977) Every non-trivial multivalued dependency in the table is a dependency
on a superkey
5NF Fagin (1979) Every non-trivial join dependency in the table is implied by the
superkeys of the table
DKNF Fagin (1981) Domain/key normal form: Every constraint on the table is a logical
consequence of the table's domain constraints and key constraints
6NF Date, Darwen;
Lorentzos
(2002)
Table features no non-trivial join dependencies at all (with reference to
generalized join operator)
c. Dimensional Data Model (DDM): Seldom used except where multi-dimensions such as 3D
and Cartesian coordinates are necessary and represents facts and dimensions, which are
used for reporting and analytical purposes. There is no logical representation of a
dimensional model. It is a “physical” model but sometimes it is shown in a logical version
in the modeling tool with English like names as opposed to physical names.
d. Physical Data Model (PDM): The final representation of the data base structures that will
be generated from the model. It contains the detailed specifications for the database
design and, in a model driven environment; the modeling tool will generate the data
definition language (DDL) that is used to create the database structure. The Physical Data
Model represents how the model will be built in the database. A physical database model
shows all table structures, including column name, column data type, column constraints,
primary key, foreign key, and relationships between tables. Features of a physical data
model include: All tables and columns, all foreign keys that are used to identify
relationships between tables (denormalization may occur based on user requirements).
Physical considerations may cause the physical data model to be quite different from the
logical data model.

The steps for physical data model design are as follows:
• Convert entities into tables.
• Convert relationships into foreign keys.
• Convert attributes into columns.
• Modify the physical data model based on physical constraints / requirements
e. Data Model Feature Set:
Feature Conceptual Logical Physical
Entity Names ✓ ✓
Entity Relationships ✓ ✓
Attributes ✓
Primary Keys ✓ ✓
Foreign Keys ✓ ✓
Table Names ✓
Column Names ✓
Column Data Types ✓
3. Enterprise Metadata Management (EMM) & Taxonomies:
MetaVista approach is to primarily categorize the structural metadata that deals more with
the information architecture, while separately documenting the semantic or taxonomic
metadata that deals with semantic relationships to disambiguate anomalous and disparate
meanings. MetaVista’s EMM solution approach integrates systems already in place, in order
to quickly reap the benefits of metadata aggregation across an enterprise, offering new well-

designed services, and provide a seamless, actionable, inter-active and customized
customer experience. The goals MetaVista focuses are as follows:
• Creating a central source of trusted information
• Effectively leveraging content across the enterprise
• Sharing assets between departments, divisions and locations
• Integrate all data content
• Repurpose older assets with access to cataloged data for effective tracking and delivery
• Implement metadata management without disrupting existing working systems
• Create a foundation for expansion to support master data management
MetaVista’s approach ensures that EMM frameworks provide consistent metadata and
shared taxonomies across multiple server sites in the enterprise. MetaVista leans towards
the concepts of creating managed Metadata services in a single term store that are realized
in databases that contain one or more taxonomies. MeteVista enforces architectural
encapsulation principals ensuring that multiple managed metadata services (term stores)
can be associated with a single Web services application where taxonomies are hierarchical
groupings of metadata, hierarchy, and other elements that provide measurable and
traceable meaning (such as descriptions, synonyms, and translations).
MetaVista has adopted the practice of establishing an Enterprise Metadata Framework
ensuring “best-practices” are installed and adhered to in the architecture and development
of EMM.
Pattern-Based Structural Expressions (PBSE):
By examining metadata specifications of enterprise frameworks from different domains

across multiple applications, at MetaVista we have observed that, in most cases, metadata
is not added to a program randomly, but tends to follow well-defined patterns. It is this
observation that led us to adopt a new expression of metadata format that is not only more
concise and expressive, but also reusable.
4. Enterprise Master Person Index (EMPI) design:
EMPI (Enterprise Master Person Index) helps healthcare organizations deliver on health
information exchange (HIE) initiatives that focus on facilitating the exchange of health
information electronically among physicians, hospitals, health plans and patients.
MetaVista would establish a design that provides the highest level of patient matching
accuracy to eliminate duplicate patient records that often plague the creation of an
enterprise patient record, or electronic health record (EHR). MetaVista’s design would
ensure that the State of California would benefit from immediate access to complete,
accurate, reliable patient data that can be trusted throughout the enterprise. Part of
MetaVista’s approach would be to establish concepts to design an EMPI hub that matches
and links source system records using probabilistic algorithms thus providing a complete,
real-time view of customer data to the point of service or need. Concepts of Master Data
Management or MDM can help the State healthcare organization take steps to
fundamentally improve the quality and accuracy of its patient data and build an enterprise
master person index (EMPI).
5. DHCS HBE data specifications:
These are to include standardized data names, definitions, elements and values. MetaVista
recognizes the importance of protecting the identity of individuals included in the data used
to generate tabulations, reports, and other research. MetaVista will craft data specifications
for DHCS that develop underlying information and analyses needed to implement a DHCS
HBE, identify important issues and critical areas that must be addressed to create the HBE
under the new market rules, assess current data and analyses, and assess need for
additional data collection and updated surveys and studies, regarding eligible populations,
expected take up, market impacts, budgetary costs, and private market conditions as well as
assess process for Medicaid/CHIP and private market integration. MetaVista will resolve the
confusion regarding the differences between a Health Information Exchange, also called a
“HIE,” and a Health Benefit Exchange, also called a “HBE.”
6. Data Migration & Integration Functional Specification
During this activity Functional specification documents will be produced for any Data
Migration requirements. MetaVista will define the Functional Specifications during the
Detailed Design for any Strategic or supporting systems and, where relevant, third party
services. The Data Migration requirements will provide one-off automated data for any Data
Migration tools.

Data Integration Framework (DIF) Decision Support Tools/Models:
MetaVista supports establishing a Data Integration Framework (DIF) to improve data
integration management and delivery as part of a Customer Implementation Project (CIP)
were we have identified several crucial decision-support areas; in as much as four (4) areas.
The CIP is designed to support the DIF’s primary goals and objectives: to validate the DIF
premise that data integration and improved access via standardized interfaces has a value
that can be measured in specific models/decision support tools.
The assessment of these projects against a set of a priori metrics is the primary subject of
this deliverable. The optimal result being that the well governed implementation of DIF
standards and services will promote the general advancement in the homogeneity of data.
MetaVista feels that by establishing a richer DIF Model Data Interoperability Framework that
would result in the interoperability between a set of previously heterogeneous structured
legacy grid model outputs that can be integrated with more recent model outputs that can be
homogenized and made accessible via standard desktop tools. The DIF activity will serve as
a catalyst to guide the State into implementing standard methods of serving their data. As a
result the will be able to transition from a group of nascent, fairly independent data providers
to a more integrated data management group. This will create an across the board
uniformity of services and data formats.
MetaVista stresses that the importance of using a DIF comes into play in various situations,
but it is especially important when an organization is first developing or revitalizing its BI
approach or finds itself with competing projects. Many healthcare customers, for example,
are just beginning to realize the need for a coordinated BI strategy –- not just for financial
information, but to reap the rewards of volumes of clinical data. Retailers find that using a

DIF when they are revitalizing their BI approach gives them a clearer picture of the critical
points and provides better value to their users. It's a way to see through vendor hype to what
is truly going to help the business. Organizations such as financial institutions that have
blossomed during the boom years have found that competing data stovepipes in different
subsidiaries have blossomed as well. A DIF gives them a better overall view of their
customers and helps consolidate critical data where it can help them, not slow them down.
DIF as Information Architecture
MetaVista’s information architecture can turn scattered data into the information that your
business uses to operate and plan for the future. Data can be gathered, transformed using
business rules and technical conversions, staged in databases and made available to
business users to report and analyze.
MetaVista is expert in creating data flow models from creation through transformation to
information, just as claims flow from the provider (ERP, transactions systems) to the payer
(data integration) to the pharmaceuticals suppliers (data warehouses) and finally to retail
pharmacies (data marts and business analytic applications).
The DIF information architecture comprises five parts:
1. Data sources: Data can come from numerous places, including legacy systems, ERP
systems, and front-office forecasting and budgeting systems.
2. Data preparation: Gathering, reformatting, consolidating, transforming, cleansing and
storing data.
3. Data franchising: The aggregation, summarization and formularization of data for use
with business intelligence (BI) tools.
4. Meta data management: Meta data is defined as "data about data." For example, a
library catalog contains information (metadata) about publications (data).
5. Data management: Data and metadata management are the processes behind the
scenes that pass data and its definitions between other processes.
DIF Processes:
The DIF encompasses two kinds of processes -– the processes to determine your data
requirements and solution, and the processes used to physically gather data from its
sources and transform it into information that businesspeople can use to analyze and make
decisions.
The biggest mistake most people make is to assume that an ETL tool is their silver bullet.
It's a critical part, but it's just one part of the whole process.
DIF Standards:
Standards help ensure successful construction, implementation and deployment of the DIF.
There are many areas that need to be addressed:
• Project management: Methodology, baselines, status, controls, scope, people
management and team management.
• Software development: Tools, techniques, documentation, version control and release
management.
• Technology and products: Company and project technology infrastructure and tools.

• Architecture: The blueprint of what and how you are going to build.
• Data: Standards help ensure that data is consistent, accurate and valid.
DIF Tools:
MetaVista will recommend using software tools to create, deploy and maintain the DIF.
There are five tool categories:
1. Data modeling: Use to create and document the logical data model and the initial draft
of physical data model.
2. Data profiling: Use to help you understand the source system data, including its
definition, condition and technical aspects (e.g., storage and format).
3. Data preparation: Use ETL tools to increase developer productivity, decrease overall
development time, simplify maintenance and provide built-in documentation. You may
also need tools for data cleansing to ensure data consistency and error detection.
4. Data franchising: These tools help with data aggregation, summarization and
formularization. There's some overlap with data preparation, but it's a much simpler
process.
5. Metadata management: While often the forgotten aspect of the architecture, technical
metadata management can improve development and maintenance productivity.
Business metadata use can improve business users' understanding of the information
offered.
7. Data Governance Processes & Procedures Specification
MetaVista’s Goals for data governance:
• Realize value from data for intelligence
• Build confidence in data accuracy and integrity
• Create and store distinguishable data
• Ensure that the data is safe, by maintaining compliance with laws, regulations, standards
and requirements
• Ensure that information can be shared unambiguously
• Support risk management best practices
• That all the data concerns converge into a unilateral governance plan

8. Test Plans
9. Assessment 1:
Assess legacy system integration challenges and opportunities based on Health Care
Reform (HCR) regulations, and document recommended methodologies of going about this
system integration. Presentations of these findings to senior leadership in form of a
PowerPoint presentation
10. Assessment 2:
Assess and document where synchronous data exchange and processing opportunities are
available and where this will not be feasible. Present these findings in the form of a
PowerPoint presentation to senior leadership.
Task Group 2: Business Analysis, Stakeholder Requirements,
and Team Leadership
• Guide the creation and monitoring for the usage of data and information as vital department
assets.
• Collaborate with industry and government data exchange leaders about data integration
techniques and methods needed to support new payment and care coordination models
• Lead core and extended EDA teams through the process of defining EDA requirements,
principles and models. This includes developing a charter that is based on goals and
objectives, and defining roles and responsibilities.
• Provide a plan for maintaining the inventory of DHCS’s data assets.
• Facilitate the understanding of the meaning, accuracy and timeliness of data assets.
• Identify areas for improvement based on assessment of DHCS’ data needs.
• Develop the governance structure for effective management and approval of the data
architecture developed during the planning and analysis stage of this effort.

MetaVista Response:
MetaVista will guide EDA teams to participate in the implementation of a Data Life Cycle
Framework, which will run concurrently to the Master SDLC.
As MetaVista will establish a Data Sharing and Implementation Policy Guide, as government
healthcare agencies increasingly require that applications that require data to support payments
and care coordination include data sharing and dissemination plans. It will be necessary For
MetaVista to establish with the EDA teams a schedule for data sharing, a format of the final
dataset, documentation, analytical tools to be provided, and a need and mode of sharing data.
MetaVista also suggests some key example steps to follow:
Step 1: Conduct a review of existing datasets; determine whether a new dataset will be
produced, whether the new dataset should be archived or not; discover special creation
and archive challenges; craft informed consent language and agreements; avoid making
restrictive promises in the informed consent agreement; make a statement about
confidentiality of the information; determine copyright and ownership; etc.
Step 2: Consider data and file structures, naming conventions, data integrity, preparing
dataset documents, variable construction and project documentation, etc.
Step 3: Consider Quantitative, Qualitative and other data types and characteristics, etc.
Step 4: Consider master datasets and work files, etc.
Step 5: Consider confidentiality for sharing, compliance and security, etc.
Step 6: Consider file formats for sharing, etc.
Step 7: Consider preservation, processing and quality review, data descriptions,
dissemination, training and user support.
MetaVista will prepare and submit a complete DLC Guide.
Deliverables
1. DHCS Business Model Compliance Report *
2. Data Management Strategy Manual *
3. Act as the Subject Matter Expert (SME) for application and system support; and provide
guidance for management as requested;
4. Evaluate the capabilities of new products and be able to recommend various solutions to
management.
5. Provide documentation and technical specifications for supporting the web development
environment *
* This deliverable was not included in Section IX, Deliverables, in the RFO but is proposed here
by MetaVista.

Task Group 3: Project Management, Coordination, Road
Mapping, Scheduling, and Meetings
• Establish the roadmap between the current data feeds to the future data feeds as described
in the CMS Pilot Project Medicaid and CHIP Business Information Solution (MACBIS)
Automated Data Management project.
• Lead and participate in planning sessions with intra- and inter-departmental workgroups to
define the data requirements for the HBE and to identify and evaluate various solution
alternatives.
• Provide oversight of health care reform activities to ensure compliance with federal, state,
and departmental policies.
• Facilitate and coordinate the communication and information sharing between departmental
staff, business partners, the governor’s task force, other state entities, and key stakeholders.
The communication role will be especially critical as the federal government provides
additional guidelines and decisions are made for system interfaces and web portal
development.
• Maintain an integrated project schedule that reflects the major activities of all data
architecture for the DHCS HBE project planning effort.
• Advise the Project Director and Project Sponsor on issues that arise during the course of the
DHCS HBE project planning efforts.
• Make presentations to committees and other internal and external stakeholders, as required
by the Project Director.
• Attend and participate in regularly scheduled meetings and ad hoc meetings with Agency
stakeholders, other State Department stakeholders, DHCS Executive Management, the
DHCS Chief Information Officer, the DHCS Planning and Project Management Branch
Chief, and the DHCS Contracting Officer.
• Prepare reports and white papers, as required by the Project Director.
• Lead weekly status meetings
• Provide briefings as requested to DHCS management with information and
recommendations for training and transfer of knowledge to State staff as well as
recommendations for inclusion of additional outside Stakeholders impacted or affected by
the DHCS HBE project planning efforts.
MetaVista Response:
MetaVista will apply its knowledge of project management and business analysis practices,
developed over nearly fifteen years of providing similar consulting services in the public and
private sectors, to the tasks identified in this task group.
MetaVista’s consultant will collaborate with other project stakeholders to develop a project work
breakdown structure format that will allow multiple work schedules (including the schedule for
our activities) to be integrated into a master schedule by the State’s Project Manager or
designee. In collaboration with the State’s Project Manager, our consultant will decompose the
work breakdown structure into a project schedule depicting all significant activities, their
estimated durations, and dependencies. He will use this schedule as the basis for weekly

reporting.
Our consultant will attend all scheduled and ad hoc meetings as requested, providing status
updates, working collaboratively to resolve issues, assessing proposed changes, and in general
serving as subject matter expert in the area of data architecture.
MetaVista proposes a conventional weekly status report identifying recently completed tasks,
late tasks, tasks scheduled for completion in the next week or two (we suggest a two-week
forecast), open issues, and the like. The objective is to give stakeholders a focused, actionable
overview of the project status and key issues, as opposed to overwhelming stakeholders with
status detail.
In support of general status reporting, MetaVista’s consultant will submit time sheets per
guidelines provided by the State’s Project Manager or designee.
MetaVista will work with State staff to determine the format and desired level of detail for any
processes, procedures, training materials, reports, and the like prior to developing the
deliverable in question. We propose developing these materials in an interactive fashion, with
multiple informal reviews of the draft materials, to allow the materials to be tailored quickly and
efficiently to the State’s needs.
Deliverables
1. Prepare a weekly status report documenting the accomplishments for the week, planned
accomplishments for the coming week, a list of all projects and activities currently assigned,
and any issues related to assigned projects;
2. Documentation of all processes and procedures required to support the daily activities of the
consultant in a format approved by the state;
3. Develop, implement training plans and provide training and knowledge transfer to DHCS
staff;
4. Provide reports, diagrams, tables and analysis as required;
5. Weekly oral report to the consultant’s supervisor on the status of all projects and activities
currently assigned to the consultant;
6. Attend any DHCS Standards meetings to obtain approval of projects assigned to the
consultant;
7. Attend all DHCS Unit staff meetings and be prepared to discuss the current status of all
projects;
8. Submit required time sheets in a timely manner;
9. Project plans and schedules, in a work breakdown structure format, for all assigned projects;
10. Complete Infrastructure Change Request form and attendance at weekly meetings for all
changes to the Enterprise.

Methods and Tools
The methods proposed by MetaVista are discussed in detail in the above section.
MetaVista understands that Microsoft Office 2010 will be used to develop most deliverables.
We assume that this will include Project 2010 as well as Visio 2010.
A description of multiple classes of Data Integration Framework / Decision Support Tools is
included under Task Group 1, starting on page 16. MetaVista’s proposed consultant has:
• Over 17 years using CASE tools modeling Requirements Engineering, ERD’s, Object
Oriented UML Modeling, as well as BPM, BPMN, TOGAF, and Zachman
• Over 17 years using Rational IBM products including RequisitePro, Rose, ClearCase,
ClearQuest and Enterprise Suite
• Over 10 years using Oracle ERD Developer tools and Microsoft SQL Server ER tools
• Over 8 years practical experience with Sparx EA building ERDs
• Over 5 years using Erwin and BPwin tools
MetaVista’s assumptions regarding the assessment and selection of specialized software tools
are documented below. In short, MetaVista assumes (and recommends) that the State
establish a standard set of decision support and modeling tools that will be used across the full
HBE lifecycle, as opposed to allowing individual contractors and consultants – including
MetaVista – to introduce tools that may ultimately not be adopted by the overall HBE project.
MetaVista will, of course, actively participate in the assessment and selection of these tools.

Reference Methodologies, Processes and Standards
Data Warehouse Definition Framework [Zachman]
Data Warehouse/Marts Architecture
• W.H. Inmon, Prism Solutions “decision making is the progressive resolution of uncertainty”
• Dr. Ralph Kimball, Metaphor & Red Brick Systems
• Douglas Hackney, Data Warehouse Institute, the International Data Warehouse Association
• Dodge & Gorman, Oracle8 Data Warehouse Consulting Services
• Bischoff & Alexander, Bischoff Technical Services, IBM
• Dr. Barry Devlin, IBM Europe
System Architecture
• John A. Zachman, IBM, the Zachman Framework for Enterprise Architectures (TAFIM),
Zachman Institute for Framework Advancement (ZIFA).
• Zachman 3 / RUP / UML Framework
• The Open Group Architectural Framework (TOGAF) 8.1, ADM (Architecture Development
Method)
• The Federal Enterprise Architecture (FEA)
• Federal Enterprise Architectural Framework (FEAF)
• Capgemini Dynamic Architecture Framework DyA
• 4+1 Philippe B. Kruchten, IBM/Rational
• The Gartner Methodology
• Object Management Group (OMG), Model Driven Architecture (MDA)
• Object Management Group (OMG), Unified Modeling Language (UML) V 1.1 to V 2.1

• Object Management Group (OMG), CORBA
• Object Management Group (OMG), DoDAF (UPDM)1.5 UML Metamodel
Systems Development Life Cycle (SDLC) and/or Software Development Life Cycle (SDLC)
• Waterfall
• Incremental
• Spiral
• Rapid Application Development
• Joint Application Development
• Aspect Oriented
• Enterprise Ontology
• Unified Process (UP)
• Rational Unified Process (RUP)
• Agile Unified Process (AUP)
Process Improvement Models
• SEI CMM Level 3
• SEI CMMI Level 3
• ISO 15504 SPiCE
• ISO 9000-3
Governance
• ISACA, IT Governance and Control (COBIT) AS 8015
SEI Metrics-based scheduling [MBS] ISO/IEC 15939
• Department of Defense (DoD) Information Analysis Center (IAC), Defense Technical
Information Center (DTIC), Air Force Research Laboratory - Information Directorate
(AFRL/RI).
• ITT Corporation (DACS)
• Dr. Robert Kaplan (Harvard Business School), Dr. David Norton, Balanced Score Card
(BSC), Balanced Score Card Institute (BSI)
Standards
• IEEE Standard 1471-2000: IEEE Recommended Practice for Architectural Description of
Software-Intensive Systems.
• ANSI/IEEE 1028: Standard for Software Review and Audits
• ANSI/IEEE 1058: Standard for Software Project Management Plan
• ANSI/IEEE 1074: Standard for Software Lifecycle Process
• SEI/CMMI: DAR, IT, OPD, IPM, RD, REQM, IPM, PI, PMC, PP, PPQA, TS, VER & VAL
Process Areas
Legislation
• U.S. Department of Defense (DoD); Technical Architecture Framework for Information
Management (TAFIM) Volumes 1-8. Version 2.0. Reston, VA: DISA Center for Architecture,
1994.
• Clinger-Cohen Act of 1996
• The Chief Information Officers Council A04. Federal Enterprise Architecture Framework
Version 1.1. September 1999.

• The Patriot Act, 2001, Electronic Privacy, Security, Commerce, and e-Government;
Technology (Web Portals) and Records Privacy, US Gov, Homeland Security: Computer
Security: Sections 105, 202, 210, 211, 216, 220, 808, 814, & 816; Critical Infrastructure
Protection: Title VII and Section 1016, Electronic Government: Sections 361, 362, 403, 405,
413, 414, 702, 906, 1008, 1009, 1012, 1015; Internet Privacy: Sections 210, 211, 212, 216,
217, 220, 224
• Sarbanes-Oxley Act, 2002, SOX 404 Management Assessment of Internal Controls:
Section 302 Corporate Responsibility for Financial Reports, including 302 (a)(4)(C) and (D),
302 (a)(5), 302 (a)(6).
• Health Insurance Portability and Accountability Act (HIPAA), Part 164, Security &
Privacy Subpart C, Security Standards for the Protection of Electronic Protected Health
Information, § 164.308 Administrative safeguards, including 164.308 (a)(3), 164.308 (a)(4),
and 164.308 (a)(5)(ii)(C)
• Gramm-Leach-Bliley Act (GLBA), 1999, Section 501, protect "non-public personal
information"

Assumptions
• The word described in the RFO will require the services of one full-time Senior Data
Architect.
• The HBE project will adhere to the same aspects of commonality desired for all State of
California IT Systems, as described in FI$Cal RFP 8860-30 for the FI$Cal System
supporting general data management activities including 1) Master Data Management
(MDM), 2) Data Cleansing and Data Quality, 3) Data Conversion, 4) Business
Intelligence (BI) and Reporting, and 5) Enterprise Data Warehouse (EDW)
• The HBE project will adhere to the same aspects of commonality desired for all State of
California IT Systems, as required in the development of IT guidelines, strategies, tools,
infrastructure, procedures, standard, roadmaps, models and solutions to meet and
achieve the EA goals and objectives described in FI$Cal RFP 8860-30 supporting 1)
Service Oriented Architecture (SOA) and SOA enabled services, 2) Enterprise Content
Management (ECM), 3) Business Process Management (BPM), 4). Integration with
State Legacy Systems and 5) IT Tools and Infrastructure.
• Any data modeling, decision support, or other specialized tools used during the initial
planning and architecture activities for HBE will continue to be used indefinitely across
the entire HBE lifecycle.
• Given the above, the State will collaborate with HBE architect consultants and others to
assess, select and procure the specialized decision support / modeling tools that will be
used by all stakeholders, as opposed to allowing each individual resource to select
his/her preferred tools.
• State and other non-MetaVista subject matter experts will be available as needed to
work with MetaVista in completing all project deliverables within the schedule constraints
identified in the RFO.
• State staff will review and provide feedback on project deliverables within five business
days of their being submitted for review.

Cost Data Sheet
MetaVista is proposing a single full-time resource for this engagement, Mr. Alexander Doré. All
work described in this offer will be performed by Mr. Doré, unless MetaVista and DHCS mutually
agree in writing to assign selected activities and/or deliverables to another MetaVista resource.
Offer Totals
Staff Name Project Role Classification
Published
hourly
rate
Negotiated
hourly rate
Est.
total
hours Total
Alexander
Doré
Senior Data
Architect
Database
Specialist III $160.54 $110 1,800 $198,000
Travel n/a n/a n/a n/a $5,000
Contractor’s Offer Totals 1,800 $203,000
Amendments
MetaVista understands that the State may extend the purchase order for time only, or time and
money at the State’s discretion. The table below identifies the cost per hour for any additional
work not previously identified that may arise during the project.
Staff Name Project Role Classification
Published
hourly rate
Negotiated
hourly rate
Alexander Doré Senior Data Architect Database Specialist III $160.54 $110

Work Samples
Several work samples are provided at the end of this document, just before the copy of
MetaVista’s CMAS contract. All work samples were developed by MetaVista’s proposed
Senior Data Architect. Mr. Alexander Doré.
Work Sample #1
This is a two-page extract from a 100+ page course, Deploying Agility and Scrum, developed by
Mr. Doré to demonstrate an approach for launching and supporting regeneratinve initiatives for
IT organizations through implementing Agile architecture and processes. This work sample
shows a potential reusable requirements process as a Gantt Chart.
This work sample is included to illustrate Mr. Doré’s knowledge of managing complex projects,
as well as his ability to produce high-quality graphics to assist in communicating abstract
knowledge.
Work Sample #2
This is a one-page extract from a network design document developed by Mr. Doré in support of
a client’s call center with multiple locations in San Jose, Bangalore, and Hong Kong.
This work sample is included to illustrate Mr. Doré’s ability to understand and document the
physical implementation of complex systems.
Work Sample #3
This is a one-page extract from a presentation developed by Mr. Doré in support of a large
private-sector healthcare customer. The presentation was developed in support of the client’s
strategic initiative to improve the revenue cycle.
This work sample is included to illustrate Mr. Doré’s ability to present proposed (“To-Be”)
business processes in a healthcare environment.
Work Sample #4
This four-page work sample depicts a SDLC Governance Model developed by Mr. Doré for a
nation wide healthcare insurance enterprise that has now acquired approximately 70% of the
nations insurance groups.
This work sample is included to illustrate Mr. Doré’s knowledge and understanding of IT
governance models in healthcare.
Work Sample #5
This five-page work sample is an extract from a recent presentation, Architecture Services
Mobilization / Introduction to SOA Highlights by Mr. Doré.
This work sample is included to illustrate Mr. Doré’s general knowledge of the need for building
and fusing business architecture to systemic architecture using MDM service data bridges, as
well as his expert understanding of SOA, and his ability to develop both an architectural vision
as well as the blueprint for implementing that vision.

Work Sample #6
This work sample is a recent White Paper on Master Data Management and related topics.
This work sample is included to illustrate Mr. Doré’s knowledge and understanding of Data
Management, as well as his ability to communicate complex material in the form of a White
Paper.

CMAS Contract
A complete copy of MetaVista’s CMAS contract is included at the end of this document,
following the Work Samples.

About MetaVista
Since 1996, MetaVista has specialized in delivering high-quality, cost-effective professional
consulting services for our public and private sector clients. Services include:
• Project and program management
• Strategic planning
• Business analysis
• Facilitation
• IV&V
• IPOC
• HIPAA security consulting
• Data center consolidation and relocation
• IT strategic planning
• Feasibility studies
MetaVista has a proven track record of managing projects that are mission critical, technically
complex, severely schedule constrained, and multi-vendor in nature. These projects include
many large-scale private sector data center
infrastructure projects, and some of the
largest IT projects for the State of California.
Over the past fourteen years, MetaVista has
served dozens of California state agencies,
departments, commissions, boards, and
other organizations, including the
Department of Corrections and
Rehabilitation. Other clients include some
of the largest private sector firms in the
country, such as Hewlett Packard, J.C.
Penney, Microsoft, and Wells Fargo Bank.
We are proud of our business history with the State of California and work hard to continually
ensure the high standards we have effectively established and applied throughout our
contracting enterprises.
Representative Projects
Current and recent projects include:
• Currently providing Project Management services to the California Prison Health Care
Services for the Access to Care project, Ten Thousand Beds, and Strategic Offender
Management System (SOMS). The services provide include, but are not limited to,
producing project documentation, weekly time recording, status reports, risk
management, procurement and contract management, transition management,
communications management, and quality management.
MetaVista holds the following certifications
and contracts with the State of California:
• Certified Small Business #17002
• Info Technology CMAS # 3-09-70-1454C
• Info Technology CMAS # 3-08-70-0471F
• Info Technology MSA # 5-06-70-105
• Multiple CalPERS Spring Fed Pools

• Provided project management and technology consulting services to Wells Fargo Bank
in support of multiple projects, each of which required detailed IT asset inventory
information describing 16,000+ servers and over 1,000 applications in more than 100
data centers and server rooms nationwide. MetaVista personnel worked with senior
management, enterprise architects and others to define the structure and content
for an enterprise-wide configuration management database (CMDB), and developed
the tools and processes for consolidating inventory data from multiple sources and
soliciting missing data from server and application owners.
• Provided project management and organizational change management services as the
CalWIN Implementation Deputy responsible for overall management of the technical
and application infrastructure rollout, data conversion, training and transition and
change leadership. Acted as liaison to the on-site WCDS Project Team for Pilot County
(Sacramento and Placer) issues.
• Provided business analysis, requirements gathering and data/systems modeling
services for the California Department of Food and Agriculture (CDFA) for their
Emerging Threats Project. This project involved analyzing and documenting existing
applications, data stores, and business requirements for over thirty unique
business processes, ranging from animal disease control to the inspection and
licensing of dairy facilities.
• Providing software development and database administration services since 2006
to the California Energy Commission in support of the CEC’s Program Information
Management System (PIMS), a multi-tier ASP .NET/SQL Server application. During
most of this time, MetaVista also provided Project Management services until this
service was taken over by State staff.
• Providing HIPAA IT Consultant Services since 2004 to support and assist CalOHII in
coordinating and leading the State’s implementation of the IT components of HIPAA.
Activities include project planning, technical analysis and recommendations on the
impact of HIPAA on IT systems, strategic planning for statewide HIPAA IT and NPI
implementation; analysis and evaluation of HIPAA changes to the Short-Doyle Medi-Cal
system; analysis and summary of major issues and risks identified in State HIPAA
project management reports, and analysis of HIPAA-related emerging issues.
• Provided project management, enterprise-wide business analysis, requirements
gathering and technical writing for the California Department of Corrections and
Rehabilitation (CDCR), according to the OCIO guidelines, developed CDCR’s
Information Technology Capital Plan (ITCP) and Agency Consolidation Plan (ACP).
Additionally, MetaVista developed Implementation Plans for Execution of the ITCP and
the ACP, provided facilitation services for CDCR’s IT Strategic Planning session and
created the Executive Summary and mapping to Business Strategic Plan.
Several of MetaVista’s employees and partners are recognized experts in their respective fields;
they have published technical papers, presented at national and global conferences, taught at
the university level, and actively contribute to industry standards. MetaVista has been actively
involved with the local chapter of the Project Management Institute (PMI) as a corporate
sponsor, as board members and volunteers.

MetaVista Proposal HBE-DA-2011-01 Vol I Final

MetaVista Proposal HBE-DA-2011-01 Vol I Final

Recommended

Recommended

More Related Content

Similar to MetaVista Proposal HBE-DA-2011-01 Vol I Final

Similar to MetaVista Proposal HBE-DA-2011-01 Vol I Final (20)

More from Alexander Doré

More from Alexander Doré (17)

MetaVista Proposal HBE-DA-2011-01 Vol I Final