36C77618R0091-008.pdf

BFF Guiding Principles

12 April 2013 BRA Internal Page 1 of 14

VHA BUSINESS FUNCTION FRAMEWORK GUIDING PRINCIPLES

DOCUMENT CHANGE HISTORY

Status Version

Number

Date Author

Initial Draft .01 November 13, 2012 Business Reference Architecture

Team

Second

Draft

.02 April 12, 2013 Business Reference Architecture

Team

Introduction

The Veterans Health Administration (VHA) Business Reference Architecture (BRA) is a core unit of the Health Systems Business Architecture Service. The primary purpose of the BRA Unit is the development, refinement, maintenance and maturation of the VHA Business Architecture.

The VHA Business Architecture comprises the strategy, business, and information layers within the overall Health Care Segment of the OneVA Segment Architecture. A key component of the business layer of the Health Care Segment Architecture is the VHA Business Function

Framework (BFF). The BFF describes what the VHA does in a manner that facilitates analysis and information technology (IT) decision-making. It also identifies, elaborates and models the

VHA business, providing a mechanism for linking the VHA organizations, strategies, applications, business processes, and other components in the business architecture. The picture below depicts the BFF with regard to its position within the OneVA Segment Architecture.

VHA OIA Strategic Investment Management BA BRA

Figure 1. OneVA Segment Architecture View

BFF Value Propositions

There are several value propositions realized by existence of a reference model such as the BFF.

These value propositions are:

• Providing a consolidated view of the VHA business functions and activities

• Establishing a bridge between the VHA strategy and its technology resources

• Providing a mechanism for the business to categorize and prioritize its project work

• Providing a tool for greater coordination between VHA business units, as redundancies can be more easily recognized

• Providing a hub for integrating VHA business architecture components (e.g., applications, process models, strategic goals, etc.)

• Improving integration and information sharing with partners to include joint Department of Defense (DoD)-Department of Veterans Affairs (VA) interoperability initiatives

• Supporting compliance with VA and Federal Architecture requirements (e.g., OMB-300 alignments)

BFF Key Aspects

The BFF describes the business functions performed by the VHA. The BFF hierarchy consists of the Health Care Segment (Level 0), Lines of Business (Level 1), Function (Level 2), formerly known as Business Functions, Function (Level 3), formerly known as Business Sub-Functions, and Function (Level 4), formerly known as Business Capabilities.

The BFF provides the means for mapping the business of VHA to its organizations, locations, VHA applications, business processes, and other components in the business architecture such as the business process models and business information models. It also aligns the VHA Business

Architecture Framework up to the strategy layer and down to the business layer. The alignment should be consistent, without gaps. BFF components are described by the same attribute set.

The set of BFF object attributes includes: the ID Number, Hierarchy Number, Name, Description, Level, Commentary, Start Date, and End Date.

In addition, the BFF is used in cross-cutting efforts to help customers identify business needs and develop business requirements. BRA internal stakeholders include: the Business Architecture

Service, the Health Systems Program Integration Office, Health Systems Requirements Analysis and Engineering Management Service, and other Lines of Business within the VHA and VA such as, the VA Office of Information and Technology. External stakeholders include: the DoD

Military Health Service, the Department of Health and Human Services, and Federal Health

Architecture.

BRA maintains and refines BFF to address the needs of key stakeholders and align with the

Standards Developing Organizations that impact stakeholder communities. The BFF content is augmented and validated by feedback from Health Systems Business Architecture leadership and staff, VA/VHA partners, and external stakeholders to ensure an accurate representation of VHA business functions.

Finally, a Glossary of Verbs serves as a reference for the names and expressions used in business architecture and in regards to the BFF. The Glossary is the authoritative source of BFF terminology and the foundation of standard nomenclature. The Glossary is maintained by BRA and included in the quarterly Business Architecture Repository (BAR) Release.

Guiding Principles

This document presents 12 Guiding Principles (GP) defined for the BFF. They provide guidance to those who use, develop, and maintain the BFF. They also describe the purpose and use of the

BFF and provide ground rules for making changes to it. Each BFF Guiding Principle is comprised of four metadata fields which include Name, Statement, Rationale, and Implications.

Name GP1: Levels of Decomposition

Statement Decompose the Lines of Business (LOB) into functions and continue to decompose to lower levels until a sufficient level of detail is achieved; however do not exceed four levels of decomposition.

Rationale The number of levels to which the decomposition is performed will depend on the size of the initial function or business operation being analyzed, the level of definition required and the lowest level of decomposition that is meaningful. If decomposing a business function to a lower level begins to depict a business process (i.e., a sequence of events for a business function), decomposition should cease.

Implications The levels below the LOBs (Level 1) are called, in descending order:

Function (Level 2), formerly known as Business Functions, Function (Level

3), formerly known as Business Sub-Functions, and Function (Level 4), formerly known as Business Capabilities. Although the levels of decomposition are given names for easy reference, the level names have no intrinsic significance except that each level was decomposed from the level above it.

Not all functions will be decomposed to a lower level.

Name GP2: Enumerated Types

Statement Enumerated types of a function (specific types of activity such as various types of surgeries) will not be included in the BFF unless the processes that form the enumerated types are distinctly different.

Rationale Adoption of enumerated types results in duplication of activities during model decomposition. The BFF will not decompose a business function into enumerated types of the function unless a special request is made by users or stakeholders to enumerate the function, or the enumeration clarifies or enhances the description of a business function.

Implications BA architects and BFF users will not have to map multiple types of the same function to the same applications, major initiatives and strategies.

BFF users may require additional guidance on how to use functions that were previously enumerated.

Name GP3: Component Placement in Model

Statement A BFF component must fit the intent of its assigned LOB.

Rationale After it is determined that a component should be included in the BFF, the component is placed under the appropriate LOB by analyzing its alignment to the definition and intended use. (See the description and commentary fields for each

LOB in the BFF). The LOBs distinguish between core health care functions and business or enterprise functions that support the core functions. Commentaries for each LOB are provided to help users articulate the differences between LOBs, and what business functions each LOB represents. Commentaries for the LOBs are provided in Appendix D.

Implications BFF users may need to reference the LOB description and commentary fields to understand component alignments.

Name GP4: Verb Usage in Component Names

Statement Each BFF component name will begin with an appropriate verb.

Rationale In order to ensure consistency across the BFF components, BRA developed a standard approach for naming the BFF components. Appendix B contains a list of verbs and associated definitions used in the model.

Implications Verbs used in component names must be clearly defined and these definitions must be used consistently in the model.

Name GP5: Organizational References

Statement The BFF represents VHA business functions, not organizational structures.

Rationale BFF components must represent a VHA business function, not an organizational structure. The intent is to depict actual health business functions, not the roles that perform the business functions. Referring to defined roles (e.g., technician, nurse, physician, etc.) in either the BFF component name or description should only be done for clarity or if the role is inherent to the activity. BFF components, and their names and definitions, represent what is done, not who does it, or how it is done, or what system supports it, or why it is done. Including organizations and individuals would identify “who” is performing a function. Keeping the functional role and organization separate enables the BFF to represent VHA business functions that support multiple domains.

Implications BFF users may require additional information on this concept as they begin to use the model.

BRA needs to perform a VHA organization to BFF function mapping to provide necessary context for BFF users.

Name GP6: Component Descriptions

Statement BFF component descriptions describe “what” VHA does- and not how, why, when, who or where they do it. Component descriptions should be clear, concise and meaningful (corresponding to the component name). The description should contain enough detail to sufficiently describe the business function to external customers. The description should begin with the name of the component to ensure the format is consistent for all descriptions and that the descriptions align to the appropriate component name. Additional guidance regarding use of component names and descriptions are provided in Appendix C.

Rationale Architecture guidance from The Open Group Architecture Framework and

Object Management Group Business Architecture Working Group reinforce the importance of developing a business reference model that describes "what" the organization does, leaving the business processes to define "how" an organization executes its functions.

Implications The linkage between the BFF and the BA process models needs to be more clearly defined.

BFF users should understand that the BFF does not depict sequences of events or process steps for executing functions.

Name GP7: Oversight and Policy

Statement Oversight and policy formulation functions are included in the BFF if these functions describe the activities necessary to comply with external entities, national or interdepartmental regulations.

Rationale Routine oversight or policy formulation functions executed by departments are assumed to occur within business functions and are not represented as separate business functions in the BFF. However, oversight or policy functions that involve external entities, national or interdepartmental oversight are represented as separate business functions in the BFF, as these are imposed functional activities beyond day-to-day business management.

Implications Any exceptions to this principle must be clearly documented in the model.

Name GP8: Components free of System or Capability Requirements

Statement All components must be free of system or capability "requirements" for current

(existing) or future functions. Therefore, BFF components are system-agnostic.

System names or capabilities should not be included in any component name or description.

Rationale Components described within the BFF only describe the functions being performed and will not refer to any systems or applications that support execution of these functions. Furthermore, future or past (retired or transitioned) capabilities, by definition, are not being performed within the VHA; as such, they should not be represented in the BFF.

Implications IT system requirements and functionalities change routinely; the BFF could inadvertently become misaligned with the changing systems environment if linkages are not properly maintained.

Name GP9: Component Type Classification

Statement All components must be classified as one of the following types: Core Mission, Business Service, or Enterprise Service (see Figure 1).

Rationale The BFF supports the segment/component types defined in the White House

Office of Management and Budget (OMB) Federal Enterprise Architecture

(FEA) Practice Guidance: Core Mission , Business Service, and Enterprise

Service. In addition, all components in a given hierarchy must belong to no more than one component type (e.g., Business Service components should not be hierarchically mixed in with Core Mission components). Since the BFF is a strict decomposition of each of the LOBs, each child component should be of the same type as the parent.

Implications Classifying a component as something other than Core Mission, Business

Service, or Enterprise Service does not comply with the FEA and Federal

Segment Architecture Methodology guidance upon which the BFF was built.

The model is constructed such that each business function and its decomposed components represent one of the three FEA segment/component types. Mixing component types within a hierarchy will obfuscate the model.

Name GP10: No Redundant Components

Statement All components must be examined for redundancy and/or overlap.

Rationale Each business function should be represented only once within the model.

Usability of the model is hindered when same or similar components exist under different LOBs.

Implications Redundant components may confuse users.

Name GP11: Parent to Child relationships

Statement All lower level components must represent a strict decomposition of higher level components.

Rationale Each child component is an extension of its parent, and as such, it must correspond to the parent component.

Implications Introducing components that do not represent a strict decomposition of its parent component may confuse users.

Name GP12: Parent Component Decomposition

Statement Every parent component must contain at least two and should contain no more than nine child component whenever reasonably possible.

Rationale No actual decomposition has occurred if a parent has less than two child components. The upper limit of nine child objects under a parent object should minimize confusion and enable users to understand the child components, as well as the underlying logic of the decomposition.

Implications Introducing components that do not represent a strict decomposition of its parent component will cause confusion for the user community of the model.

Appendix A

BFF Alignment to FEA BRM

This diagram depicts the alignment between the FEA Business Reference Model (BRM) and

BFF LOBs.

Appendix B

Glossary of Verbs

Verbs Definition

Acquire The business function involves buying or obtaining a good, service, or asset

Administer The business function is responsible for the implementation, use or operation of an activity, product or service

Adopt The business function incorporate or institutes an idea, method, or procedure

Advise The business function recommends the a course of action

Analyze The business function methodically examines details in the constitution or structure of an activity, product or service

Archive The business function places or stores a collection of documents or records

Assign The business function allocates or appoints an organization or individual to accomplish particular job or task

Backup The business function provides supplemental support, if necessary

Capture The business function includes information gathering and reporting

Change The business function makes an activity, product or service different

Check-In The business function confirms the arrival of a patient for a medical appointment

Communicate The business function shares or exchanges information, news, or ideas

Conduct The business function directs a course of action

Control The business function determines the behavior or maintains authority over an activity, product or service

Coordinate The business function facilitates a complex activity or organization to ensure efficiency or effectiveness

Create The function brings an activity, product or service into being

Deliver The business function provides an activity, product or service to designated recipients

Determine The business function involves a number of business rules

Develop The business function creates a product or service

Establish The business function institutes an activity, product or service

Evaluate The business function determines or assesses the value, accuracy or timeliness an activity, product or service

Facilitate The business function makes an action or process easier

Implement The business function puts a decision, plan or agreement into effect

Inventory The business function generates a list of activities, products or services

Maintain The business function causes or enables a condition or state of affairs to continue at the same level or rate

Manage The business function handles, directs, governs, or controls resources (for some purpose)

Monitor The business function provides oversight of an activity and can include tracking and reporting

Participate The business function takes part or shares in an activity

Perform The business function is a executes a specific task

Process The business function performs a series of operations to execute an activity or provide a product or service

Promulgate The business function promotes or makes an activity, product or service widely known and/or used

Provide The business function supplies or makes an activity, product or service available for use

Pursue The business function follows an organization, individual, activity, product or service

Reach The business function enables the communication of an organization, individual, activity, product or service

Record The business function documents an organization, activity, product or service for later reference

Report The business function gives an account of a particular matter

Schedule The business function arranges for a planned event to take place at a particular time and place

Select The business function chooses the most suitable organizations, individuals, activities, products and/or services from a larger number as being the best or most valuable

Service The business function provides aid or services rather than products or goods

Share: The business function allots a portion of an activity, product or service with others

Support The business function sustains or assists in the establishment, operation, maintenance, refinement and/or retirement of an activity, product or service

Track The business function follows the course or pathway of an activity, product or service

Use The business function deploys an activity, product or service as a means of accomplishing a purpose or achieving a result

Utilize The business function makes an activity, product or service usable or practical

Appendix C

Component Name and Description Rules

1. BFF Component Descriptions- Whenever possible, describe exactly what a component is and/or does (e.g., “Provide Health Care is” or “Provide Health Care does”). This is more specific than stating what a component involves or includes.

2. BFF Commentary Column- Use the Commentary Column to provide additional information for BFF components that is not appropriate to include in the component descriptions (e.g., notes, organizational references and other supplemental information).

3. Lower Level Sequential Components- Submit a BFF Change Request form to provide recommendations for deleting lower level sequential components such as “Process

Freedom of Information Act Requests” or incorporating their descriptions into larger components like “Manage Freedom of Information Act Requests.” Following the BFF

Change Control procedure, BRA will consider recommended changes and decide their disposition.

4. Minimize the use of multiple verbs in BFF component names. If possible, use

“Manage” to consolidate them because it addresses the performance of multiple interrelated tasks.

Example: Obtain/Capture & Manage Consents & Authorizations (change to Manage

Consents and Authorizations)

5. Using “Beneficiary,” “Patient” and “Veteran”- Use the term “beneficiary” to describe components that involve providing access to care and processing benefit claims. Use the term “patient” to describe components related to health care delivery. Use the term

“Veteran,” as necessary, for components that apply specifically to Veterans.

6. Using “Provider” in lieu of “Doctor” or “Physician”- Use the term “provider” instead of “doctor” or “physician.”

7. Using “Caregiver”- In cases where a provider or qualified clinician (a licensed medical professional) is not providing services, using the term “caregiver” is acceptable.

8. If a BFF component name ends with “Management,” change the first word to

“Manage” (as appropriate).

Example: Provide Patient Summary Lists Management (change to Manage Patient

Summary Lists)

9. If possible, use “Develop” instead of “Create,” “Monitor” in lieu of “Track,”

“Perform” instead of “Execute,” and “Capture” in lieu of “Gather.”

10. Spell out all words used in BFF component names- no abbreviations or acronyms.

Example: Coordinate with Health Agencies on Epidemiology, EmergMgmt, Public

Health Issues (change to Coordinate with Health Agencies on Epidemiology, Emergency

Management, and Public Health Issues)

11. Spell out an acronym the first time it appears in the BFF component description and then include the acronym only if it will be used for subsequent reference(s).

Example: Provide HR Strategy (change to Provide Human Resources Strategy and include acronym (HR) only if referring to Human Resources at a later point in the BFF).

12. Capitalize all words used in BFF component names except prepositions (e.g., of, in, to, and).

Example: Perform Acquired Infection and Influenza Surveillance

13. Don’t use special characters like &, # or /. Use a comma for / or use words such as

“and,”, “number” and “or” instead.

Example: Conduct Electronic Insurance Identification & Verification (change to

Conduct Electronic Insurance Identification and Verification)

14. Divide “Healthcare” into two words- “Health” and “Care.” Exception: when part of a proper noun, someone’s office or title, or a formal name for a healthcare system

(i.e. Tampa Healthcare Center)

15. Capitalize all instances of the word “Veteran.”

16. Run spell check to identify and correct typographical errors.

Appendix D

BFF Line of Business Commentaries

1.0 Provide Access to Health Care

Provide Access to Care represents an important concept in health care provisioning with regard to one’s ability to obtain health services. "Access" refers to entry into or granting use of the health care system, including decisions points that influence entry or use. The specific dimensions represented by the functions of this LOB include availability and accessibility.

2.0 Manage Public Health

Manage Public Health was added to capture VHA public and population health activities such as epidemiological studies and medical registry management. Manage Public Health was initially called “Manage Population Health” to be more in line with the FEA BRM Health Business Area

Population Health Management and Consumer Safety LOB. During the Health System subject matter expert interviews, it was determined that “Manage Public Health” was a more appropriate name for this LOB because this LOB is broader than just population health.

3.0 Provide Health Care Administration

Provide Healthcare Administration involves overseeing the day to day operations of a hospital, health care facility, or medical service. Personnel executing the functions in this LOB are making decisions about how to save money, managing staff, and handling any financial and legal problems that arise. Components represented herein comprise the necessary functions to provide the best patient care, while interpreting and ensuring compliance with laws that affect healthcare providers and administrators.

4.0 Deliver Health Care

Deliver Health Care contains the business functions that are involved with the patient encounter.

HL7 defines a patient encounter as “an interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient. For example, outpatient visits to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call and provider communication health care to patients.”

Deliver Health Care also contains the business functions that are involve the clinical documentation that must take place to indicate what happened in patient/provider encounters and the results of ancillary actions. Finally, Clinical Decision Support is documented in the Deliver

Health Care LOB, as it is used to link health observations with health knowledge to influence choices by clinicians for the direct care of patients.

5.0 Conduct Health Care Research

Conduct Health Care Research LOB serves as a centralized location for health care research topics in the BFF. Biomedical Laboratory, Health Services, Clinical and Rehabilitation research topics are covered by this LOB.

6.0 Provide Health Care Education

Provide Health Care Research serves as a centralized location for health care education topics in the BFF. Health Care Education is provided to allied health professionals and medical and dental students and residents. Allied health professionals are students that are being mentored by

VA employees or someone from their training institution (e.g., psychologists, social workers, specialty care, etc. - a wide range of health care providers). The VHA employee education and training components can be found under the Human Resource function in Managing Business

Enabling Services.

7.0 Manage Business Enabling Services

The mission of Business Enabling Services is to assist the administration in carrying out their goals and objectives in providing quality health care to our Veterans. To that end, Manage

Business Enabling Services provides services in the areas of Accounting, IT, Human Resources, General Administration, Payroll, Supply Chain, and Strategic Planning. Each of these services are invoked by or called upon to support the core mission areas. Further analysis into a business service will help to understand the impact of that service with regard to its role in delivering health care, helping to ensure the portfolio of Business Services aims to support the changing needs and objectives of the VHA.