VA118-17-R-2324-032.docx

VETERAN - FOCUSED INTEGRATION PROCESS (VIP)

Major COTS Program Interface Development Guide

1. Overview The Veteran’s Affairs (VA), Veteran-focused Integration Process (VIP) is a Lean-Agile framework that services the interests of Veterans through the efficient streamlining of activities that occur within the enterprise. Acknowledging that there is not a “one size fits all” solution, the VIP artifact requirements can be tailored to accommodate the unique needs of Major Programs[footnoteRef:2] in an effective manner. Major Programs with a commercial off-the-shelf (COTS) solution, require execution on an accelerated timeline and the flexibility to incorporate artifacts provided by software vendors. The following guide outlines how major programs progress through the VIP lifecycle. [2: https://www.va.gov/op3/Enterprise_Program_Management_Office.asp]

Systems are part of other systems, are made up of subsystems, and interact with other systems. This applies to simple as well as complex systems, hardware systems and software systems. These interactions between your system and others are called interfaces.

An interface is a common functional or physical boundary between two systems of interest (SOI). Each interface can be considered to have a source, a destination, an interaction and exchanging of information.

Identifying interfaces help define the system’s boundaries and help with the understanding of the dependencies the SOI has with other systems and dependencies other systems have with your system. Failing to identify an interface can lead to project failure and not meet stakeholders’ expectation. Missing or incorrectly defined interfaces are often a major cause of cost overruns and product failures.

2. Interface Identification Process

The general steps in the Interface Identification Process are as follows:

1. Receipt of business requirements that identify specific capabilities that the IT solution must deliver.

2. Analysis and allocation of the needed capabilities to systems.

3. Analysis of the data needed by each capability, in one system at a time.

4. When it is found that data needed by one system resides in another system, then an interface must be specified.

This analytical process provides context to how the identified systems must interact with other systems, both external and internal.

Operational concepts, System Block Diagrams, Allocation Analysis, External Interface Block Diagrams and Interface Block Diagrams are all the artifacts that make up the Interface Design process. They are used to refine the interfaces between all elements that make up the system as a whole.

The Operational Concepts lay out different interfaces at different times in its life cycle so that no systems are left out. All stakeholders’ viewpoints will be identified and included in the Operational Concepts.

The System Block Diagrams show all architectural elements of the enterprise systems and their interfaces. These diagrams give an overall view, showing both internal and external interfaces.

An Allocation Analysis shows the interface between elements that are allocated to one requirement. Since there are interactions between these elements to satisfy one requirement, there is an interface between them.

External Interface Block Diagrams show the SOI and its external interfaces to other system elements throughout the system lifecycle, including development, testing, verification and maintenance, and should be found in the Operational Concepts.

Each identified system is required to have an Interface Block Diagram. The system of interest is shown on one side of the diagram and the other systems are shown on the other side, with interfaces shown between these elements.

Identifying and managing systems interfaces early help the system to solidify key drivers for the system that must be addressed in the system requirements.

3. Interface Definition Process

Once an interface has been identified, the following detailed interface information needs to be defined:

1. Information exchange description

2. High level systems interactions architecture

3. Level of interoperability, such as:

a. Non-electronic data

b. Unstructured, viewable electronic data

c. Non-standardized but structured, viewable electronic data

d. Computable Electronic data

4. Information element

5. Sending/Receiving system name, affiliated organization, broker/interface name and type

6. Message standard

7. Data exchange details

8. Exchange protocol

9. Characteristics of each system, the services involved in the interaction and the format,

10. Performance requirements

For interfaces with new or developing systems, a lot of these information will be TBD. For interfaces with existing systems, these interfaces should already have been defined in the form of tables, figures, and drawings in documents ranging from Interface Control Documents, Interface Exchange Matrix to Interface Design Document and our SOI must comply with the interfaces as defined in the above documents.

4. Interface Requirements Specification

Interface Requirements Specification is developed after all interfaces have been identified and defined. It defines requirements for system interactions. The interface requirement includes a reference to the specific requirement in the Interface Requirements Document (IRD) that defines the interface as shown in Figure 1.

Figure 1 – Interfaces interaction with requirements reference example

In this example, we are verifying that the System 1 Requests Data from System 2 per requirement #123 in the IRD, and System 2 returns the data using protocol xxx. There could be multiple interactions between System 1 and System 2 with a separate interface requirement for each of the interactions. This keeps the requirement as a simple, single interaction that is easier to verify and test.

All the interfaces need to be defined and all their requirements are documented in the IRD. All the interface requirements are verified and tested just like any software, hardware or systems requirements. The full requirements traceability matrix (RTM) show specifications mapped back to the original requirements.

5. Interface Architecture Artifacts The followings documents make up the Interface Architecture artifacts:

a. Information Exchange Matrix (IEM) The Information Exchange Matrix (IEM) describes the system data exchanges between systems within a node and from those systems to systems at other nodes. The focus of the System Information Exchange Matrix is on how the data exchanges will be implemented.

b. Interface Control Document (ICD) This Interface Control Document (ICD) specifies the exchanges and interfaces between the SOI and relevant systems within Veterans Affairs (VA), Department of Defense (DoD) and external third parties. This document provides details on the functional, performance, operational and design requirements for the interface. The intended audience is the project manager, project team, development team, and stakeholders interested in interfacing with the SOI.

c. DoDAF Operational Viewpoints (OV)2 DoDAF-described Models in the Operational Viewpoint describe the tasks and activities, operational elements, and resource flow exchanges required to conduct operations. A pure operational model is materiel independent. However, operations and their relationships may be influenced by new technologies, such as collaboration technology, where process improvements are in practice before policy can reflect the new procedures. There may be some cases, as well, in which it is necessary to document the way activities are performed, given the restrictions of current systems, to examine ways in which new systems could facilitate streamlining the activities. In such cases, operational models may have materiel constraints and requirements that need to be addressed. For this reason, it may be necessary to include some high-level system architectural data to augment information onto the operational models. The following OVs are most applicable to the System Interface Architecture:

· OV-1 (High Level Operational Concept Graphic): The OV-1 describes a mission, class of mission, or scenario. It shows the main operational concepts and interesting or unique aspects of operations. It describes the interactions

2 http://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_data/ between the subject architecture and its environment, and between the architecture and external systems. The OV-1 is the pictorial representation of the written content of the AV-1 Overview and Summary Information. Graphics alone are not sufficient for capturing the necessary architectural data.

· OV-2 (Operational Resource Flow Descriptions): The OV-2 depicts Operational Needlines that indicate a need to exchange resources. New to DoDAF V2.0, the OV-2 show flows of funding, personnel and materiel in addition to information. The OV-2 may also show the location of Operational facilities or locations, and may optionally be annotated to show flows of information, funding, people or materiel between Operational Activities. The Operational Activities shown in an OV-2 may be internal to the architecture, or may be external activities that communicate with those internal activities.

A Needline documents the required or actual exchanges of resources. A Needline is a conduit for one or more resource exchanges - i.e., it represents a logical bundle of Resource Flows. The OV-2 is not a communications link or communications network diagram but a high-level definition of the logical requirement for resource exchange.

· OV-3 (Operational Resource Flow Matrix): The OV-3 identifies the resource transfers that are necessary to support operations to achieve a specific operational task. This model is initially constructed from the information contained in the OV-2 Operational Resource Flow Description model. But the OV-3 provides a more detailed definition of the Resource Flows for operations within a community of anticipated users. The Operational Resource Flow Matrix details Resource Flow exchanges by identifying which Operational Activity and locations exchange what resources, with whom, why the resource is necessary, and the key attributes of the associated resources.

d. DoDAF System Viewpoints (SV) 2 The DoDAF-described Models within the Systems Viewpoint describes systems and interconnections providing for, or supporting, DoD functions. DoD functions include both warfighting and business functions. The Systems Models associate systems resources to the operational and capability requirements. These systems resources support the operational activities and facilitate the exchange of information. The Systems DoDAF-described Models are available for support of legacy systems. As architectures are updated, they should transition from Systems to Services and utilize the models within the Services Viewpoint. The following OVs are most applicable to the System Interface Architecture:

· SV-1 (Systems Interface Description): The SV-1 links together the operational and systems architecture models by depicting how Resources are structured and interact to realize the logical architecture specified in an OV-2 Operational Resource Flow Description. A SV-1 may represent the realization of a requirement specified in an OV-2 Operational Resource Flow Description (i.e., in a "To-Be" architecture), and so there may be many alternative SV models that could realize the operational requirement. Alternatively, in an "As-Is" architecture, the OV-2 Operational Resource Flow Description may simply be a simplified, logical representation of the SV-1 to allow communication of key Resource Flows to non-technical stakeholders. A System Resource Flow is a simplified representation of a pathway or network pattern, usually depicted graphically as a connector (i.e., a line with possible amplifying information). The SV-1 depicts all System Resource Flows between Systems that are of interest.

· SV-2 (Systems Resource Flows Description): A SV-2 specifies the System Resource Flows between Systems and may also list the protocol stacks used in connections. A SV-2 DoDAF-described Model is used to give a precise specification of a connection between Systems. This may be an existing connection, or a specification for a connection that is to be made.

· SV-3 (Systems-Systems Matrix): A SV-3 enables a quick overview of all the system resource interactions specified in one or more SV-1 Systems Interface Description models. The SV-3 provides a tabular summary of the system interactions specified in the SV-1 Systems Interface Description model for the Architectural Description. The matrix format supports a rapid assessment of potential commonalities and redundancies (or, if fault-tolerance is desired, the lack of redundancies). The SV-3 can be organized in a number of ways to emphasize the association of groups of system pairs in context with the architecture's purpose.

· SV-6 (Systems Resource Flow Matrix): The SV-6 specifies the characteristics of Resource Flow exchanges between systems. The SV-6 is the physical equivalent of the logical OV-3 table and provides detailed information on the system connections which implement the Resource Flow exchanges specified in OV-3. Non-automated Resource Flow exchanges, such as verbal orders, are also captured.

System Resource Flow exchanges express the relationship across the three basic architectural data elements of a SV (systems, system functions, and system Resource Flows) and focus on the specific aspects of the System Resource Flow and the system resource content. These aspects of the System Resource Flow exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation such as security policy and communications limitations.

The focus of SV-6 is on how the System Resource Flow exchange is affected, in system-specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the resource exchange. In addition, the System Resource Flow elements, their format and media type, accuracy, units of measurement, and system data standard are also described in the matrix.

· SV-7 (Systems Measures Matrix): The SV-7 specifies qualitative and quantitative measures (metrics) of resources; it specifies all of the measures. The measures are selected by the end user community and described by the architect.

Performance parameters include all performance characteristics for which requirements can be developed and specifications defined. The complete set of performance parameters may not be known at the early stages of Architectural Description, so it is to be expected that this model is updated throughout the specification, design, development, testing, and possibly even its deployment and operations lifecycle phases. The performance characteristics are captured in the Measures Meta-model group.

One of the primary purposes of SV-7 is to communicate which measures are considered most crucial for the successful achievement of the mission goals assigned and how those performance parameters will be met.

e. DoDAF Data and Information Viewpoint (DIV) 2 DoDAF-described Models within the Data and Information Viewpoint provide a means of portraying the operational and business information requirements and rules that are managed within and used as constraints on the organizations business activities. The DIV DoDAF-described Models provide means of ensuring that only those information items that are important to the organization's operations and business are managed as part of the enterprise. They are also useful foundations for discussion with the various stakeholders of the architecture (e.g., decision-makers, architects, developers). These stakeholders require varying levels of detail to support their roles within the enterprise. DoDAF V2.0 incorporates three levels of abstraction that correlate to the different levels associated with most data models developed in support of the operations or business. These levels are:

· DIV-1 (Conceptual Data Model): When building an architecture using a structured analysis approach, the items captured as part of the data model can be derived from the inputs and outputs associated to the organizations activities. Building the data model in this manner ties the data being managed within the architecture to the activities that necessitate that data. This provides a valuable construct enabling the information to be traceable to the strategic drivers of the architecture. This also enables the data to be used to map services and systems to the business operations. The conceptual data model would be a good tool to use when discussing this traceability with executive decision-makers and persons at that level.

· DIV-2 (Logical Data Model): The logical data model bridges the gap between the conceptual and physical-levels. The logical data model introduces attributes and structural rules that form the data structure. As evidenced by the content, this model provides more detail than the conceptual model and communicates more to the architects and systems analyst’s types of stakeholders. This is one model that helps bridge the gap between architecture and system development. It provides a valuable tool for generating requirements and test scripts against which services and systems can be tested.

· DIV-3 (Physical Data Model): Lastly, the physical data model is the actual data schema representative of the database that provides data to the services and applications using the data. This schema is usually a de-normalized data structure optimized to meet performance parameters. The physical data model usually can be generated from a well-defined logical data model then used by database developers and system developers or it can be developed separately from the logical data model (not the optimum method of development) and optimized by the database and system developers. This model can be used to develop XML message sets and other physical exchange specifications enabling the exchange of architecture information.

6. Configuration and Interface Testing

As more interfaces are defined and the interface design and requirements are architected, a lot of the TBDs in the Interface Definition phase will be filled out. This requires frequent updates to the ICD, IEM, IRD and other interface documents per the VA Configuration Management Plan (CMP). A Change Control Process (CCP) will be specified in accordance with VIP and ProPath Policy (if applicable) within the CMP. Change Control is the formal procedure used to help ensure that changes are executed in a controlled and coordinated manner. A detailed write up of all changes and recommended course of action(s) (COA) will be presented to the Change Control Board (CCB). These changes will be reviewed by the CCB and voting will be recorded for final approval and submission to PM and COR. All CCB actions, documents, designs, architecture artifacts, and interface codes will be deposited into the existing VA SharePoint repository in a VA environment that is compliant with VA enterprise CM guidelines and policies, as outlined in VA Directive 6004, “Configuration, Change, And Release Management Programs,” September 28, 2009, or any subsequent VA Policy and in the VA Office of Enterprise Development (OED) CM program plan.

The interface testing across agencies confirms the internal technical and functional performance of each application and the infrastructure that is part of the VA EHRM ecosystem i.e. VA, DoD, commercial entities and other agencies that interoperate with EHRM. The technical and functional tests validate that the requirements have been successfully implemented and the infrastructure performance is at the desired level. The interface requirements will be verified just like all the other system requirements.

Interface testing is conducted in two steps:

1. In a system engineering test environment with mock interfaces with other systems

2. On a complete, integrated system, with VA and non-VA interfaces.

The primary focus is to verify that the software components are functioning with each other in accordance with the requirements. Interface testing is performed in the system integration test (SIT) environment, which contain all the interfaces to the application, and the test team stages data defined and available to support integration testing. Coordination with external teams to identify and/or create test data in their systems for use by the test team is a key factor to confirm that the test team is ready to conduct system testing.

End-to-end test scenarios, which represent a collection of detailed test cases and step-by-step test scripts, will be created to validate system integration during this testing cycle.

Table 1 describes the process to conduct interface system testing. This process gives VA the ability to make an informed decision about the readiness of a release to go into production based on its ability to meet the functional and technical requirements. It also provides full traceability between the requirements to the test scripts and test case and to the test results and any related defects and their status.

Table 1: EHRM Interface Testing

Obtain information for the appropriate mock web services, if needed Verify the test environment setup

Develop scripts for data staging in test environment Automate data staging scripts to reduce efforts in baselining the environment

Confirm that test records are available in the external systems to conduct a complete end-to-end test Review and update the Master Test Plans and Test Scripts for each test site to include the site specific information. This is to confirm that deployments into the integrated test environment include all system components and appropriate information for external interfaces

Verify build is deployed to test environment where it will be tested using the planned test cases/scripts Smoke test build to verify it has been correctly installed in the test environment and is ready for testing Conduct TRR to determine readiness to start interface testing Document results of TRR

Log defects and facilitate/attend a triage meeting to discuss defects Update RTM with actual results and post all appropriate documentation

Communicate schedule, number of test cases executed, number of defects opened/closed among other trend related information, and remediation

Appendix A: Interface Control Document (ICD) Template

Appendix B: Cerner Overview of Risk-Based Processes image1.emf image2.emf

Microsoft_Visio_Drawing1.vsdx image3.emf

EHRM ICD Template v0.1.docx Department of Veterans Affairs

Electronic Health Record Modernization (EHRM) <System Name> Interface

Interface Control Document [v0.0] DRAFT

Office of Information and Technology (OI&T), Enterprise Program Management Office (EPMO), Software Engineering and Integration (SE&I)

<Month, Year>

Document Version History

The document version history will be used to track document changes throughout the cycle of the capability planning process. When changes are made, please provide the version number, name, job title and organization of the person updating, version date, and a description of the basic changes made by the respective version of the document.

Version Number

Person Updating

Version Date

Version Description

0.1

Table of Contents

Table of FIGUres

No table of figures entries found.

Scope

Instructions: Provide a brief introduction to the ICD, including which systems are interacting and the goals of the exchanges. Name any related systems that are specifically out of scope for this document. For example:

This document describes the interface between the VA’s <System Name> and the Cerner HealtheIntent platform to <summary of interface objective>. The goals of these exchanges are to:

Purpose

Instructions: Provide the purpose of the Interface Control document. What architecture and interfaces are being described? For example:

The purpose of this document is to describe the architecture and the interfaces for the exchange of Health Information from VistA to the Cerner EHR platforms.

This ICD describes the general concept of operations for the interface, defines the message structure and protocols, which govern the interchange of data, and identifies the communication paths along which the data is expected to travel.

Scope Overview

Instructions: Provide the business use cases this interface will support. Include any additional details, alternative uses, or any other relevant information about how the use cases will be supported.

The <System Name> interface will support the following Business Use Cases:

System Overview

Instructions: Provide a figure depicting the High Level Architecture View and describe the functionality and architecture of the interfacing systems as they relate to the proposed interface. If there are multiple interfaces between systems, provide a description for each.

Interface Overview

Instructions: Briefly describe the purpose of each interface to another external system at a functional level and the data exchanged between the interfaces. In particular, each system should be briefly summarized with special emphasis on the functionality related to the interface.

Data Domains

Instructions: Provide the data domains used by relevant interfaces. Provide an initial set of details associated with the system (namely the data domain parameters). To facilitate communications and discussion with Cerner, the title block preceding each data domain table below contains the field name from VistA and the associated Cerner data domain name is listed afterwards. A separate table should be created for each data domain.

<VistA Field Name 1> – <Cerner Data Domain Name 1>

DWFieldName

FieldDescription

<VistA Field Name 2> – <Cerner Data Domain Name 2>

DWFieldName

FieldDescription

<VistA Field Name 3> – <Cerner Data Domain Name 3>

DWFieldName

FieldDescription

Data Domain Models

The files presented below offer a means to analyze, in depth, the data models for each of the Data Domains the VA plans to provide to Cerner (PAMP+). Each file represents the data model details for each of the identified data domains.

1.6.1 Sample Data Domain Model:

System Interface Resource Flow

Instructions: Provide details in the Excel sheet below to describe the applicable resource flow exchanges

This section describes the characteristics of Resource Flow exchanges between systems, system components and between system boundaries.

Reference Documents

Instructions: List any relevant reference documents

1.

Operational Agreement

Instructions: Describe the operational agreement between the relevant parties. For example:

Any system changes by the provider or consumer system that affects this interface shall be coordinated with the appropriate points of contact (POCs) (see Appendix C).

Operational Environment

Instructions: Describe the operational environment the interface will follow. For example:

The individual system interface operational environment will follow the specific system prescribed environment.

Change Management

Instructions: Provide the change management procedures and controls in place. For example:

Modifications to this ICD will go through a change control process and be subject to agreement between VA, DoD and other project teams.

Interface Specification

Instructions: This section provides additional interface requirements unique to each interface. Where appropriate, interface requirements describe in Section 1 are referenced.

Identification of Interface

Instructions: Create a bulleted list of which interfaces will be further described in this section

Precedence and Criticality of Requirements

Instructions: Provide the order in which requirements should be addressed. If any operations should be processed before others, identify them here. Otherwise, state that all requirements shall be given equal priority.

Interface Details

Instructions: Provide any other relevant details on the interface

Transaction Types

Instructions: Briefly describe the types of transactions that will be used to move data among the component systems of the interface being defined. If multiple types of transactions will be used for different portions of the interface, a separate section may be included for each interface.

Performance Requirements

Instructions: Include a table that lists the interface’s Key Performance Indicators (KPI) and/or Service Level Requirements (SLR).

Security and Integrity

Instructions: This section and following subsections describe the security protocols and policies the interface will adhere to. For example:

<System Name> will comply with applicable policies, laws, and regulations including, but not limited to, Directive 6500.

Confidentiality

Instructions: Briefly describe how access security and data transmission security will be implemented for the interface.

Integrity

Instructions: Include a brief description of how data will be protected during transmission and how data integrity will be guaranteed. Describe how an individual on one system can be audited and held accountable for resulting actions on the other component of the interface.

Availability

Instructions: Briefly describe the security measures in place to ensure the data is accessible and guarded against gaps in service. Provide references to Service Level Requirements & Supported Availability Levels as needed.

Communication

Instructions: Describe any encryption, transmission, or physical security controls implemented to ensure communication security.

Interconnection Security Agreement

Instructions: Detail the technical and security requirements for establishing, operating, and maintaining the interface interconnection.

Approval

The undersigned acknowledge they have reviewed the ILER Interface Control Document and agree with the approach it presents. Changes to this document will be coordinated with and approved by the undersigned or their designated representatives.

xxxxxxx xxxxxxxxxxx

Date Approved:

xxxxxxxxxxxxxxx xxxxxxxxxxxxx

Date Approved:

xxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx

Date Approved:

Acronyms and Definitions

Acronym

Definition

Points of Contact (POCs)

Role

Name

Title

Phone

Email

Business Owners

Business Representatives

System Interconnection Specification

The following is the system interconnection specification for the interconnection between Vx130 systems and the Cerner Systems.

TODO:

1. Add the specification image1.png image2.emf

VA Vital Sign Workbook v1.xlsx

VistA VitalSigns DD

SourceAttributeSID SourceEntitySID FileNumber FieldNumber FileName FieldName FieldType FieldLength FieldCodes PointsToFileNumber GlobalNode Piece MultipleFileNumber ParentFileNumber WholeNumberDigits DecimalDigits Description

801228858 800064655 120.5 0.01 GMRV VITAL MEASUREMENT DATE/TIME VITALS TAKEN DateTime NULL NULL NULL ^GMR(120.5,D0,0) 1 NULL NULL NULL NULL This field contains the date/time this vital/measurement was taken by thecare provider.

801228862 800064655 120.5 0.02 GMRV VITAL MEASUREMENT PATIENT Pointer NULL DPT( 2 ^GMR(120.5,D0,0) 2 NULL NULL NULL NULL This field contains the name of the patient for whom this vital measurementdata was entered. Pointer to the PATIENT (#2) file.

801228864 800064655 120.5 0.03 GMRV VITAL MEASUREMENT VITAL TYPE Pointer NULL GMRD(120.51, 120.51 ^GMR(120.5,D0,0) 3 NULL NULL NULL NULL This field denotes the type of measurement for this record. Pointer tothe GMRV VITAL TYPE (#120.51) file.

801228868 800064655 120.5 0.04 GMRV VITAL MEASUREMENT DATE/TIME VITALS ENTERED DateTime NULL NULL NULL ^GMR(120.5,D0,0) 4 NULL NULL NULL NULL This field contains the date/time that this record was entered.

801228872 800064655 120.5 0.05 GMRV VITAL MEASUREMENT HOSPITAL LOCATION Pointer NULL SC( 44 ^GMR(120.5,D0,0) 5 NULL NULL NULL NULL This field contains the location where this measurement was taken. Pointer to the HOSPITAL LOCATION (#44) file.

801228876 800064655 120.5 0.06 GMRV VITAL MEASUREMENT ENTERED BY Pointer NULL VA(200, 200 ^GMR(120.5,D0,0) 6 NULL NULL NULL NULL This field contains the name of the person who edited the file entry. Pointer to the NEW PERSON (#200) file.

801228880 800064655 120.5 1.2 GMRV VITAL MEASUREMENT RATE FreeText NULL NULL NULL ^GMR(120.5,D0,0) 8 NULL NULL NULL NULL This field contains the numeric value associated with this vitalmeasurement.

801228886 800064655 120.5 1.4 GMRV VITAL MEASUREMENT SUPPLEMENTAL O2 FreeText 30 NULL NULL ^GMR(120.5,D0,0) 10 NULL NULL NULL NULL This field stores the information of the supplemental oxygen as follows: .5-20 l/min (liters/minute) and/or 21-100 % of oxygen concentrationFor example: 4.5 l/min 40% 4.5 l/min 40 %

801228889 800064655 120.5 2 GMRV VITAL MEASUREMENT ENTERED IN ERROR SetOfCodes NULL 1:YES; NULL ^GMR(120.5,D0,2) 1 NULL NULL NULL NULL This field indicates that this record was flagged as entered in error.

801228893 800064655 120.5 3 GMRV VITAL MEASUREMENT ERROR ENTERED BY Pointer NULL VA(200, 200 ^GMR(120.5,D0,2) 2 NULL NULL NULL NULL This field indicates the name of the person responsible for entering the record in error. Pointer to the NEW PERSON (#200) file.

801228897 800064655 120.5 4 GMRV VITAL MEASUREMENT REASON ENTERED IN ERROR SubFile NULL NULL NULL ^GMR(120.5,D0,2.1) 0 120.506 NULL NULL NULL This multiple contains a list of reasons for entering a vital measurement in error.

801228902 800064655 120.5 5 GMRV VITAL MEASUREMENT QUALIFIER SubFile NULL NULL NULL ^GMR(120.5,D0,5) 0 120.505 NULL NULL NULL A list of qualifiers associated with this measurement.

VistA VitalType DD

SourceAttributeSID SourceEntitySID FileNumber FieldNumber FileName FieldName FieldType FieldLength FieldCodes PointsToFileNumber GlobalNode Piece MultipleFileNumber ParentFileNumber WholeNumberDigits DecimalDigits Description

801228916 800064657 120.51 0.01 GMRV VITAL TYPE NAME FreeText 50 NULL NULL ^GMRD(120.51,D0,0) 1 NULL NULL NULL NULL This field reflects a list of vital signs/physical measurement types.

801228919 800064657 120.51 1 GMRV VITAL TYPE ABBREVIATION FreeText 5 NULL NULL ^GMRD(120.51,D0,0) 2 NULL NULL NULL NULL This field contains an abbreviation for this vital type.

801228923 800064657 120.51 3 GMRV VITAL TYPE RATE SetOfCodes NULL 0:NO;1:YES; NULL ^GMRD(120.51,D0,0) 4 NULL NULL NULL NULL This field specifies whether or not the vital measurement record withthis vital type has a rate associated with it.

801228927 800064657 120.51 4 GMRV VITAL TYPE RATE INPUT TRANSFORM MCode NULL NULL NULL ^GMRD(120.51,D0,1) 1 NULL NULL NULL NULL If a rate is specified for a vital measurement record, this field checksthe data validity. The code stored in this field should only be updatedby someone with programmer's access to the FileMan.

801228930 800064657 120.51 5 GMRV VITAL TYPE RATE HELP FreeText 30 NULL NULL ^GMRD(120.51,D0,0) 6 NULL NULL NULL NULL This field contains the name of the Help Frame associated with thisVital Type.

801228933 800064657 120.51 7 GMRV VITAL TYPE PCE ABBREVIATION FreeText 10 NULL NULL ^GMRD(120.51,D0,0) 7 NULL NULL NULL NULL This field contains the PCE Abbreviation for this Vital Type.

804530406 800064657 120.51 8 GMRV VITAL TYPE CODING SYSTEM SubFile NULL NULL NULL ^GMRD(120.51,D0,2) 0 120.518 NULL NULL NULL This multiple stores the coding system(s) associated with the codes identifying this GMRV VITAL TYPE.

801228936 800064657 120.51 99.98 GMRV VITAL TYPE MASTER ENTRY FOR VUID SetOfCodes NULL 0:NO;1:YES; NULL ^GMRD(120.51,D0,"VUID") 2 NULL NULL NULL NULL This field identifies the Master entry for a VUID associated with a Term/Concept.

801228948 800064657 120.51 99.99 GMRV VITAL TYPE VUID FreeText 20 NULL NULL ^GMRD(120.51,D0,"VUID") 1 NULL NULL NULL NULL VHA Unique ID (VUID). A unique meaningless integer assigned to referenceterms VHA wide.

801228952 800064657 120.51 99.991 GMRV VITAL TYPE EFFECTIVE DATE/TIME SubFile NULL NULL NULL ^GMRD(120.51,D0,"TERMSTATUS") 0 120.5199 NULL NULL NULL Describes the pair Status and Effective Date/Time for each reference term.

VISTA-to-CDW Mapping

DatabaseName DWPhysicalSchemaName DWPhysicalTableName DWFieldName FileNumber FileName FieldNumber FieldName MapComments DWFieldTechnicalDescription GlobalLocation FieldDescription

FDW10 Vital VitalSign_120_5_v004 VitalSignIEN NULL NULL NULL NULL NULL NULL NULL NULL

FDW10 Vital VitalSign_120_5_v004 VitalSignTakenDateTime 120.5 GMRV VITAL MEASUREMENT 0.01 DATE/TIME VITALS TAKEN $Piece($Get(^GMR(120.5,D0,0)),"^",1) This field contains the date/time this vital/measurement was taken by the care provider.

FDW10 Vital VitalSign_120_5_v004 VitalSignTakenDateTimeTransformSID 120.5 GMRV VITAL MEASUREMENT 0.01 DATE/TIME VITALS TAKEN $Piece($Get(^GMR(120.5,D0,0)),"^",1) This field contains the date/time this vital/measurement was taken by the care provider.

FDW10 Vital VitalSign_120_5_v004 VitalSignTakenVistaErrorDate 120.5 GMRV VITAL MEASUREMENT 0.01 DATE/TIME VITALS TAKEN $Piece($Get(^GMR(120.5,D0,0)),"^",1) This field contains the date/time this vital/measurement was taken by the care provider.

FDW10 Vital VitalSign_120_5_v004 PatientIEN 120.5 GMRV VITAL MEASUREMENT 0.02 PATIENT NULL NULL $Piece($Get(^GMR(120.5,D0,0)),"^",2) This field contains the name of the patient for whom this vital measurement data was entered. Pointer to the PATIENT (#2) file.

FDW10 Vital VitalSign_120_5_v004 VitalTypeIEN 120.5 GMRV VITAL MEASUREMENT 0.03 VITAL TYPE NULL NULL $Piece($Get(^GMR(120.5,D0,0)),"^",3) This field denotes the type of measurement for this record. Pointer to the GMRV VITAL TYPE (#120.51) file.

FDW10 Vital VitalSign_120_5_v004 VitalSignEnteredDateTime 120.5 GMRV VITAL MEASUREMENT 0.04 DATE/TIME VITALS ENTERED NULL NULL $Piece($Get(^GMR(120.5,D0,0)),"^",4) This field contains the date/time that this record was entered.

FDW10 Vital VitalSign_120_5_v004 VitalSignEnteredDateTimeTransformSID 120.5 GMRV VITAL MEASUREMENT 0.04 DATE/TIME VITALS ENTERED $Piece($Get(^GMR(120.5,D0,0)),"^",4) This field contains the date/time that this record was entered.

FDW10 Vital VitalSign_120_5_v004 VitalSignEnteredVistaErrorDate 120.5 GMRV VITAL MEASUREMENT 0.04 DATE/TIME VITALS ENTERED $Piece($Get(^GMR(120.5,D0,0)),"^",4) This field contains the date/time that this record was entered.

FDW10 Vital VitalSign_120_5_v004 LocationIEN 120.5 GMRV VITAL MEASUREMENT 0.05 HOSPITAL LOCATION NULL NULL $Piece($Get(^GMR(120.5,D0,0)),"^",5) This field contains the location where this measurement was taken. Pointer to the HOSPITAL LOCATION (#44) file.

FDW10 Vital VitalSign_120_5_v004 StaffIEN 120.5 GMRV VITAL MEASUREMENT 0.06 ENTERED BY NULL NULL $Piece($Get(^GMR(120.5,D0,0)),"^",6) This field contains the name of the person who edited the file entry. Pointer to the NEW PERSON (#200) file.

FDW10 Vital VitalSign_120_5_v004 VitalResult 120.5 GMRV VITAL MEASUREMENT 1.2 RATE NULL NULL $Piece($Get(^GMR(120.5,D0,0)),"^",8) This field contains the numeric value associated with this vital measurement.

FDW10 Vital VitalSign_120_5_v004 SupplementalO2 120.5 GMRV VITAL MEASUREMENT 1.4 SUPPLEMENTAL O2 NULL NULL $Piece($Get(^GMR(120.5,D0,0)),"^",10) This field stores the information of the supplemental oxygen as follows: .5-20 l/min (liters/minute) and/or 21-100 % of oxygen concentration For example: 4.5 l/min 40% 4.5 l/min 40 %

FDW10 Vital VitalSign_120_5_v004 EnteredInErrorFlag 120.5 GMRV VITAL MEASUREMENT 2 ENTERED IN ERROR 1:"Y",:$Extract(EnteredInErrorFlag,1) If '1' then 'Y' Else get the first character from the source field $Piece($Get(^GMR(120.5,D0,2)),"^",1) This field indicates that this record was flagged as entered in error.

FDW10 Vital VitalSign_120_5_v004 ErrorEnteredByStaffIEN 120.5 GMRV VITAL MEASUREMENT 3 ERROR ENTERED BY NULL NULL $Piece($Get(^GMR(120.5,D0,2)),"^",2) This field indicates the name of the person responsible for entering the record in error. Pointer to the NEW PERSON (#200) file.

CDW VitalSigns

ScrVitalIEN Sta3n VitalSignTakenDateTime VitalSignTakenVistaErrorDate VitalSignTakenDateTimeTransformSID VitalSignEnteredDateTime VitalSignEnteredVistaErrorDate VitalSignEnteredDateTimeTransformSID ScrPatientIEN VitalTypeIEN VitalResult SupplementalO2 LocationIEN ScrStaffIEN ErrorEnteredByStaffIEN EnteredInErrorFlag OpCode VistaCreateDate VistaEditDate

41554927 663 1/1/17 11:24 NULL NULL 1/1/17 11:25 NULL NULL 2277 1 168/77 NULL 3716 54162 NULL NULL NULL 1/1/17 11:26 1/1/17 11:26

51554927 663 1/1/17 11:24 NULL NULL 1/1/17 11:25 NULL NULL 2277 5 55 NULL 3716 54162 NULL NULL NULL 1/1/17 11:26 1/1/17 11:26

61554927 663 1/1/17 11:24 NULL NULL 1/1/17 11:25 NULL NULL 2277 22 8 NULL 3716 54162 NULL NULL NULL 1/1/17 11:26 1/1/17 11:26

71554927 663 1/1/17 11:24 NULL NULL 1/1/17 11:25 NULL NULL 2277 3 18 NULL 3716 54162 NULL NULL NULL 1/1/17 11:26 1/1/17 11:26

81554927 663 1/1/17 11:24 NULL NULL 1/1/17 11:25 NULL NULL 2277 2 97.9 NULL 3716 54162 NULL NULL NULL 1/1/17 11:26 1/1/17 11:26

38183831 660 1/1/16 11:32 NULL NULL 1/1/16 11:34 NULL NULL 3611 2 97.4 NULL 2101 210721 NULL NULL NULL 1/1/16 10:35 1/1/16 10:35

48183831 660 1/1/16 11:32 NULL NULL 1/1/16 11:34 NULL NULL 3611 5 86 NULL 2101 210721 NULL NULL NULL 1/1/16 10:35 1/1/16 10:35

58183831 660 1/1/16 11:32 NULL NULL 1/1/16 11:34 NULL NULL 3611 3 20 NULL 2101 210721 NULL NULL NULL 1/1/16 10:35 1/1/16 10:35

68183831 660 1/1/16 11:32 NULL NULL 1/1/16 11:34 NULL NULL 3611 1 177/103 NULL 2101 210721 NULL NULL NULL 1/1/16 10:35 1/1/16 10:35

78183831 660 1/1/16 11:32 NULL NULL 1/1/16 11:34 NULL NULL 3611 22 6 NULL 2101 210721 NULL NULL NULL 1/1/16 10:35 1/1/16 10:35

88183831 660 1/1/16 11:32 NULL NULL 1/1/16 11:34 NULL NULL 3611 21 96 NULL 2101 210721 NULL NULL NULL 1/1/16 10:35 1/1/16 10:35

70283831 660 1/1/16 11:58 NULL NULL 1/1/16 11:59 NULL NULL 3611 9 226.86 NULL 2101 622392 NULL NULL NULL 1/1/16 11:00 1/1/16 11:00

50442281 648 1/1/15 10:18 NULL NULL 1/1/15 10:19 NULL NULL 4657 2 97.3 NULL 5254 342010 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

60442281 648 1/1/15 10:18 NULL NULL 1/1/15 10:19 NULL NULL 4657 5 54 NULL 5254 342010 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

70442281 648 1/1/15 10:18 NULL NULL 1/1/15 10:19 NULL NULL 4657 3 20 NULL 5254 342010 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

80442281 648 1/1/15 10:18 NULL NULL 1/1/15 10:19 NULL NULL 4657 1 138/75 NULL 5254 342010 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

90442281 648 1/1/15 10:18 NULL NULL 1/1/15 10:19 NULL NULL 4657 22 5 NULL 5254 342010 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

1442281 648 1/1/15 10:18 NULL NULL 1/1/15 10:19 NULL NULL 4657 21 90 l/min % 5254 342010 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

89183831 660 1/1/16 11:48 NULL NULL 1/1/16 11:49 NULL NULL 9486 2 98.4 NULL 2101 364432 NULL NULL NULL 1/1/16 10:50 1/1/16 10:50

99183831 660 1/1/16 11:48 NULL NULL 1/1/16 11:49 NULL NULL 9486 5 102 NULL 2101 364432 NULL NULL NULL 1/1/16 10:50 1/1/16 10:50

283831 660 1/1/16 11:48 NULL NULL 1/1/16 11:49 NULL NULL 9486 3 20 NULL 2101 364432 NULL NULL NULL 1/1/16 10:50 1/1/16 10:50

10283831 660 1/1/16 11:48 NULL NULL 1/1/16 11:49 NULL NULL 9486 1 124/87 NULL 2101 364432 NULL NULL NULL 1/1/16 10:50 1/1/16 10:50

20283831 660 1/1/16 11:48 NULL NULL 1/1/16 11:49 NULL NULL 9486 22 3 NULL 2101 364432 NULL NULL NULL 1/1/16 10:50 1/1/16 10:50

30283831 660 1/1/16 11:48 NULL NULL 1/1/16 11:49 NULL NULL 9486 21 97 NULL 2101 364432 NULL NULL NULL 1/1/16 10:50 1/1/16 10:50

58365855 691 1/1/14 10:07 NULL NULL 1/1/14 10:07 NULL NULL 11925 2 97.5 NULL 1316 807375745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

68365855 691 1/1/14 10:07 NULL NULL 1/1/14 10:08 NULL NULL 11925 4 0 NULL 1316 807375745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

63454927 663 1/1/17 10:14 NULL NULL 1/1/17 10:14 NULL NULL 12575 22 8 NULL 4116 893364 NULL NULL NULL 1/1/17 10:16 1/1/17 10:16

28454927 663 1/1/17 10:51 NULL NULL 1/1/17 10:51 NULL NULL 12694 22 8 NULL 4116 893364 NULL NULL NULL 1/1/17 10:52 1/1/17 10:52

52465855 691 1/1/14 10:34 NULL NULL 1/1/14 10:34 NULL NULL 18762 4 6 NULL 1320 22643 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

43342281 648 1/1/15 10:02 NULL NULL 1/1/15 10:03 NULL NULL 19810 2 98.1 NULL 5261 124249 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

53342281 648 1/1/15 10:02 NULL NULL 1/1/15 10:03 NULL NULL 19810 5 80 NULL 5261 124249 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

63342281 648 1/1/15 10:02 NULL NULL 1/1/15 10:03 NULL NULL 19810 3 18 NULL 5261 124249 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

73342281 648 1/1/15 10:02 NULL NULL 1/1/15 10:03 NULL NULL 19810 1 137/88 NULL 5261 124249 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

83342281 648 1/1/15 10:02 NULL NULL 1/1/15 10:03 NULL NULL 19810 22 0 NULL 5261 124249 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

93342281 648 1/1/15 10:02 NULL NULL 1/1/15 10:03 NULL NULL 19810 21 97 l/min % 5261 124249 NULL NULL NULL 1/1/00 0:00 4/9/15 19:47

57365855 691 1/1/14 10:00 NULL NULL 1/1/14 10:00 NULL NULL 20038 4 5 NULL 1316 387457745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

83454927 663 1/1/17 10:15 NULL NULL 1/1/17 10:15 NULL NULL 20588 22 3 NULL 11205 494426 NULL NULL NULL 1/1/17 10:17 1/1/17 10:17

4454927 663 1/1/17 10:15 NULL NULL 1/1/17 10:16 NULL NULL 24755 2 100.2 NULL 16298 56045 NULL NULL NULL 1/1/17 10:18 1/1/17 10:18

14454927 663 1/1/17 10:15 NULL NULL 1/1/17 10:16 NULL NULL 24755 5 61 NULL 16298 56045 NULL NULL NULL 1/1/17 10:18 1/1/17 10:18

24454927 663 1/1/17 10:15 NULL NULL 1/1/17 10:16 NULL NULL 24755 3 20 NULL 16298 56045 NULL NULL NULL 1/1/17 10:18 1/1/17 10:18

34454927 663 1/1/17 10:15 NULL NULL 1/1/17 10:16 NULL NULL 24755 1 153/91 NULL 16298 56045 NULL NULL NULL 1/1/17 10:18 1/1/17 10:18

44454927 663 1/1/17 10:15 NULL NULL 1/1/17 10:16 NULL NULL 24755 22 0 NULL 16298 56045 NULL NULL NULL 1/1/17 10:18 1/1/17 10:18

54454927 663 1/1/17 10:15 NULL NULL 1/1/17 10:16 NULL NULL 24755 21 94 2 l/min 16298 56045 NULL NULL NULL 1/1/17 10:18 1/1/17 10:18

61465855 691 12/31/13 15:29 NULL NULL 1/1/14 10:30 NULL NULL 24944 4 2 NULL 12896 563495745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

67365855 691 1/1/14 10:00 NULL NULL 1/1/14 10:00 NULL NULL 35505 4 7 NULL 518 22643 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

53465855 691 1/1/14 10:38 NULL NULL 1/1/14 10:38 NULL NULL 36834 1 147/73 NULL 1316 387457745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

63465855 691 1/1/14 10:38 NULL NULL 1/1/14 10:38 NULL NULL 36834 5 62 NULL 1316 387457745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

59183831 660 1/1/16 11:43 NULL NULL 1/1/16 11:43 NULL NULL 40366 22 9 NULL 4 55891 NULL NULL NULL 1/1/16 10:43 1/1/16 10:43

30465855 691 1/1/14 10:20 NULL NULL 1/1/14 10:20 NULL NULL 41807 4 10 NULL 1317 45416 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

2454927 663 1/1/17 9:57 NULL NULL 1/1/17 9:57 NULL NULL 43856 22 8 NULL 4116 893364 NULL NULL NULL 1/1/17 9:58 1/1/17 9:58

86454927 663 1/1/17 10:40 NULL NULL 1/1/17 10:40 NULL NULL 48867 22 0 NULL 4116 73207 NULL NULL NULL 1/1/17 10:41 1/1/17 10:41

51283831 660 1/1/16 12:03 NULL NULL 1/1/16 12:03 NULL NULL 50474 22 6 NULL 2516 151631 NULL NULL NULL 1/1/16 11:05 1/1/16 11:05

61283831 660 1/1/16 12:03 NULL NULL 1/1/16 12:04 NULL NULL 50474 22 6 NULL 2516 151631 NULL NULL NULL 1/1/16 11:05 1/1/16 11:05

39365855 691 1/1/14 10:13 NULL NULL 1/1/14 10:14 NULL NULL 50727 1 116/60 NULL 525 794533256 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

49365855 691 1/1/14 10:13 NULL NULL 1/1/14 10:14 NULL NULL 50727 5 70 NULL 525 794533256 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

80283831 660 1/1/16 11:59 NULL NULL 1/1/16 11:59 NULL NULL 51198 2 97.8 NULL 2101 210721 NULL NULL NULL 1/1/16 11:00 1/1/16 11:00

90283831 660 1/1/16 11:59 NULL NULL 1/1/16 11:59 NULL NULL 51198 5 92 NULL 2101 210721 NULL NULL NULL 1/1/16 11:00 1/1/16 11:00

1283831 660 1/1/16 11:59 NULL NULL 1/1/16 11:59 NULL NULL 51198 3 16 NULL 2101 210721 NULL NULL NULL 1/1/16 11:00 1/1/16 11:00

11283831 660 1/1/16 11:59 NULL NULL 1/1/16 11:59 NULL NULL 51198 1 121/81 NULL 2101 210721 NULL NULL NULL 1/1/16 11:00 1/1/16 11:00

21283831 660 1/1/16 11:59 NULL NULL 1/1/16 11:59 NULL NULL 51198 22 3 NULL 2101 210721 NULL NULL NULL 1/1/16 11:00 1/1/16 11:00

31283831 660 1/1/16 11:59 NULL NULL 1/1/16 11:59 NULL NULL 51198 21 99 NULL 2101 210721 NULL NULL NULL 1/1/16 11:00 1/1/16 11:00

80465855 691 1/1/14 10:21 NULL NULL 1/1/14 10:22 NULL NULL 53985 5 76 NULL 11786 124455745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

90465855 691 1/1/14 10:21 NULL NULL 1/1/14 10:22 NULL NULL 53985 1 131/94 NULL 11786 124455745 NULL NULL NULL 1/1/00 0:00 4/9/15 23:42

93183831 660 1/1/16 11:01 NULL NULL 1/1/16 11:01 NULL NULL 59685 22 5 NULL 2516 10139 NULL NULL NULL 1/1/16 10:02 1/1/16 10:02

36365855 691 1/1/14 9:55 NULL NULL 1/1/14 9:57 NULL NULL 65089 1 111/76 NULL 526 885686745 NULL NULL NULL…