ATTACHMENT E - VHA OHI Business Information Modeling Guidelines_v18_20201013.pdf

Veterans Health Administration

Office of Health Informatics

Strategic Investment Management

Business Information and Knowledge

Business Information Modeling Guidelines

Version 18

October 13, 2020

VHA Office of Health Informatics

Document Change History

Version Number

Date Author Description

1 8-15-2010 BIA TEAM Baseline

2 3-03-2011 BIA TEAM Errors Corrected

3 7-7-2011 BIA TEAM Appended

4 3-18-2012 BIA TEAM Appended

5 5-2-2012 BIA TEAM Revised with Additional Change Control Information

6 8-30-2012 BIA TEAM Revised with additional Notational Concepts

7 10-31-2012 BIA TEAM Revised to include iEHR Standards

8 02-08-2013 BIA TEAM Applied changes

8.1 05-28-2013 Ben Bovée Improved consistencies of cross-references, spelling, and grammar

8.2 08-27-2013 Robert Crawford

Added more specifics around Hybrid model and changed diagrams

9 (Draft) 10-01-2013 BIA TEAM Addressed comments based on review of document at BIA Team Face to Face meeting on August 27-29 2013; improved document layout and grammar

9.1 12-27-2013 BIA Team Added Section 4: Overview of BIA Artifacts. Updated Sections 3.6, 4.1, 4.2,4.3, 4.4, and 4.5. Updated Hybrid Specific Instructions.

Moved Project Specific Model to be a subsection of Logical Information Model. Added role descriptions for Business Information Architecture Lead (VHA Federal Employee) and Lead Information Architect

10 04-04-2014 BIA Team Revamped entire document for RSA v9, RTC and new and improved modeling methodology.

10.1 06-11-2014 BIA Team Corrected references and links

11 08-18-2014 BIA Team Added additional verbiage in guidance and information about the BIM and Work Effort models

11.2 04-01-2014 BIA Team Added links to Naming Guidelines as well as changes in the repeatable process necessary to create work efforts from the Business Information Model

11.3 05-18-2015 BIA Team Added links to new BIA Theme guideline as well as added some additional content in the repeatable process for work efforts

12 12-11-2015 BIA Team Added additional details and process in section that covers creating and integrating work effort models as well as more detail around the use of information patterns in models. Also, further elaborated the section on the RTM and how it’s to be completed.

12.1 2-9-2016 BIA Team Added section that details how the BIA BIM Domains are evaluated and chosen

12.2 7/2016 BIA Team Added performance metrics reports and detail on processes to integrate work effort information into the BIM.

13 9/2016 BIA Team Added description of how redefined classes will notate reuse of classes within the same model with changes required.

14 3/2017 BIA Team Added steps to link data objects (DOs) to normalized data objects (NDOs) in BPMN models.

15 1/2018 BIA Team Added new links to change control documentation and information about the non-VHA enterprise modeling and additional guidance on Conceptual Information Model diagram creation.

15 8/22/2018 BIK Team Added new link to documentation describing quarterly import of BIA architecture data to System Architect.

Version Number

Date Author Description

16 11/27/2018 BIK Team Updated the document to add final changes to Guidelines for ABS TO6 contract.

17 8/12/2019 BIK Team Multiple updates reflect change in relationship to Federal Health Information Model, updates in model methodology and resources.

18 10/7/2019 BIK Team Edits incorporated from BIK Government Lead feedback.

19 5/12/2020 BIK Team Renamed VHA_BIA_Normalized_Data_Objects_WIP.xls to VHA BIA Normalized Data Objects.xls

20 8/10/2020 BIK Team Draft content, markup, and placeholders: Information Domain Methodology, Change Management, DDO, Transitional Architecture, Analytics, BTRIM. Tag RSA specific content.

21 10/13/2020 BIK Team Sequential sub-section headers added for improved readability.

Multiple modifications to images and references related to the recent migration from RSA to Cameo. Other notable updates:

Section 2: Expansion of the guiding principles to include BIK metadata and analytics

Section 3: Reference to the methodology for BIK information domain management and the information domain inventory; use of discrete data objects

Section 5: Addition of the BIK Change Management Plan

Section 6: Incorporation of BIK Business Transformation Risk Identification and Management practices.

Section 7: Moved from previous Section 9. Added Transitional Information Architecture considerations from a CY19 related strategic task.

Section 9: Previous Section 10. Content revised based on modified stereotypes.

Section 10: Previous Section 8. Revisions based the findings of a related CY20 BIK strategic task.

Appendix A: Link removed until Cameo version available

Old Appendix B was removed

Appendix C (previously D): Datatypes revised or removed

Appendix D (previously E): Several documents added, revised or removed; content moved into new table layout

Table of Contents 1 Introduction

1.1 Purpose

1.2 Scope

2 Guiding Principles for Business Information Modeling

2.1 Contribute to the Internal and External Communities of Practice

2.2 Establish Business Information Modeling Best Practices

2.3 Obtain and Leverage Management Sponsorship

2.4 Maintain Awareness of Health Care Industry Information Standards

2.5 Work Collaboratively with Stakeholders

2.6 Adhere to Organizational Standardized Modeling Technique

2.7 Make Information Architecture models and Metadata accessible to Internal and External

Stakeholders

3 Overview of Models and Diagrams

3.1 Conceptual Information Model (CIM)

3.2 Business Information Model (BIM)

3.3 Subject Area Diagrams

3.4 VHA BIM Pattern Diagrams

3.5 Normalized Data Object (NDO) Diagram

3.6 Discrete Data Object (DDO) Diagram

3.7 Hybrid Information Model

4 Overview of BIK Artifacts

4.1 Data Dictionary

4.2 NDO Master Inventory

4.3 Requirements Traceability Matrix (Optional)

5 BIK Change and Configuration Management

6 Information Modeling Work Efforts

6.1 Modeling Work Effort Overview

6.2 Modeling Work Effort Process

6.3 Business Transformation Risk Identification and Management (BTRIM) Analysis and

Modeling

7 Modeling Best Practices and Techniques

7.1 Business Information Modeling Approach

7.2 Conceptual Information Modeling Approach

7.3 Hybrid Modeling Approach

7.4 Information Model Development Methodology

7.4.1 Establish a new work effort project

7.4.2 Modeling sequence

7.4.3 Modeling guidelines compliance checks

7.4.4 Periodic quality reviews

7.4.5 Techniques for model readability

7.4.6 Modeling closeout

7.5 Transitional Information Architecture Modeling

8 Class Diagram Notations

9 Building the Data Dictionary

10 Tracking and Reporting Performance

Appendix A. Hybrid Information Model Guide

Appendix B. Optional Analysis Activities

Appendix C. Business Information Model Data Types

Appendix D. Links to Supporting Sites, Reference Documents and Templates

Table of Figures

Figure 1 - Conceptual Information Model (CIM) Example

Figure 2 - Business Information Model (BIM) Example

Figure 3 -VHA BIM TWC Location Figure 4 - Subject Area Diagram Example Figure 5 - VHA BIM Pattern Diagram Example Figure 6 - Normalized Data Object Cameo Folder Figure 7 - Normalized Data Object (NDO) Diagram Example

Figure 8 – Discrete Data Object (DDO) Diagram Example Figure 9 - Hybrid Information Model Example

1 INTRODUCTION

Business Information Modeling is used to understand and document business information usage, structure and interchange requirements that help to form the basis for systems requirements. The

Veterans Health Administration (VHA) Business Information and Knowledge (BIK) Information

Modeling Guidelines document has broad implications for business and IT decision-makers, project owners and support staff. It guides the process and requirements for the development of information models and related artifacts that increase accuracy of shared information. This document also helps to improve the quality of communication between information stakeholders as they align with the

VHA operational initiatives and strategic objectives.

1.1 PURPOSE

The VHA Information Modeling Guidelines informs the direction of all business information modeling efforts and associated artifact development performed at the VHA. The purpose of this document is to assist information architects and modelers, as well as the working groups and other collaboration forums in which they participate. This assists in the development of consistent information models, diagrams, and other artifacts by providing a structured methodology and common notation for these development efforts.

1.2 SCOPE

This document is intended primarily for the BIK team that is performing business information modeling activities, specifically those resulting in the creation of information modeling artifacts.

Additionally, members of the VHA and VA management team, business and IT decision makers, project managers, initiative owners, support staff, and other stakeholders that require the information modeling artifacts will gain a better understanding of the information modeling process and outputs.

This document is not intended to serve as a tutorial in general information modeling techniques, or in a specific modeling notation language – such guidance, while useful, would be outside of this document’s scope.

2 GUIDING PRINCIPLES FOR BUSINESS INFORMATION

MODELING

In its business information modeling efforts, the BIK unit adheres to eight general guiding principles. Each of these principles is described below, including a brief description of each principle that specifies overall definition and justification.

2.1 CONTRIBUTE TO THE INTERNAL AND EXTERNAL COMMUNITIES OF PRACTICE

During the course of developing Business Information Architecture artifacts, it is important to create a source of information (potentially a community of practice) that can establish or refine existing best practices relating to industry standards, training programs, and knowledge management systems. Participation in this community will help to increase the capacity of Strategic

Investment Management and VHA to produce business information modeling artifacts and communicate model driven requirements across the VA/VHA business environment.

Table 1 – Contribute to the Internal and External Communities of Practice

Activities Benefits

• Capture best practices and lessons learned

• Train modeling community on relevant technology, practices, and modeling notation

• Contribute to the internal and external communities of practice

• Establishes information modeling as a core business practice across the VHA and external business partners

• Ensures that information models are consumable to implementation teams and other stakeholders

2.2 ESTABLISH BUSINESS INFORMATION MODELING BEST PRACTICES

Consistent modeling and reporting approaches, notations and design patterns utilized in the development and maintenance of business information modeling artifacts allow information modelers to create standardized work products (models, diagrams, data dictionaries, technical reports) that are better understood by the stakeholders. To ensure this level of consistency, clear, standardized modeling guidelines need to be established that are based on the proven best practices, methods and approaches.

Table 2 - Information Modeling Best Practices

Activities Benefits

• Work with internal and external groups to establish design and style guidelines that will be consistent across all information models and artifacts

• Store, organize, and manage knowledge in a centralized repository

• Resources and skills of the information modeling team are extended and perpetuated

• Models are consistent, standardized and manageable within the VHA business architecture community

2.3 OBTAIN AND LEVERAGE MANAGEMENT SPONSORSHIP

Information modeling engagements usually include numerous stakeholder interviews and participation in working groups. The term “work effort” is used in these guidelines as the equivalent for these engagements that may be formally managed as parts of projects, initiatives, workgroups, or any other configuration used to manage outcome-oriented tasks. These activities, while crucial to the success of the modeling efforts, may consume the time and resources of the information modeling staff, stakeholders, and other business architecture resources. It is important to ensure management support for these efforts by helping to coordinate activities with their staff and allocating required resources.

Table 3 - Obtain and Leverage Management Sponsorship

Activities Benefits

• Actively engage management in defining the scope, specifics, and impact of all information being modeled

• Provide regular progress updates to management

• Facilitate allocation of resources to support requirements definition and information artifacts

• Minimizes the number of follow-ups and redundancy of data calls and meetings

• Improves the use of resources, planning, and logistics involved in creating information artifacts and preparing for their implementation

• Ensures acceptance and buy-in of the initiative, respective information artifacts, and requirements before implementation begins

2.4 MAINTAIN AWARENESS OF HEALTH CARE INDUSTRY INFORMATION STANDARDS

The health care industry continues to work towards the adoption of standards for the content and format of health care information to take advantage of technological advances in information exchange. Adoption of standards provides opportunities to reduce errors and increase efficiency in health care, which has real consequences in terms of patient safety and quality of care, as well as costs for maintenance of health IT (HIT) solutions. Even with adoption of standards for health information exchange (HIE), many HIT systems do not persist those standards within their internal data and processes. The lack of standards requires establishing things like rules engines to transform the data back and forth.

Performing business information architecture can be enhanced with the awareness of the health care industry standards, particularly in relation to establishing future-state architecture content. It should not be assumed that standards that may be relevant to a work effort will address all the needs of the stakeholders. However, such standards can both help establish initial modeling in the absence of other content, and also provoke thinking in the stakeholder community toward adoption of content in the standards, if not overall standards themselves.

The list below is a sample of HIE/HIT standards that may be useful for providing business information architecture analysis and modeling:

• Health Level 7 (HL7) – This includes electronic data interchange (EDI) formats such as

Version 2.x, structured documents such as the Consolidated Clinical Document

Architecture (C-CDA), and the Fast Healthcare Interoperability Resources (FHIR).

• National Council of Prescription Drug Programs (NCPDP) – HIE standards focused on retail pharmacy. This includes National Drug Codes used to identify medications.

• X12 – EDI standards for a multitude of industries, including health care.

• Federal Health Information Model (FHIM) – The Federal Health Interoperability

Methodology and Standards (FHIMS) initiative is an effort originated and managed by the

Office of National Coordinator (ONC) under Health and Human Services (HHS). Since its initiation, this effort has been transitioned to the Open Group as custodians of the FHIM, the key product of the FHIMS effort. The FHIM is designed to be a superset of information domain requirements across all federal health organizations. BIK has been engaged in the past with this effort to help identify and focus the information domains in ways that will harmonize with the VHA information domain requirements.

2.5 WORK COLLABORATIVELY WITH STAKEHOLDERS

Incorporating the input and expertise of stakeholders is one of the primary activities involved in information modeling efforts. To keep stakeholders apprised, iterative sessions are conducted in appropriate forums (work groups, integrated project team (IPT) meetings) where these subject matter experts review the information model diagrams and supporting artifacts as they evolve, providing guidance that confirms accuracy and clarity in the models.

To initiate the iterative information modeling process, first a “straw man” model is created based on documentation that is collected and reviewed. This preliminary model serves as a starting point to stimulate discussions in subsequent requirements sessions with the subject matter experts. The straw man is typically developed based on existing documentation within the timeframe available before the first review with the subject matter experts.

The continuous process of ‘review -> revise -> confirm’ enables the stakeholders to address concerns and convey additional requirements as necessary. Communications are managed with status reports, artifact reviews, memos, emails, meetings, participation in oversight boards, and interviews.

It is important for the Information Architecture community to develop strong relationships with the organizations and teams involved in implementation. It may be necessary to incorporate feedback from developers or other stakeholders involved in delivering the solutions, and it is critical to establish clear channels of communication to ensure that the feedback is incorporated into information artifacts.

The key deliverable produced during the modeling effort, the Information Modeling Summary

Report (IMSR), will consolidate the detailed documentation of new information requirements and changes to existing information domains. This lays the groundwork for preparing and training staff for changes in the way information is managed. In addition to the various summary reports produced by the BIK team, the newly developed information models and associated artifacts will be available in Hypertext Markup Language (HTML) format.

Table 4 - Work Collaboratively with Stakeholders

Activities Benefits

• Actively engage business and technical SMEs in information requirements elicitation sessions

• Help project teams understand how systems and applications intersect with information artifacts

• Apprise Stakeholders and SME’s of all proposed changes to information domains

• Provide detailed documentation of new information requirements and proposed changes for all current-state information domains and applications

• Provide points of contact at Strategic Investment Management, Office of Information Technology (OIT), BIK, Business Process and Value (BPV), and Requirements Development and Management (RDM) Teams

• Manage communications utilizing tools such as memos, email lists, meetings, and interviews

• Address implementation activities and impacts with information domain stewards

• Update Stakeholders with regular progress reports

• Incorporate project team feedback into models

• Efforts will be aligned with the work of Stakeholders

• Service offerings of the modeling community will be well understood

• Information Models will accurately reflect the subject matter expertise of information domain Stewards and Stakeholders

• Managers are prepared for new information domains or changes to domains which impact their departments or operations, prior to implementation

• Ongoing input from information Stakeholders is incorporated into information models and requirements documentation

• Working relationships and best practices will be developed with the project teams which will facilitate information artifacts and application development work going forward

• Technical requirements will be based on business and functional perspectives

2.6 ADHERE TO ORGANIZATIONAL STANDARDIZED MODELING TECHNIQUE

To ensure that all information modeling artifacts are consistent and understandable, each work effort will incorporate the standardized modeling methodology. Additionally, information models are intended to be at a level and structure that can be easily consumed and understood by the business community. For this reason, Business information models and their respective artifacts must be:

• Understood and validated by SMEs

• Developed according to Business Information Modeling Guidelines

• Integrated with related process models and other architectural artifacts and standards

Based on a variety of criteria and industry best practices, the BIK Team has selected Unified

Modeling Language (UML) Version 2.x class diagrams with corresponding data dictionaries as the most effective mechanism for communicating the information requirements of the modeling work efforts. Modeling artifacts are listed and defined in Section Error! Reference source not found..

All VHA information models must be developed with national and health industry segment standards taken into consideration. i.e., HL7, FHIR, NIEM. While it is not necessary to dogmatically follow naming structure of standards, it is necessary to provide the capability cross reference to those standards.

Table 5 - Adhere to Organizational Standardized Modeling Technique

Activities Benefits

• Provide documentation and tools so modeling community can understand the common notations and techniques

• Reference Information Modeling Checklist for guidance on modeling best practices

• Consistency among models across teams facilitates process improvement and object reuse across organizational boundaries

2.7 MAKE INFORMATION ARCHITECTURE MODELS AND METADATA ACCESSIBLE TO

INTERNAL AND EXTERNAL STAKEHOLDERS

Business Information and Knowledge (BIK) produces a multitude of artifacts that represent detailed data and information concepts within VHA. Transforming data captured within modeling tools, traceability matrixes, and online repositories into easily consumable versions, whether through visualizations or other vehicles, is an ongoing task to improve interoperability and stakeholder communication. There is value to both our stakeholders and internally across BA teams to review, organize, and improve the methods that BIK data is utilized.

Traditionally, BIK has shared information via modeling tools, word and excel documents and quarterly data model releases to the VEAR. Data needs continue to grow, and BIK must look to new and more efficient ways of disseminating information to a variety of stakeholders. The activities listed below are the current approach.

Activities Benefits

• Provide collaborative web access to BIK information models through native Cameo/Teamwork Cloud functionality.

• Construct and maintain dashboards to allow stakeholder access to BIK metadata.

• Teamwork Cloud provides the ability to publish models to the public (within the VA) while also providing the ability for clients to annotate questions and concerns to facilitate collaboration between BIK and its stakeholders.

• Constructing dashboards allows stakeholders to peruse BIK metadata in an interactive and managed fashion to educate themselves and become more comfortable with the data.

Connecting data via inherent relationships and foreign keys allows users to interrogate BIK and BPV data at their own pace.

3 OVERVIEW OF MODELS AND DIAGRAMS

Work products should clearly communicate business information requirements as standalone artifacts. While a number of different artifacts can be developed, as part of the business information modeling process, a significant part of the modeling effort is focused on the development of class diagrams, utilizing UML notation.

UML class diagrams are a growing standard for information representation among enterprise information models. Information analysts can use class diagrams to represent information at various levels of stratification and detail. UML is maintained by the Object Management Group

(OMG). The current version of the UML is version 2.x.

UML class diagrams use a box and relationship approach to diagramming that illustrates how business classes or entities relate to each other and are leveraged in the design of information structures. The core set of UML class modeling elements used to develop class diagram models are provided in Section Error! Reference source not found. of this document. The complete

UML documentation is available at http://www.omg.org/.

VHA BIK uses three model projects. These projects are:

• VHABA BIM – Enterprise Business Information Model which represents the health segment business-level information requirements.

• VHABA_Hybrid – The current state VistA represented in a logical UML diagram.

• VHABA_Non-VHA – This model contains information content which represents the business-level information requirements that are not included in the health segment. This model is seldom used and only for non-VHA work efforts (i.e., Vet360).

• VHABA BTRIM – Contains information content developed to address gaps in current architecture and to represent information at the Enterprise level as reflected in Enterprise

End-to-End process models.

• VHABA Work Efforts – Holds information content for active work efforts and are work-in-progress.

• VHABA Archive – Reflects the models and information from a specific work effort at the time of business owner acceptance and approval.

The Business Information Model and the Non-VHA Model leverage the following diagraming methods as described in Section 3:

• Error! Reference source not found. Diagram

• Error! Reference source not found. (BIM) Diagram

• Error! Reference source not found. (SAD)

• Error! Reference source not found. (NDO)

• Discrete Data Object Diagram (DDO)

The Hybrid Information Model leverages the following diagraming methods as described in

Sections 3.53.3 and 3.5:

• Error! Reference source not found. Diagram

• Error! Reference source not found.

http://www.omg.org/

3.1 CONCEPTUAL INFORMATION MODEL (CIM)

A conceptual information model represents “concepts” (entities) and relationships between them.

The conceptual model is explicitly chosen to be independent of implementation details. The aim of conceptual model is to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts. In the CIM example below, only key concepts are represented on the diagram categorized by subject area.

FIGURE 1 - CONCEPTUAL INFORMATION MODEL (CIM) EXAMPLE

Business Information Modeling Guidelines 15

3.2 BUSINESS INFORMATION MODEL (BIM)

A Business Informational Model (BIM) as a diagram represents a business-oriented logical information model, a distinction made in comparison to logical models that may be limited to planned IT solution functionality. A BIM created for a work effort would be expected to represent the breadth of information needs within that work effort at a detailed level, displaying classes, attributes, associations, and multiplicity. Because BIM diagrams often have large numbers of classes, enumerations are not displayed for sake of readability; a separate enumeration diagram may be utilized.

FIGURE 2 - BUSINESS INFORMATION MODEL (BIM) EXAMPLE

Business Information Modeling Guidelines 16

VHA Business Information Model

The VHA Business Information Model (BIM) is the logical model that represents the current business information requirements as identified by VHA information modeling work efforts. The

Business Information Model is located within the VHABA BIM Cameo Enterprise Architect

(CEA) project (See image below for location of this model in Teamwork Cloud). The VHA BIM is managed using proprietary information domains defined and maintained by BIK with defined creation and maintenance methodology. Currently, the methodology (See Appendix D) includes analysis of the following sources:

• VHA Capabilities and Services

• VHA Data Stewardship Domains

• Federal Health Information Model Domains

• Office of the National Coordinator for Health Information Technology (ONC) United States

Core Data for Interoperability (USCDI)

Separate UML packages are used for each BIK Information Domain to store assigned VHA BIM classes, diagrams, and other UML objects. Each BIK Information Domain is intended to have a

BIM diagram (and a CIM diagram) representing the relevant content modeled to-date. There is no overarching VHA BIM diagram at the logical level, only a CIM.

FIGURE 3 -VHA BIM TWC LOCATION

Business Information Modeling Guidelines 17

Because the VHA BIM is always evolving, it is necessary to carefully manage and control the content and change control process for additions, updates and removal of concepts in the model.

Refer to Appendix D for instructions on the TWC change control method and process.

Business Information Modeling Guidelines 18

3.3 SUBJECT AREA DIAGRAMS

Subject Area Diagrams are diagrams based on a focused section of a BIM, intended to provide a filtered view. It is often necessary to provide Subject Area Diagrams by creating views of smaller sections of a large BIM to facilitate review of the model. Some potential considerations as to what drives the need for a subject area include:

➢ Business stakeholder input

➢ Sub process models

➢ Alignment to reference model hierarchy (Business Function Framework (BFF))

➢ Specialized need

➢ Modelers’ discretion

➢ Size of the subject area

Subject Area Diagrams are stored and managed in a distinct folder within a project in order to distinguish their specified use. These diagrams are also placed into folders within some of the BIK information domains of the VHA BIM at the discretion of the information architects, typically when the diagram is determined to represent a meaningful subset of that overall domain.

FIGURE 4 - SUBJECT AREA DIAGRAM EXAMPLE

Business Information Modeling Guidelines 19

3.4 VHA BIM PATTERN DIAGRAMS

Similar to Subject Area Diagrams, VHA BIM Pattern Diagrams are based on a focused collection of content. However, that content is collected from the breadth of the VHA BIM. The

VHA BIM includes information patterns of related concepts and information structures that are leveraged in multiple information domains and subject areas that require a consistent approach and structure. Information patterns often consist of information classes and associations that reside in multiple model packages and a BIK architect must be careful to consider this when making modeling choices. The VHA BIM Pattern Diagrams help identify opportunities to reuse content that is otherwise not evident from examining the VHA BIM.

FIGURE 5 - VHA BIM PATTERN DIAGRAM EXAMPLE

Business Information Modeling Guidelines 20

3.5 NORMALIZED DATA OBJECT (NDO) DIAGRAM

A normalized data object (NDO) diagram demonstrates a constrained perspective of a BIM (first created at the work effort level, then integrated in the VHA BIM) reflecting information explicitly or implicitly needed to support relevant process models and functional requirements, primarily based on documented process model data objects. NDOs are stored in UML class containers and managed in the Normalized Data Objects folder within the VHABA_BIA BIM.

FIGURE 6 - NORMALIZED DATA OBJECT CAMEO FOLDER

A data object is used in Business Process Model and Notation (BPMN) diagrams to represent when an activity or task utilizes information. Data objects are business-level concepts that may use one term to cover several distinct pieces of information or a singular data attribute that is part of a larger source of information. Data objects can serve either as an input for or an output of an individual business process task, are typically context-specific, and may reflect state transitions

(e.g., draft vs. completed). An NDO consolidates multiple process model data objects across processes, projects, and capabilities into a single information architecture concept. An NDO is not context specific and is stateless in order to support multiples scenarios of use of the same concept.

Business Information Modeling Guidelines 21

NDO diagrams are initially created during work efforts. When work effort model content is integrated into the VHA BIM, the NDO Diagrams are moved into the consolidated collection of existing NDO diagrams, available for re-use within the VHA BIM and subsequent work efforts.

Work efforts may also result in modifying existing NDO diagrams as part of the VHA BIM integration process.

NDO diagrams reflect broader detail than BIM diagrams by including the enumerations from the underlying model that are used by particular class attributes in the NDO. NDO diagrams are constrained by visually filtering out BIM content that is not relevant (e.g. classes, attributes, associations, and enumerations). The filtered-out content persists in the BIM. One limitation from filtering is that NDO diagrams currently cannot store or display different attribute multiplicity values An attribute that is optional (e.g., 0..1, 0..*) in a BIM class but mandatory (e.g., 1..1, 1..*)for the NDO will still appear optional.

BIK has established a governance process for the identification and validation of a newly identified

NDO. This validation process must be followed in order to ensure that creating a new NDO is required within the modeling work effort. Please refer to Appendix D for the link to the established process.

FIGURE 7 - NORMALIZED DATA OBJECT (NDO) DIAGRAM EXAMPLE

Business Information Modeling Guidelines 22

3.6 DISCRETE DATA OBJECT (DDO) DIAGRAM

A discrete data object diagram is a logical information concept intended to supplement a Data

Object by demonstrating known and definable boundaries. The information is categorical and discontinuous, meaning that only a finite number of values is possible. The finite values of a DDO must all be valid for each specific instance mapped of an Activity-To-Data Object. In the context of VHA Business Architecture, UML redefines and filtering for existing classes may be appropriate to accurately model DDO content. DDO’s can only support one state of a Data Object and serves to illustrate the information found in the context of that Data Object’s relationship to an Activity. In the DDO example below, only the necessary information to for that instance of a

Data Object is represented.

FIGURE 8 – DISCRETE DATA OBJECT (DDO) DIAGRAM EXAMPLE

Business Information Modeling Guidelines 23

3.7 HYBRID INFORMATION MODEL

The BIK unit leverages a concept known as Hybrid models to create the current state models of the VHA systems. Hybrid models reflect the business-related data elements captured and managed by the Veterans Health Information Systems and Technology Architecture (VistA) system.

System-related data elements are filtered from view in the hybrid model, such as attributes used to log transaction update dates and times. If the VistA data structure does not group related data elements into well-formed classes, the hybrid model restructures the data into logically related groups of attributes. This new structure is more consumable to the business SMEs.

FIGURE 9 - HYBRID INFORMATION MODEL EXAMPLE

Business Information Modeling Guidelines 24

4 OVERVIEW OF BIK ARTIFACTS

This section describes the various non-diagram artifacts that could be created during an information modeling effort.

4.1 DATA DICTIONARY

The data dictionary is a detailed listing of all classes, attributes and enumerations for any UML package or diagram with BIK content. The BIK team develops a data dictionary for every modeling work effort. The data dictionary is generated, in the form of a MS Word document, from an information model (currently using the Cameo report wizard from within the Cameo Enterprise

Architect designer) . Refer to Appendix D.

A typical data dictionary contains the following sections: classes (names and definitions), attributes (names and definitions), and enumerations (names, values and definitions). For a work effort, multiple data dictionaries may be generated, such as one for each diagram created. Data dictionaries for each BIK Information Domain and NDO diagram are generated and maintained as part of the VHA BIM. Section 9 includes more details on the construction and contents of a data dictionary.

4.2 NDO MASTER INVENTORY

The Normalized Data Object Master Inventory List is an Excel file that currently contains the official BIK NDO inventory. It lists each NDO and provides a visual indicator that allows the information analysts and SMEs to quickly identify any capabilities or VHA specific projects associated with that NDO. The NDO Master Inventory helps information analysts to leverage previously created NDOs whenever possible in order to minimize rework. This list is updated and posted to SharePoint (filename VHA_BIA_Normalized_Data_Objects_WIP.xlsx) as new NDOs are identified and modeled.

The NDO Master Inventory contains metadata about each NDO to understand what it represents, its status, if there is an NDO diagram available, along basic identification. Refer to Appendix D for the current URL to the Normalized Data Object Master Inventory List.

4.3 REQUIREMENTS TRACEABILITY MATRIX (OPTIONAL)

Information modeling activities frequently coincide with requirements development. When this occurs, the requirements analysts will develop a requirements traceability matrix (RTM). Once provided with the requirements matrix, the assigned information analyst will review the requirements for completeness against the information models and artifacts created for the work effort to identify any missing information concepts. Any discrepancies will be documented and socialized with the requirements analyst. This activity will confirm that the information models appropriately identify all of the requirements listed in the RTM. Additionally, this provides an opportunity to review any requirements that were identified during information modeling that had not been captured in the RTM. It is common that the BIK architect may not receive the final RTM until after the RDM analyst is finished compiling requirements. Therefore, the RTM may not be completed until after the IMSR and other documents are reviewed and signed off by the business owners/SMEs. In that case, the RTM should still be completed and forwarded to the SMEs and

Business Information Modeling Guidelines 25

RDM analysts once it is completed and reviewed. After the BIK architect completes information traceability in the RTM, the document is saved on the BIK SharePoint site within the appropriate work effort’s folder and sent back to the RDM analyst for publication.

The approach for mapping information concepts to process and requirements is determined by the scope of the captured requirement. The level of the mapping should be performed at the lowest level in the information model that aligns to the requirement. For example:

• A requirement that states that a process accesses or modifies a set of data that crosses multiple classes of information would align, in most cases, to an NDO diagram

• A requirement that states that an activity accesses or modifies data from a single class of concepts (appointment, address, order, etc.) would align to an information class

• A requirement that states that an activity accesses or modifies a single, discrete piece of information would align to an attribute within an information class (person last name, zip code, telephone number, etc.)

Business Information Modeling Guidelines 26

5 BIK CHANGE AND CONFIGURATION MANAGEMENT

Change Management (CM) Plan provides a standardize and formal methodology to handle all documented change activities from their inception, through approval to implementation. It defines the procedure through which the information content produced for approved work efforts and other non-work effort changes may be integrated into the BIK Architecture. The CM Plan ensures that the changes are documented, scheduled, approved, and communicated prior to insertion into the

BIK Architecture. This results in minimizing risk to the integrity of the existing BIK Architecture.

Please see Appendix D for a link to the BIK Change Management Plan for the details of how changes to the architecture are processed and evaluated prior to acceptance.

BIK architects must also consider configuration management as a component of their work. For information model content, configuration management is managed through the Cameo Enterprise

Architecture Tool and Teamwork Cloud. All other official BIK documentation is stored and managed in Microsoft SharePoint. Internal procedures and methodology are documented in the

BIK Configuration Management Plan (See Appendix D). That appendix also lists additional documents regarding the recurring releases of BIK model content for stakeholder access.

Business Information Modeling Guidelines 27

6 INFORMATION MODELING WORK EFFORTS

The BIK team executes modeling work efforts that are defined and scoped by the business owners and stakeholders. While there are differences between the types of work efforts, the roles for BIK team members are standardized:

• Business Information and Knowledge Lead – Leads the BIK unit, with responsibilities that include coordination of BIK engagement on modeling efforts; oversight of BIK artifacts and standards; supervision of BIK resourcing; and provides primary BA liaison to external organizations.

• Lead Information Architect – Responsible for scoping, planning and modeling approach of the business information domains; mentors information analysts and modelers; provides consultation and final review of information models; leads the establishment of information modeling guidelines and templates; assists in representing BIK interests in external organizations; assists the Government staffing internal artifact reviews; leads the publication and collaboration approach for information modeling efforts.

• Information Architect – The person(s) who will actually create and maintain information models, diagrams and data dictionaries using a Unified Modeling Language (UML) tool.

• Integration Architect – An additional role held by an Information Architect who is responsible for the incorporation of work effort content into the VHA BIM.

• Information Analyst – The person(s) who research documents such as current business documentation (policies, handbooks, directives, user and technical documentation), functional requirements, process models, existing information models, and health industry information standards for input into information modeling work efforts.

The sub-sections below describe the specific deliverables and process for each of the work efforts.

6.1 MODELING WORK EFFORT OVERVIEW

The BIK artifacts from sections 3 and 4 of these guidelines are the basis for creating an Information

Modeling Summary Report (IMSR). With the exception of the RTM, any or all of those artifacts previously described may be included in an IMSR. RDM creates and publishes RTMs at their discretion.

6.2 MODELING WORK EFFORT PROCESS

This section includes a detailed process describing the current practice for performing project-related information modeling. Some key considerations driving the process include:

Business Information Modeling Guidelines 28

• The project has been staffed with knowledgeable stakeholders who are decision makers.

• Our process supports concurrent development of functional requirements, business process models (if required), and information models to ensure business needs are completely captured and are traceable across the deliverables. BIK will release iterations of the artifacts for review, feedback, and update, as required.

• As the process matures, it should evolve to include reviews of artifacts generated by other roles, such as informatics experts, solution architects, and enterprise architects. Such artifacts should be reviewed to ensure consistency with the BIM or to identify gaps that may require modifications (e.g., an interface requires business information missing from information models, a new interface need is identified, or data types must be updated to align with terminology decisions).

• For engagements involving RDM and using the Business Requirements and Architecture Management Plan (BRAMP), BIK ensures its activities align to that methodology. This includes following business process-driven requirements development and submitting the

IMSR as part of a Requirement and Architecture Package (RAP). See Appendix D for a link to the current BRAMP.

The information modeling process is as follows (general alignment to BRAMP is provided in parentheses; specific terms may change over time):

1. Hold a kickoff call to establish key organizations, stakeholders, project scope, and anticipated schedule. (Hold Work Effort Kick-Off Meeting)

2. Review project schedule and scope and confirm that the BIK resources are properly allocated in accordance with the defined roles (Define Work Effort Scope and Schedule).

Identify a common method for storing and sharing the project information artifacts. The method should be available and accessible to all information modelers associated with the work effort. Validated artifacts should be managed as follows:

a. Create the Cameo model project (Refer to the BIK Configuration Management

Plan; see Appendix D.)

b. Establish a work effort folder in the VHA BA BIK SharePoint site for publishing and sharing relevant project documentation.

3. Gather initial documentation (Review Existing Documentation)

a. Attempt to identify relevant packages and files via the VA Enterprise Architecture

Repository (VEAR).

b. Initiate a data call for additional relevant documentation

c. Review any documentation provided by the work effort leads or business subject matter experts (SMEs). Ideally this will include a scope description and/or charter.

d. Review previous related information and/or process modeling products (if available)

e. Share information findings among other project analysts, architects, and modelers.

4. Determine the authoritative source for this business information

Business Information Modeling Guidelines 29

a. If VistA is the source, research if the Hybrid model has related content. If the VHA

Hybrid package has not been developed, evaluate importing VistA file content for information relevant to the subject areas and develop a logical representation in the

VHA Hybrid model. Refer to the hybrid modeling section for more detailed information on the Hybrid model process.

b. Otherwise if VistA is not the source (e.g., Cerner Millennium or a Community Care solution), determine if the general domain(s) have not been previously modeled in the VHA BIM. If it has not been modeled, create a strawman version of the information that is related to the subject areas. This should be based on existing system documentation and external reference models (i.e. FHIM, FHIR, etc.).

5. Begin information modeling work effort (Information Models)

a. Determine content from existing BIM diagrams that need to be referenced or modified as part of the work effort. This may include intersecting concepts that have been previously diagrammed and represented in other BIM work efforts. For example, access control information is often leveraged in multiple capabilities and may need to be updated according to feedback from the current subject matter experts.

b. Begin identifying additional key classes expected for the BIM based on the analysis performed to-date.

6. Review initial requirements and processes (if applicable). This is the input for the initial

Requirements Traceability Matrix. Continue to collaborate with the requirements analysts and process modelers until final BIM is submitted. (Information Models)

a. Participate in initial requirements gathering and process modeling sessions with

SMEs. These sessions will often identify information needs as data objects – information inputs to and outputs from activities - that can be used to facilitate the construction of the BIM and will eventually lead to the Normalized Data Objects analysis. Conduct the iterative steps below:

o Document the inventory of process model data objects o Normalize process model data objects, harmonizing with existing

Normalized Data Objects, as appropriate o Identify key classes for any new Normalized Data Objects o Draft working descriptions for the data objects if they are not already present o Add key classes to the draft model, if they do not already exist o Begin marking up an initial version of the RTM that provides linkages to the relevant information model content; annotate requirements that present traceability issues

Business Information Modeling Guidelines 30

7. Review initial process models (if applicable). Collaborate with the process architect to identify data objects and definitions. This is the input for the initial iteration of the

Normalized Data Objects analysis. (Information Models)

8. Evaluate the BIM for additional existing diagrams that need to be modified as part of the work effort and copy those diagrams into the work effort model. (Information Models)

a. Identify existing information patterns in the BIM that should be considered for use or that may require enhancement. (See the information pattern information in

Section 7 for guidance on information patterns)

b. Identify additional existing classes with content that can support the work effort processes and requirements and copy them into the model.

c. Create new classes, associations, and attributes to support the work effort processes and requirements.

d. Identify issues with naming conventions, associations or multiplicity that may result in recommended changes to overall Business Information Model content.

e. Determine necessary supportive classes that would be required in the work effort model.

f. Add attributes as needed to existing Business Information Model classes (Note:

These classes would have been imported from existing diagrams), but annotate which attributes are new Mark the additions with “ADD” in the stereotype keyword.

g. Remove attributes as needed. Mark those attributes in stereotype keyword as

“DEL.”

h. Modify attributes as needed. Mark those attributes in stereotype keyword as

“MOD.”

i. Identify existing enumerations that are applicable based on the selected classes and copy them into the draft model.

j. Begin identifying additional enumerations that may be appropriate to the work effort (including sample values is a best practice, empty enumerations are not acceptable).

k. Enter data dictionary definitions into new model “objects” (i.e., classes, attributes, and enumerations) and associations.

l. Reference existing Business Information Model complex data types…