36C77618R0091-006.docx

VHA Office of Health Information Health Systems Business Information Architecture

Information Modeling Guidelines Version 8 February 2013

VHA Office of Information\ Enterprise Systems Management Business Architecture Process Modeling

This report is confidential and intended solely for the use and information of the company to whom it is addressed

DOCUMENT CHANGE HISTORY

Table of Contents

List of Figures

introduction The Veterans Health Administration’s (VHA) Business Information Architecture’s (BIA) Information Modeling Guidelines have broad implications for business and IT decision-makers, project owners and support staff, because they guide the process and requirements for the enhanced accuracy of shared information. This serves to improve the quality of communication between information stakeholders as they align with the VHA operational initiatives and strategic objectives.

Purpose Information modeling is used to understand and document business information usage, structure and interchange requirements that later form the basis for systems requirements. With this in mind, the VHA Information Modeling Guidelines informs the direction of all business information modeling and associated artifact creation performed at the VHA. The ultimate goal is to ensure consistent information models and artifacts by providing a structured methodology and common notation for model and artifact development.

Scope This guidance is intended for members of the VHA and VA management team, business and IT decision makers, project managers, initiative owners, support staff, and other stakeholders who rely on and benefit from information modeling artifacts and requirements.

guiding principles Each principle is followed by a brief description that specifies overall definition and justification. Each table contains a list of specific activities and benefits related to the principle.

Contribute to an InFORMATION ARCHITECTURE Center of Excellence During the course of developing Information Architecture artifacts, it is important to create a resource that can provide best practices relating to industry standards, training programs, and knowledge management systems. It is imperative to take a long term perspective on Health Systems (HS) and VHA’s capacity to produce Information artifacts and communicate model driven requirements across the business environment.

· Establish design and style guidelines that will be consistent across all information models and artifacts

· 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

· Models will be consumable to implementation teams and other stakeholders

Information modeling Best practices It is important that consistent approaches, notations and design patterns in the information models are maintained during the development of artifacts. Clear guidelines are the building blocks for ensuring the execution of this goal.

· Establish design and style guidelines that will be consistent across all information models and artifacts

· Capture best practices and lessons learned

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

· Resources and skills of the modeling team are extended and perpetuated

· Models will be consistent and manageable within the VHA business architecture community

Participate on INTEGRATED PROJECT TEAMS (IPT) It is important for the Information Architecture community to develop strong relationships with the organizations and teams involved in implementation. Information Architecture artifacts often require several iterations, and it may be necessary to incorporate feedback from developers or other stakeholders involved in delivering the solutions detailed in a business Information Model. In order to accomplish this, it will be necessary to establish clear channels of communication and best practices related to how feedback is incorporated into information artifacts.

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

· Incorporate project team feedback into models

· Capture information requirements for future by the Business and Technical Communities

· 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

· Project teams will have solid understanding of information stakeholders’ and stewards’ vision

Obtain and Leverage Management Sponsorship During the course of a modeling engagement there will be numerous interviews and working groups which may consume the time and resources of the staff, stakeholders, and other business architecture resources. It is important for management to support these efforts by helping to coordinate activities with their staff and allocating resources.

· 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

· Minimize the number of follow ups and redundancy of data calls and meetings

· Improved use of resources, planning, and logistics involved in creating information artifacts and preparing for their implementation

· Acceptance and buy in of the initiative, respective information artifacts, and requirements before implementation begins

Referencing the FHIM (Federal Health INformation MODEL) The Federal Health Interoperability Methodology and Standards is an effort originated and managed by the Office of National Coordinator under Health and Human Services. It establishes interoperability standards that include the creation of a high level Information Model that represents metadata of health information domains across the federal health information community. Business Information Architecture is engaged in this effort to help identify and focus the information domains in ways that will harmonize with the VHA Information domain requirements.

The FHIM is designed to be a superset of Information domain requirements across all federal organizations and by necessity covers information that will by default never be needed or consumed by the VHA. BIA’s goal is to ensure that VHA’s key information requirements are represented in the FHIM. BIA will attempt to align VHA’s information with the FHIM models when it is possible and reasonable.

Domain and project work efforts should use the FHIM as the first model of reference when evaluating the scope and content of an information model. A gap analysis will always be performed on iEHR-related information modeling against the FHIM to ensure that all possible information requirements are addressed. The FHIM Information Model can be referenced at http://fhims.org/content/420A62FD03B6_root.html

Referencing the VIM (VA Information model) The VA Information Model (VIM) is an product managed by the VA Office of Information Technology. It is used as the bridge between logical information requirements and physical information deployments.

The VIM is at a complexity level that makes it difficult to verify with, and be consumed by business stakeholders and Subject Matter Experts (SME). This is because the VIM is representing information in a perspective and format that is unfamiliar to the typical business stakeholder due to its reliance on external modeling standards. Business Information Architecture models are designed to be at a level and structure that can be easily consumed and understood by the business community. For this reason Business information models must be:

0. Understood and validated by SMEs

0. Developed according to Business Architecture Guidelines

0. Integrated with related process models and other architectural artifacts and standards

0. Stored and maintained according to the BA Integration Methodology (BAIM)

Business modelers will closely collaborate with VIM modelers when VIM model(s) are to be leveraged to develop a business information model. Any issues discovered with the VIM model(s) will be logged for review with VIM modelers.

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 where these subject matter experts review the diagrams and supporting artifacts as they evolve, providing guidance that confirms accuracy and clarity in the models. The key deliverable produced during the modeling effort, (either the Information Modeling Summary Report (IMSR) for domain efforts, or integrated Information Model Report (iIMR) for iEHR capability work) will be 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.

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.

· Actively engage business and technical SMEs in information requirements elicitation sessions.

· 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 Health Systems, Office of Information Technology (OIT), BIA, Business Process Architecture (BPA), and Requirements Analysis and Engineering Management (RAEM) 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

· 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

Adhere to organizational Standardized Modeling Technique Business information products should clearly communicate business information requirements as standalone artifacts. All models will incorporate the Business Information Architecture standardized modeling methodology (as directed in the section regarding each type of artifact in this document).

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

Based on a variety of criteria and industry best practices, the BIA Team has selected Unified Modeling Language (UML) version 2 class diagrams with integrated data dictionaries as the most effective notation for communicating the information requirements of the modeling work efforts. Section 11 CLASS DIAGRAM NOTATIONS of this document provides an overview of the UML class diagram in addition to style and standards recommendations.

The order of creation is that 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.

UML ClaSS DIAGRAM Overview 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. The current version of the UML is version 2.

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 11 CLASS DIAGRAM NOTATION of the document. The complete UML documentation is available at http://www.omg.org/.

Conceptual Information Models (CIM)

Figure 1 – Conceptual Information Model (CIM)

The Conceptual Information Model (CIM) is the abstracted view of the logical information model. It is intended as a tool for higher level audiences. It simplifies the information view by concentrating on high level information concepts and by removing class attributes. This also includes removing supportive classes that add unnecessary detail to the content of the conceptual information model. In the above example, there are supportive dependent classes for both the Person class and the Encounter class that are not illustrated in the Conceptual Information Model.

Logical Information Models (LIM)

Figure 2 – The Logical Information Model (LIM)

The Logical Information Model (LIM) is the detailed view of the information. It is a representation of the business information requirements of the project/domain. This includes all the classes in the work effort model along with all of their attributes. The attributes are defined with their simple data types and characteristics. In the above example there are supportive dependent classes for both the Person class and the Encounter class that are not illustrated in the Conceptual Information Model.

The LIM is still an abstracted view of the information as it does not contain system specific information attributes that are required in the final system but not required or consumed by the business stakeholders or SMEs.

HYBRID Information Models (HYBIM)

Figure 3 – Sample Hybrid Information Model (HYBIM)

The BIA unit leverages a concept known as Hybrid models (HYBIM) 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 VistA’s 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.

Hybrid model attribute names and definitions are imported from the VistA dictionaries and are included in the models’ dictionary (stereotypes) to illustrate how the attributes map back to the original system. For example, if the system duplicates information in more than one file, those duplicate attributes are included in both class representations of those files. The names of those attributes do not change from the system representation. The names are retained and converted to lower camel capitalization format to accommodate BIA data dictionary standards. Any special characters (i.e., ”/”,”?”,”&”,”$”,”#”) that exist in the file attribute names are removed or renamed as appropriate.

Hybrid Modeling Approach Unlike logical models, the process is not the driving decision behind the definitions for the Hybrid Information models. Instead, the existing applications are used to reverse-engineer the model design. The first step is to identify the files that are used by the application. Those files are then inspected and reverse-engineered into the modeling tool as classes with the information from the Data Architecture Repository (DAR).

The attributes of the files are parsed and further broken out into classes created to categorize the attributes by concept. VistA sub-files and pointers are evaluated to determine if they belong to the model as referenced classes. Forward and backward pointers are evaluated to identify touchpoints to other domains. All value sets defined in the VistA files are defined as enumerations.

PROJECT SPECIFIC Information Models

Figure 4 – Sample Project Specific Information Model Project specific information models are logical models that leverage information from the existing VHA Enterprise Logical Model (As-Is) that are located in the VHAEIM project. Each project specific Information Model is housed within its own Rational Software Architect (RSA) project with separate folders used to identify the domain of information where any new class or object should be located.

Project specific models will leverage existing model content (classes, enumerations, and associations) from the existing VHAEIM model and potentially modify that model design, as well as identify new requirements for information that dictate changes to the existing classes. Changed classes are housed within the VHAEIM_To-Be project until there is implementation work performed that functionally addresses the changes within the production environment. At that point the VHAEIM model would be updated to reflect the current production state.

Each modeler should determine if a class or enumeration they require has pending changes captured in previous or concurrent project work .This determination is performed by discovering if the class or enumeration in question has a new entry in the VHAEIM_To-Be project. If so, VHAEIM_To-Be version of the class in question should be used with notation placed in the changed or new attribute with the reason for the required change, the project, and the Subject Matter Expert (SME) that requested it.

SUBJECT AREA Diagrams Subject Area class diagrams are intended to provide a filtered view that illustrates a major area of focus of the information model. It is often necessary to provide targeted diagrams to make review of the model more efficient. There is no hard and fast rule as to what comprises a subject area. 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) or integrated Business Reference Model (iBRM))

· Specialized Need

· Modelers discretion Subject Diagrams are stored and managed in a distinct folder within the model project in order to distinguish their specified use.

Figure 5 – Sample Subject Area Diagram (SAD)

NORMALIZED DATA OBJECT DIAGRAMS

A Data Object is used in Business Process Modeling Notation (BPMN) models to represent when an activity or task utilizes information. Data Objects can serve either as input for or output of an individual business process task.

Normalized Data Object (NDO)[footnoteRef:1] diagrams are intended to provide a consolidated model of information explicitly or implicitly described in the process models and functional requirements. The process models identify Data Objects that are either used or created by the project’s individual processes. These 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. In future state modeling, implementation level considerations such as forms, messaging, or services are intentionally not factored into the identification of these data objects, whereas current state may have specific ties to such requirements. While the process model Data Objects serve as a good starting place to transition into the information model, some degree of “normalization” is needed at times. Normalization in this instance is used to identify more common sets of information that may be represented as many different Data Objects in the process models. An NDO can be defined more clearly to facilitate information modeling. The NDOs and their definitions that are used to validate the Logical Information Model. [1: Data Objects the information required or produced in an activity]

NDOs are stored and managed in a specific folder within the modeling project.

Figure 6 – Sample Normalized Data Object Diagram

CURRENT STATE DOMAIN WORK EFFORT

BIA generates artifacts that are the basis for creating the Information Modeling Summary Report (IMSR) in a current state domain work effort. These include:

· Conceptual Information Model (CIM) of the project scope[footnoteRef:2] [2: Conceptual models are not always created if the only work in the current state is a Hybrid model]

· See Conceptual Information Model Section

· Hybrid Information Model (HYBIM) of the project scope

· See Hybrid Information Model Section

· Enumerations Diagram(s)[footnoteRef:3] [3: As a general rule, Enumerations should not be defined if there are more than 50 values in the value set. ]

· Subject Area Diagrams – required in documentation if identified

· See Subject Area Diagrams section

· Data Dictionary

· See Data Dictionary information in Section 13.

This section includes a detailed process describing the current practice to be followed for performing current state Hybrid information modeling. Some key considerations driving the process include:

· The subject area in question is clearly scoped in the existing VistA Electronic Data Dictionary (EDD), or Data Architecture Repository (DAR).

· We will release iterations of the artifacts for review, feedback, and update as required.

· There are stakeholders and subject matter experts available to provide guidance and validation to the current state domain modelers The current state domain based information modeling process is as follows:

1. Determine roles among the participants that are fulfilling the Business Information Architect role (this process is described as though one BIA team member is performing all of these roles). Any person may fulfill more than one role, but will include:

a. Publisher – The person responsible for releasing official iterations of the BIA artifacts for subject matter expert review.

b. Information Analyst – The person(s) consuming documents such as current business documentation (policies, handbooks, directives, and user and technical documentation), functional requirements, process models, As-Is information models, and health industry information standards for gaps against the current state HYBIM model.

c. Information Modeler – The person(s) who will actually create and maintain the information model, diagrams and data dictionary using a Unified Modeling Language (UML) modeling tool.

2. Identify a common method for storing and sharing the current state domain information artifacts. It should be available and accessible to all information modelers associated with the work effort. Validated artifacts should use the following storing and sharing methods:

a. Establish a folder in the VHAHybrid ClearCase project.

b. Establish a folder in the VHA BA BIA SharePoint site for publishing and sharing current state domain documentation.[footnoteRef:4] [4: Note: The artifacts created may be deemed “acquisition-sensitive,” requiring documents only be shared with authorized individuals.]

3. Gather initial documentation

a. See “BIA Information Analyst Guide[footnoteRef:5],” for locating VA reference documents. [5: See embedded document in Appendix E.]

b. Attempt to identify relevant packages and files via the VistA Data Architecture Repository.

c. Review any documentation provided directly by the subject matter experts. Ideally this will include business rules and directives to lend guidance in identifying related current state applications/interfaces.

d. Review previous related information modeling products (if available)

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

4. Begin initial VistA As-Is Hybrid Information Model, – This is done by leveraging DAR export files as well as previously modeled information domains.

a. Reference relevant content from existing information domain models that have already been included in the VHAHybrid project, including common and domain-specific classes as appropriate.

b. Begin importing DAR file content and integrating into the model.

c. Execute ‘backward’ and ‘forward’ pointer reports in DAR to identify external domain touchpoints.

5. Generate initial Hybrid CIM.

a. Review the current state HYBIM model completed to-date to identify key classes that should be represented in the CIM.

b. Construct the separate CIM diagram.

c. Identify appropriate subject areas and label in the CIM accordingly.

6. Conduct initial Information Model content presentation – This is the first exposure of information modeling concepts and content to the SMEs.

a. Present slides.

b. Show examples from the initial modeling straw man (if available and time permits)

c. Solicit sources of content that would further inform the information model (interface documents, manuals, websites, etc.)

7. Baseline the Information Model prior to modeling sessions with SMEs.

a. Institute documentation procedures[footnoteRef:6] for any subsequent changes to the information model. [6: See embedded template with instructions in Appendix E of the “BIA Information Modeling Guiding Principles.”]

8. (Optional) Conduct information modeling sessions with SMEs.

a. Identify subject area-specific issues in the model and develop directed questions to facilitate feedback from SMEs.

b. Identify and generate Subject Area Diagrams from the Information Model as needed to facilitate communication with SMEs.

c. Package and distribute content in advance of sessions. Subject Area Diagrams may be distributed in Joint Pictures Expert Group (JPEG) format inserted in Microsoft Word docs, Portable Document Format (PDF) or HTML.

d. Capture feedback from SMEs and other work effort participants.

e. Evaluate potential Information Model changes based on feedback. For accepted changes, update the model and document the change in a log. (Note: The change log should be kept and maintained in the source control mechanism for the duration of the use of model). For changes not accepted, document and communicate the disposition and reason back to the project manager and contributing stakeholder.

9. Conclude information modeling sessions (if applicable).

a. Navigate through the current CIM and seek feedback and validation.

b. Identify areas in the HYBIM that may not be accounted for as applicable areas of the current state domain in question.

c. Identify areas in the HYBIM that do not appear to have functional requirements supporting the content.

d. Navigate through the model classes and attributes to seek feedback and validation on the descriptions, cardinality, enumerations and associations.

e. To the extent feasible, actively modify the model based on the SME feedback. For more complicated modifications, document the issue and incorporate the changes as soon as possible; this may occur after the face-to-face meetings, if necessary.

10. Confirm best practices from approved modeling guidelines have been utilized.

a. Review the "BIA Information Modeling Guidelines” document.

b. Perform a BIA peer review of the Information Model.

11. Begin development of the Information Model Summary Report (IMSR).

a. Retrieve the IMSR template and begin customizing to the work effort.

b. Document assumptions relevant to the Information Model (e.g., Audit logging is not being modeled.)

c. Document major findings regarding the current state domain.

d. Add narrative regarding key concepts in the CIM.

e. Add narrative regarding key concepts exposed in the HYBIM.

f. Add subsections for Subject Area Diagrams as appropriate and provide corresponding narratives.

12. Complete development of the IMSR

a. Insert graphic (PDF, HTML, JPG) views of the CIM, HYBIM, Subject Area, and Enumeration diagrams from the model.

b. Embed the Data Dictionary.

c. Review the acronymns and glossary in the appendix and make updates as appropriate.

d. Insert business owner and stakeholders from the domain modeling effort

e. Document the references used in support of developing the information model.

f. Update the HTML published version of the current model.

13. Solicit peer review of model content among the BIA analysts, modelers, and architects.

a. Evaluate potential Information Model changes based on feedback. Adjudicate the Peer Review Comments Matrix and share the results with the BIA Team. The Comment Review Matrix should be baselined and stored within the ClearCase repository.

b. Ensure that the IMSR has all track changes accepted and there are no lingering comments within the document. Ensure watermark states DRAFT.

14. Deliver the completed IMSR to the Business Owner of the current state review for review and sign-off.

15. Once approval is received from Business Owner, publish the approved IMSR to the BIA SharePoint site.[footnoteRef:7] [7: Refer to the BIA Artifact Location Guide embedded in Appendix E for all locations of storage for iEHR documentation]

16. Create a new/update an existing Business Architecture Specification Report (BASR) by embedding the IMSR (if applicable).

FUTURE STATE PROJECT WORK EFFORT

BIA generates artifacts that are the basis for creating the Information Modeling Summary Report (IMSR). These include:

· Normalized Data Objects Analysis – optional, only if BPA is engaged

· This analysis requires collecting the data objects from the process models created as part of the IPT and determining the set of unique data objects defined in the process models that identify key classes that populate the information model.[footnoteRef:8] [8: See the example embedded in Appendix E]

· If no process modeling is performed, project owner must provide detailed information requirements to support generation of class diagrams.

· Conceptual Information Model (CIM) of the project scope

· See Conceptual Information Model Section 3.1

· Logical Information Model (LIM) of the project scope

· See Logical Information Model Section 3.2

· Enumerations Diagram(s)

· Subject Area Diagrams – required if created

· See Subject Area Diagrams Section 6

· Normalized Data Object Diagrams – required if created

· See Normalized Data Objects Diagrams Section 7

· Data Dictionary

· See Data Dictionary information in Section 13.

· VistA As-Is / To-Be Gap Analysis (if applicable)

· This analysis requires a VistA Hybrid model (See Hybrid Information Models in Section 4) and then comparing the classes and attributes to the To-Be LIM of the project. 8

· Health Industry Information Gap Analysis – if applicable

· This analysis requires identifying potential sources to align with health industry standards for information exchange (such as the FHIM Information Model , Health Level 7 (HL7) current balloting standards, Health Information Technology Standards Panel (HITSP), etc.) and comparing that content with the To-Be LIM of the project. [footnoteRef:9] [9: See the example embedded in Appendix E]

A Requirements Traceability Matrix is a supporting document that identifies how the functional requirements for the capability are represented by classes in the information model. (Note: This document is not included in the iIMR and is not published. The Requirements Traceability Matrix will be stored and managed on the iEHR BIA Sharepoint location.)

The VistA Hybrid model will also be created if there is an authoritative VistA application that supports the scope of the project that has not already been completed under previous BIA activities. This will be published as a separate IMSR for domain work efforts. See the Current Domain Modeling work effort for guidance.

Future state Modeling Process This section includes a detailed process describing the current practice to be followed for performing project-related information modeling. Some key considerations driving the process include:

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

· The analysis-oriented process steps are not intended to be fully completed before other process steps begin, such as reviewing existing VistA or health industry information artifacts.

· 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. We will release iterations of the artifacts for review, feedback, and update as required.

· As the IPT process matures, it should evolve to include reviews of artifacts generated by other IPT roles, such as Informatics Experts, Solution and Enterprise Architects. Such artifacts should be reviewed to ensure consistency with the To-Be LIM or to identify gaps that may require modifications in either direction (e.g., an interface requires business information missing from the model, a new interface need is identified, or datatypes must be updated to align with terminology decisions).

The current project based (IPT) information modeling process is as follows:

1. Determine roles among the IPT participants that are fulfilling the Business Information Architect role (this process is described as though one BIA team member is performing all of these roles). Any person may fulfill more than one role, but will include:

a. Publisher – The person responsible for releasing official iterations of the BIA artifacts for IPT review.

b. Information Analyst – The person(s) consuming documents such as current business documentation (policies, handbooks, directives and user and technical documentation), functional requirements, process models, As-Is information models, and health industry information standards for gaps against the To-Be LIM.

c. Information Modeler – The person(s) who will actually create and maintain the information model, diagrams and data dictionary using a UML modeling tool.

2. Identify a common method for storing and sharing the project information artifacts. It should be available and accessible to all information modelers associated with the work effort. Validated artifacts should use the following storing and sharing methods:

a. Establish a folder in the VHBAO_model ClearCase project.

b. Establish a folder in the VHA BA BIA SharePoint site for publishing and sharing relevant project documentation.[footnoteRef:10] [10: Note: The artifacts created may be deemed “acquisition-sensitive,” requiring documents only be shared with authorized individuals.]

3. Gather initial documentation

a. See “BIA Information Analyst Guide[footnoteRef:11],” for locating VA reference documents. [11: See embedded document in Appendix E.]

b. Attempt to identify relevant packages and files via the VistA Data Architecture Repository.

c. Review any documentation provided directly by the IPT leads. Ideally this will include a scope description and/or charter.

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

e. Determine status of the Federal Health Information Model (FHIM) as related to the work effort.

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

4. Determine if a Business Architecture Specification Report exists and if so, review for detailed requirements previously identified by Business Architecture.

5. Identity if logical current state models already exist for the project subject areas from previous work efforts, BIA will use these for reference.

6. If the project requires current state information that has not been previously modeled, determine authoritative source for this business information.

a. If VistA is the source, import DAR file content for information relevant to the project subject areas and develop a logical representation of the information imported from VistA.

b. Otherwise if VistA is not the source, create logical version of current state information that is related to the project subject areas. This is required to create equivalent To-Be representations of the classes.

7. Obtain confirmation of As-Is logical information requirements with the Business Owner/SMEs.

8. Begin To-Be information modeling

a. Import content from existing Business Information Model diagrams, if applicable, including the As-Is logical information requirements described above. This may include subject areas from current state domains that have already been diagrammed and represented in the current state logical model. Other future state diagrams may also inform and add content to this model.

b. Begin laying out additional key classes expected for the LIM based on the analysis performed to-date.

9. Participate in initial requirements gathering sessions with SMEs. These sessions will often identify information needs that can be used to facilitate constructing the To-Be LIM.

10. Participate in initial process modeling sessions with SMEs (if applicable). These sessions identify data objects that may facilitate constructing the To-Be LIM, and will eventually lead to the Normalized Data Objects Analysis[footnoteRef:12]. Also, additional requirements may be identified. [12: See embedded template with instructions in Appendix E of the “BIA Information Modeling Guiding Principles.”]

11. Review of initial requirements (if applicable). This is the input for the initial Requirements Traceability Matrix.12

12. Review of initial process models (if applicable). This is the input for the initial iteration of the Normalized Data Objects Analysis.12

13. Elaborate the To-Be LIM

a. Identify additional existing classes with content that can support the processes and requirements identified for the work effort and bring them into the model.

b. Create new classes, associations, and attributes to support the processes and requirements identified for the work effort.

c. Identify issues with naming conventions, associations or cardinality that may result in recommending changes to the overall Business Information Model content.

d. Add attributes as needed to existing business Information Model classes (Note: These classes would have been imported from existing diagrams), but annotate the new attributes versus original attributes of the class (mark the additions with “NEW” in the stereotype keyword).

e. Remove attributes as needed. Mark those attributes in stereotype keyword as “DEL.”

f. Modify attributes as needed. Mark those attributes in stereotype keyword as “MOD.”

g. Rename attributes as needed. Mark those attributes in stereotype keyword as ‘REN.” Note the original name as an AKA in the documentation section.

h. Identify existing enumerations applicable based on the classes selected and bring them into the To-Be model.

i. Begin identifying additional enumerations that may be appropriate to the work effort (including sample values is a best practice).

j. Insert data dictionary entries into new model “objects” (i.e., classes, attributes, and enumerations) and associations.

k. Bring existing Business Information Model complex data types into the To-Be model.

14. Generate initial To-Be CIM.

a. Review the To-Be LIM completed to-date to identify key classes that should be represented in the CIM.

b. Construct the separate CIM diagram.

c. Identify appropriate subject areas and label in the CIM accordingly.

15. Perform initial analysis of the FHIM, if applicable. The FHIM may not have adequate material to support performing a gap analysis. If there is adequate content, the analysis may be performed in iterations. One possible approach would be focusing on classes selected for the CIM, then all classes and attributes.

16. (Optional) Begin a gap analysis between one or more of the following items and the Department of Defense/VA Target Health Standards Profile (see Appendix F).

a. Messages and content that conform to health industry information standards

b. Analysis and modeling already captured in the FHIM content

c. Content that VA or Department of Defense (DoD) would exchange with external trading partners

17. (Optional) Identify web-accessible content available from federal organizations relevant to the work effort (e.g., CDC, FDA, NIH, etc.). The requirements identified to date and SME feedback may suggest there is content avaialable on these websites that may inform the information model. Any site reviewed should be documented as a reference in the Interoperabiltity section of the IMSR.

18. Continue integration of process model content into information modeling (if applicable).

a. Document inventory of process model data objects

b. Normalize process model data objects, harmonizing with existing Normalized Data Objects as appropriate.

c. Identify focal classes for the new normalized data objects.

d. Draft working descriptions for the objects if they are not already present.

e. Add focal classes to the To-Be model if they do not already exist.

f. (Optional) Create normalized objects in model as instances of focal classes.

19. Begin integrating requirements into information model(s) (if applicable).

a. Begin marking up a current version of the requirements for traceability to the current To-Be information model. Annotate requirements that present issues for traceability to information modeling.

20. Participate in ongoing process model and requirements discussions with subject matter experts (if applicable).

a. Identify changes to process models and requirements that impact the information model.

b. Update the model as appropriate.

21. Prepare interim Information Model content for SME discussions.

a. Prepare slide presentation for initial SME discussion.

b. Generate HTML version of model for sharing with OIT and the project team.

c. Identify supplemental content for discussion (normalized objects, data dictionary content)

22. Conduct initial Information Model content presentation (remote) – This is the first exposure of information modeling concepts and content to the SMEs.

a. Present slides.

b. Review highlights of the CIM.

c. Show examples from the LIM (if available and time permits)

d. Solicit sources of content that would further inform the LIM (interface documents, manuals, websites, etc.)

23. Baseline the Information Model in the BIA ClearCase repository prior to modeling sessions with SMEs.

a. Institute documentation procedures for any subsequent changes to the Information Model.

24. (Optional) Conduct remote information modeling sessions with SMEs.

a. Identify subject area-specific issues in the model and develop directed questions to facilitate feedback from SMEs.

b. Identify and generate Subject Area Diagrams from the LIM as needed to facilitate communication with SMEs.

c. Identify relevant functional requirements related to the subject area.

d. Identify relevant process model diagrams related to the subject area (if applicable).

e. Package and distribute content in advance of sessions (Subject Area Diagrams may be distributed in PDF).

f. Reserve navigating in the LIM to clarifying issues or confirming feedback.

g. Capture feedback from SMEs and other work effort participants.

h. Evaluate potential Information Model changes based on feedback. For accepted changes, update the model and document the change in the Comment Review Log. For changes not accepted, document and communicate the disposition and reason in the Comment Review Log and communicate the decision back to the project manager and the comment author.

25. Participate in face-to-face sessions for process modeling and requirements validation (if applicable).

a. Determine if face-to-face sessions result in scope clarification, process refactoring, and requirements discovery.

b. Document proposed changes to the model based on the information gathered from these sessions in the Comment Review Log.

26. Conduct face-to-face information modeling sessions (if applicable).

a. Identify outstanding issues in the process models or requirements requiring resolution to complete the information modeling.

b. Navigate through the current CIM and seek feedback and validation.

c. Using the current To-Be process models (if available), discuss data objects and how they are accounted for in the LIM to elicit feedback.

d. Identify areas in the LIM that may not be accounted for as parts of data objects in the process models (this activity may trigger changes to the process models).

e. Identify areas in the LIM that do not appear to have functional requirements supporting the content (this activity may trigger additions or clarifications in the requirements).

f. Navigate through the model classes and attributes to seek feedback and validation on the descriptions, cardinality, enumerations/valid values and associations.

g. To the extent feasible, actively modify the model based on the SME feedback. For more complicated modifications, document the issue in the Comment Review Log and incorporate the changes as soon as possible; this may occur after the face-to-face meetings, if necessary.

27. Confirm best practices from approved modeling guidelines have been utilized.

a. Review the "BIA Information Modeling Guidelines” document.

b. Conduct an initial BIA peer review (this is the first pass).

28. Begin development of the Information Modeling Summary Report (IMSR).

a. Retrieve the IMSR template and begin customizing to the work effort.

b. Document assumptions relevant to the Information Model (e.g., Auditing logging is not being modeled.)

c. Document major findings regarding the work effort.

d. Add narrative regarding key concepts in the CIM.

e. Add narrative regarding key concepts exposed in the LIM.

f. Add subsections for Subject Area Diagrams and/or Normalized Data Object Diagrams as appropriate and provide corresponding narratives.

g. Add narrative and table entries regarding a high-level comparison of the As-Is and To-Be Information Model diagrams.

29. Complete the VistA Hybrid Information Model, if it has not already been finished.

30. Complete the documented VistA As-Is/To-Be Gap Analysis, if it has not already been finished.

31. (Optional) Complete the documented Health Industry Information Gap Analysis, if it has not already been finished.

32. Update Information Model based on resolvable gaps with the As-Is, FHIM, or interoperability standards.

33. Complete development of the IMSR

a. Enter statistics for the “To-Be” model (classes, attributes, enumerations).

b. Insert PDF views of the CIM, LIM, Subject Area, Normalized Object, and Enumeration diagrams from the model.

c. Embed the Normalized Data Object Analysis[footnoteRef:13]. [13: See Normalized Data Object Diagram Checklist for example Template of a Normalized Data Object Analysis Spreadsheet]

d. Embed the VistA As-Is/To-Be Gap Analysis.

e. Embed the Health Industry Information Gap Analysis if one was completed.

f. Embed the Data Dictionary.

g. Review the acronyms and glossary in the appendix for any appropriate updates.

h. Insert stakeholders from the Business Requirements Document (BRD) if available; otherwise, use information from the work effort charter.

i. Document the references used in support of developing the information model.

j. Generate an HTML version of the current model for review and place in a zipped file.

k. Solicit peer review of the model content among the BIA Team.

i. All feedback is noted in the Comment Review Log for the project.

ii. Proposed changes to the model are adjucticated as follows:

1. If the change is formatting related and does not change business definition then the model is updated…