Attachment B - RTLS_National_Enterprise_Data_Architecture_12.0.pdf

DXC Technology Military Health and Veterans Affairs (MHVA)

Real Time Location System (RTLS)

National Enterprise Data Architecture

September 2017

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

National RTLS Enterprise Data Architecture ii September 11, 2017

Revision History Date Version Description Author September 11,

12.0 Updated version number and date to reflect VA acceptance DXC

August 31, 2017 11.1 Updated data dictionaries and data models:

• InSites ODS

• InSites BI

• WaveMark EiRTLS

• OATSystems

Updated:

• Table 1 RTLS Data Flow Data Store Descriptions

• Section 2.4 Data Value Standards

DXC

October 21, 2016 11.0 Updated Data Retention White Paper (VA acceptance) HPE

October 17, 2016 10.10 Updated Data Retention White Paper. HPE

October 11, 2016 10.9 Updated Table 7, Data retention by data store. Updated the Data Retention WP to include enhanced storage associated with ECP 2061.

HPE

September 23,

10.8 Updated data retention content HPE

August 26, 2016 10.7 Removed NDR content Updated data dictionaries:

• InSites BI

• Censitrac HL

• InSites ODS

• WaveMark EiRTLS

• OATSystems

• CenTrak

Updated data model:

• WaveMark EiRTLS

• CenTrak

Updated:

• Censitrac-InSites Data Flow (6.1.1)

• Data retention content

• Figure 1 to include WaveMark MySQL database

• Table 3 RTLS Data Model Constraints

HPE

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

National RTLS Enterprise Data Architecture iii September 11, 2017

April 1, 2016 10.6 Updated data dictionaries and data models:

o InSites ODS o InSites BI o Censitrac HL o InSites Third Party Censitrac

Updated InSites analytical data stores native DBMS to SQL Server and version to 4.6.

Updated data retention content.

Re-designed RTLS data flows to incorporate data integration workbook information.

Updated analytical data flow between Censitrac and Intelligent InSites to include two data elements.

HPE

January 4, 2016 10.5 • Updated data dictionaries and data models:

o InSites ODS o Censitrac HL

HPES

September 11,

10.4 • Updated data dictionaries.

• Updated data models.

• Updated Section 2.1.1 to correct source system version numbers.

• Updated Section 3.1.4.1.3 to add Facility identifier to schema naming convention.

HPES

August 23, 2015 10.3 • Updated data dictionaries.

• Updated data models.

• Incorporated VA comments from EDA 10.2.

HPES

July 24, 2015 10.2 • Updated data dictionaries.

• Updated data models.

• Added InSites-Maximo integration.

• Incorporated VA comments from EDA 10.1.

HPES

May 21, 2015 10.1 Section 2.4.3.5 – Replaced Data Dictionary for OATSystems.

HPES

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

National RTLS Enterprise Data Architecture iv September 11, 2017

March 31, 2015 10.0 Section 2.3.3 – Replaced data models for InSites, CenTrak, and OATSystems.

Section 2.4.3.1 – Updated Data Dictionaries for Intelligent InSites ODS VA Used and Intelligent InSites ODS VA Full.

Section 2.4.3.4 – Updated CenTrak Data Dictionary.

Section 2.4.3.5 – Updated OATSystems Data Dictionary.

Section 3.1.2.2 – Added reference to CDW Source Report.

Section 3.1.2.3 – Updated status of feasibility studies.

Section 3.1.4 Naming Conventions – Updated based on NDR team review and update.

HPES

October 17, 2014 9.3 Subsequent Submission to VA:

• For the NDR DW Data Dictionary (Sec. 3.4.2), modified Unique Column to False for composite primary keys.

• All other embedded Data Dictionaries remain unchanged from the October 8 EDA Delivery (V 9.2).

HPES

October 8, 2014 9.2 Subsequent Submission to VA HPES

September 19,

9.1 Subsequent Submission to VA HPES

August 19, 2014 9.0 Subsequent Submission to VA HPES

March 26, 2014 8.1 Subsequent Submission to VA HPES

March 19, 2014 8.0 Subsequent Submission to VA HPES

March 7, 2014 7.0 Subsequent Submission to VA HPES

December 13,

6.0 Subsequent Submission to VA HPES

October 4, 2013 5.0 Subsequent Submission to VA HPES

September 6,

4.0 Subsequent Submission to VA HPES

July 26, 2013 3.0 Subsequent Submission to VA HPES

July 12, 2013 2.0 Subsequent Submission to VA HPES

June 4, 2013 1.0 Initial Submission to VA HPES

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

National RTLS Enterprise Data Architecture v September 11, 2017

Table of Contents 1 Introduction

1.1 Purpose

1.2 Scope

1.3 Related Documentation

1.4 Points of Contact

2 Layer 1 – Data Context

2.1 RTLS Data Stores

2.2 Specified Evaluations

2.3 Data Design Decisions

2.4 Data Value Standards

2.5 Naming Conventions

2.6 Time Synchronization

2.7 Constraints

3 Layer 2 – Conceptual Data Model

4 Layer 3 – Data Model

4.1 System Configuration

4.2 Data Retention

4.2.1 Design Decisions

4.3 Data Models

4.3.1 Online Transaction Processing Data Models

4.3.2 Online Analytical Processing Data Models

4.4 Data Model Extension Instructions

4.4.1 Intelligent InSites

4.4.2 CenTrak/Censis/WaveMark

4.4.3 OATSystems

5 Layer 4 – Data Dictionaries

5.1 Data Dictionary Table Description

5.2 Data Dictionary Data Column Description

5.3 Transactional Data Dictionaries

5.3.1 Intelligent InSites Transactional Data Dictionary

5.3.2 Censitrac HL Data Dictionary

5.3.3 WaveMark EiRTLS Data Dictionary

5.3.4 CenTrak Data Dictionary

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

National RTLS Enterprise Data Architecture vi September 11, 2017

5.3.5 OATSystems Data Dictionary

5.4 Analytical Data Dictionaries

5.4.1 Intelligent InSites Business Intelligence Data Dictionary

5.4.2 Intelligent InSites Third Party WaveMark Data Dictionary

5.4.3 Intelligent InSites Third Party Censitrac Data Dictionary

6 Layer 5 – Data Flow

6.1 Transactional to Transactional

6.1.1 Censitrac to Intelligent InSites

6.1.2 CenTrak to Intelligent InSites

6.1.3 OATSystems to Intelligent InSites

6.2 Transactional to Analytical

6.2.1 WaveMark to Intelligent InSites

6.2.2 Censitrac to Intelligent InSites

7 Appendix A: Acronyms and Abbreviations

List of Tables Table 1 RTLS Enterprise Data Architecture Five-Layer Design Table 2 RTLS Data Flow Data Store Descriptions Table 3 RTLS Data Model Constraints Table 4 Conceptual Data Model Crosswalk Table 5 RTLS System Database Configuration Table 6 Data retention requirements Table 7 Data retention by data store Table 8 RTLS OLTP Data Models Table 9 RTLS Online Analytical Processing Data Models Table 10 Data Dictionary Table Description Table 11 Data Dictionary Data Column Description Table 12 Integration of WaveMark Data into Intelligent InSites ADS Table 13 Data Element Flow from WaveMark to Intelligent InSites ADS Table 14 Censitrac to Intelligent InSites ADS

Table of Figures Figure 1: RTLS Data Flow Figure 2: RTLS Conceptual Data Model

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 1 September 11, 2017

1 Introduction The Department of Veterans Affairs (VA) is implementing an integrated, enterprise-wide solution for a Real Time Location System (RTLS). RTLS will initially be used to track equipment, supplies, medical/surgical instruments, and provide the ability to monitor environmental conditions such as humidity and temperature. Future uses for the system may include locating staff, patients, paper documents, and the monitoring of carbon dioxide (CO2).

The Veterans Health Administration (VHA) has a requirement to implement RTLS in all of its Medical Centers and certain other facilities over the next several years. Each VHA Veterans Integrated Service Network (VISN) will have an implementation of RTLS, which will be capable of exchanging data with VA information systems (e.g., Veterans Health Information System and Technology Architecture [VistA]). Data from the RTLS systems could be made available within a single National Data Repository (NDR). The NDR could provide sophisticated business intelligence, predictive analytics, and reporting capabilities used for process improvement, business and financial analytics, workflow analysis, and research analysis.

1.1 Purpose

This document describes the enterprise data architecture to support the implementation of RTLS. It can be thought of as a “user’s guide” to the underlying data for the RTLS ecosystem. This document will define the data captured, stored, and used within all data stores that comprise RTLS.

1.2 Scope

The scope of this document covers the initial RTLS Enterprise Data Architecture (EDA) and the Maximo- RTLS integration. The RTLS systems described cover the four primary applications that were identified by the National RTLS Initiative. These applications include Asset Tracking (AT), Cardiac Catheterization Laboratory Supply Management (CL), Sterile Processing Workflow (SPW), and Temperature Monitoring

(TM).

As depicted in Table 1, the RTLS data architecture is comprised of multiple views, each of which are described in subsequent sections of this document. It is important to note that the RTLS Enterprise Data Architecture is implemented via an ecosystem of Commercial-Off-The-Shelf (COTS) products and is therefore contextually the logical composite of all the data schemas of each of these COTS systems.

The RTLS Enterprise Data Architecture includes a set of data standards for RTLS data systems as a vision or a model of the eventual interactions between the component parts of RTLS. The RTLS Enterprise Data architecture consists of policies, rules, and standards that govern which data is collected, how it is stored, arranged, integrated, and used in the RTLS ecosystem and across the VHA. This guidance ensures a higher quality and completeness of specific data. The opportunity for reuse and consolidation are greater when this process is followed. Data integration with the Automated Engineering Management System/Medical Equipment Reporting System (AEMS-MERS), for example, should be dependent upon data architecture standards to insure data interactions between RTLS and AEMS-MERS are consistent with other RTLS interactions.

The RTLS Enterprise Data Architecture addresses data at rest and at an introductory level, data in motion;

descriptions of data stores, data groups, and data items; and, it addresses mappings of those data artifacts

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 2 September 11, 2017 to data qualities, applications, locations, and how data is processed, stored, and used in a given system. It provides criteria for data processing operations that make it possible to design data flows in the system.

The RTLS Enterprise Data Architecture is designed to describe categories of data from conceptual to physical state. This approach uses a five-layer design, as shown in the following table.

Table 2 RTLS Enterprise Data Architecture Five-Layer Design

Layer View Data (What) 1 Context List of details and architectural standards important to the business

2 Conceptual Conceptual Data Model

3 Physical Physical Data Model

4 Data Specification Data Definitions (Data Dictionaries)

5 Data Flow Data Movement

This document addresses all the data stores that are part of the RTLS solution. The RTLS data stores are depicted in the RTLS Data Flow Diagram (see Figure 1). These databases aggregate data from all the VA Medical Centers (VAMC) and Community-Based Outpatient Clinics (CBOC) RTLS systems belonging to the VISNs or all the aggregated Consolidated Mail Outpatient Pharmacies (CMOP).

1.3 Related Documentation

• Real Time Location System (RTLS) System Design Document (SDD)

• AEMS-MERS/Intelligent InSites RTLS Interface Control Document (AEMS-MERS ICD)

• Generic Inventory Package (GIP)/WaveMark Real Time Location System Interface Control Document (GIP ICD)

• NEW PERSON File/WaveMark Real Time Location System Interface Control Document (Employee

ICD)

• VistA PATIENT File/WaveMark Real Time Location System Interface Control Document (Patient

ICD)

• RTLS National Requirement Specification Document (RSD)

• Cardiovascular Assessment, Reporting, and Tracking System for Catheterization Laboratories/WaveMark System Interface Control Document (CART-CL ICD)

• Intelligent InSites Online Help

• Intelligent InSites 2.0 Application Programming Interface (API) RESTful Web Services

• Censis Technologies, Inc. API Documentation

• CenTrak Streaming Services Guide

• OAT Foundation Suite Customer / partners public API

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 3 September 11, 2017

• WaveMark IntegratorConnect – Interface Specification

• Maximo-RTLS (Real Time Location System) Interface Control Document (Maximo ICD)

• Service-Oriented Handheld Tagging Solution Software Design Document (Handheld SDD)

1.4 Points of Contact

Points of contact for the RTLS Enterprise Data Architecture (EDA) will be DXC Technology and the VHA RTLS Program Management Office (PMO).

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 4 September 11, 2017

2 Layer 1 – Data Context The data for Phase 1 of the RTLS implementation will reside in Commercial Off-The-Shelf (COTS) products which were developed at private expense by the owners.

The Performance Work Statement Enterprise Systems Engineering Task Order (PWS ESE TO) includes requirements for a common data model. Since the PWS was issued, that term has evolved into “RTLS Data Model (RDM).” RDM will be used in this section instead of “common data model.”

2.1 RTLS Data Stores

The RTLS system is a system of systems. As a system of systems, data flows between multiple components both for transactional and for analytical purposes. The following diagram focuses solely on how data flows from one data store to another data store within the RTLS system. For a more in-depth description of RTLS data flows, see Section 6 of the System Design Document (SDD). Section 6 of the SDD contains information pertaining to how sensory data flows from various hardware components to the various software components within the RTLS system (e.g., how multi-mode active tag data flows throughout the RTLS system). The data stores in the following diagram that are blue in color are part of the RTLS Data Model.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 5 September 11, 2017

Figure 1: RTLS Data Flow

Note: A local facility will have either an AEMS-MERS/RTLS integration or a Maximo-RTLS integration, but not both.

A PDF version of the diagram above is embedded in this document here: RTLS Data Flow v004 07132016.pdf

Table 2 (following) provides a list of the data stores from the diagram above. The columns in the RTLS Data Flow Data Store Description table are defined as follows:

• Data Store Name (# in diagram) – this is the name of the data store; the number corresponds to the number in the diagram above.

• Brief Description – an explanation of the data store.

• Native DBMS – the data store’s underlying database management system type (i.e., Oracle).

• Company – the company that designed and provided the physical structure of the data store.

• Schema Type – this indicates whether the data store is an online transaction processing (OLTP) or online analytical processing (OLAP) database.

• Scope – this indicates the type of operations for which the data store is used. Valid values include:

o Facility – indicates that the data store contains facility level data.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 6 September 11, 2017 o VISN – indicates that the data store contains VISN level data. VISN level data stores contain facility level data for the facilities within that VISN.

o National – indicates that the data store retains National level data. National level data stores contain all facility level data in the RTLS enterprise.

o VISN/National – indicates that the data store contains VISN level data in a VISN deployment model and contains National level data in a National deployment model.

• Supported Applications (version) – indicates what application, including its version, is supported for the current data model and data dictionary contained within the EDA.

• Receives Data From – provides a list of components that send data to the data store. Components can either be a hardware component (i.e., Smart Cabinet), software component (i.e., CenTrak Onsite Platform) or a data store (i.e., Intelligent InSites Business Intelligence). Not all components are present in the diagram. Components with a number in parentheses indicate a data store that is present in the diagram.

• Sends Data To – provides a list of components that receive data from this data store. Components can either be a hardware component (i.e., Smart Cabinet), software component (i.e., CenTrak Onsite Platform) or a data store (i.e., Intelligent InSites Business Intelligence). Not all components are present in the diagram. Components with a number in parentheses indicate a data store that is present in the diagram.

• Detailed Info in Section – which section within the EDA provides more details about the data store.

• Notes – this is used to provide additional information about the data store.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 7 October 21, 2016

Table 3 RTLS Data Flow Data Store Descriptions

Data Store

Name (# in diagram)

Brief Description

Native

DBMS

Compa ny

Sche ma

Type

Scope Supported Applica-tions (version)

Receives Data From

Sends Data To

Detailed Info in

Section

Notes

Censis Censitrac (1)

The Censitrac data store handles the storage and retrieval of medical/ surgical instrument inventory and tracking data.

SQL

Server

Censis Technol ogies

OLTP Facility Censitrac 3.6.13

Censis Censitrac Workstations

Intelligent InSites ODS (3) Intelligent InSites Censitrac Analytical (5) Censis Host Server

4.3.1

5.3.2

CenTrak

GMS

(2)

CenTrak Global Monitoring System (GMS) data store handles the storage and retrieval of current and summary active tag data.

SQL

Server

CenTra k

OLTP VISN/

Nation al

CenTrak

5.14 SP4

CenTrak Onsite Platform

None 4.3.1

5.3.4

The data received by this data store is also sent to the Intelligent InSites ODS

(3) via the CenTrak Onsite Platform.

Intelligent InSites

ODS

(3)

Intelligent InSites ODS (Operational Data Store) is the online transaction environment (Operational Data Store) for

SQL

Server

Intellige nt InSites

OLTP VISN Intelligent InSites Platform 4.7

OATxpress (8) Censis Censitrac (1)

Intelligent InSites Business Intelligence (4)

5.3.1

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 8 October 21, 2016

Store

Name (# in diagram)

Brief Description

Native

DBMS

Compa ny

Sche ma

Type

Scope Supported Applica-tions (version)

Receives Data From

Sends Data To

Detailed Info in

Section

Notes unstructured data that supports the RTLS business functions and user interface.

AEMS-

MERS

(VistA) External

RTLS

Systems CenTrak Onsite Platform

AEMS-

MERS

(VistA)

Intelligent InSites Business Intelligence (4)

Intelligent InSites Business Intelligence is the reporting environment (Analytical Data Store) that contains a copy of the unstructured data from the Intelligent InSites ODS data store.

This data store transforms unstructured data to structured data that will be used for reporting and analytical purposes.

SQL

Server

Intellige nt InSites

OLAP VISN Intelligent InSites Platform 4.7

Intelligent InSites ODS (3)

None 4.3.2

5.4.1

This data is presented to user via the reporting and analytical features of the Intelligent InSites Business Intelligence Platform.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 9 October 21, 2016

Name (# in diagram)

Brief Description

Native

DBMS

Compa ny

Sche ma

Type

Scope Supported Applica-tions (version)

Receives Data From

Sends Data To

Detailed Info in

Section

Notes

Intelligent InSites Censitrac Analytical (5)

Intelligent InSites Censitrac Analytical (OLAP

– 3rd Party) are the data tables imported from Censis Censitrac data store that mirror reports generated from the Censitrac application. This data store is used to provide analytics on medical/ surgical instrument reprocessing.

SQL

Server

Intellige nt InSites

OLAP VISN Intelligent InSites Platform 4.7

Censis Censitrac (1)

5.4.3 user via the reporting and analytical features of the Intelligent InSites Business Intelligence Platform.

Intelligent InSites WaveMark Analytical (6)

Intelligent InSites WaveMark Analytical (OLAP

– 3rd Party)—are the data tables imported from WaveMark interface engine infrastructure HL7 messaging interface. This data store is used to provide

SQL

Server

Intellige nt Intellige nt InSites

OLAP VISN Intelligent InSites Platform 4.7

WaveMark EiRTLS (9)

5.4.2 user via the reporting and analytical features of the Intelligent InSites Business

Platform.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 10 October 21, 2016

Name (# in diagram)

Brief Description

Native

DBMS

Compa ny

Sche ma

Type

Scope Supported Applica-tions (version)

Receives Data From

Sends Data To

Detailed Info in

Section

Notes analytics on supply data within the Cardiac Catheterization Laboratory.

OAT

Enterprise Administrat or (7)

The OAT Enterprise Administrator data store is the master data repository for all the OATxpress data stores across the enterprise. This data store maintains and distributes passive tagging configuration items such as locations and product information. This data store is identical to the OATxpress (8) data store.

SQL

Server

OATSys tems

OLTP VISN/

Nation al

OAT

Enterprise Administrato r 8.2

OATxpress (8)

OATxpress (8)

5.3.5

This data store is the same database schema as the OATxpress

(8) database schema.

OATxpress (8)

OATxpress data store is used to capture, filter, and

SQL

Server

OATSys tem

OLTP Facility OATxpress 8.2

OAT

Enterprise

OAT

Enterprise

4.3.1

5.3.5

OATxpress is deployed in VISN and

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 11 October 21, 2016

Name (# in diagram)

Brief Description

Native

DBMS

Compa ny

Sche ma

Type

Scope Supported Applica-tions (version)

Receives Data From

Sends Data To

Detailed Info in

Section

Notes manage passive tagged asset’s sensor data within a single facility.

Administrator (7) Intelligent InSites ODS (3) Fixed and Handheld Passive tag readers

Administrato r (7) Intelligent InSites ODS (3)

National locations on a per facility basis

This data store is the same database schema as the OAT Enterprise Administrator

(7) database schema.

WaveMark EiRTLS (9)

The WaveMark EiRTLS data store collects, stores, and retrieves information from WaveMark’s RFID Smart Cabinets and Point of Use Stations. The data stored in this data store allows for the efficient

Oracle WaveM ark

OLTP VISN/

Nation al

WaveMark EiRTLS 7.9.6

Smart Cabinets Point of Care Employee (VistA)

IFCAP-GIP

(VistA) WaveMark Online

Intelligent InSites WaveMark Analytical (6)

CART-CL

IFCAP-GIP

(VistA)

5.3.3

Patient data from the Patient (VistA) interface is not directly stored in the EiRTLS data store. It is stored on the xPOS using a request and receive service using

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No. VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 12 October 21, 2016

Name (# in diagram)

Brief Description

Native

DBMS

Compa ny

Sche ma

Type

Scope Supported Applica-tions (version)

Receives Data From

Sends Data To

Detailed Info in

Section

Notes management of Catheterization Laboratory supplies.

the ID of a patient’s bracelet as a parameter.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 13 September 11, 2017

2.2 Specified Evaluations

The PWS ESE TO Section 5.2.2, Table 2 specifies that when developing the RDM, that Houston, TX and Columbus, OH be evaluated for their data characteristics concerning Operating Room Flow and Patient Tracking, respectively. Operating Room Flow and Patient Tracking are not part of the four base applications that are being addressed by the current RTLS task orders. When applications for operating room flow and patient tracking are added, HP will evaluate the appropriate data characteristics from these locations and update the EDA to include the requested analysis.

The PWS ESE TO Section 5.2.2 also specifies that during the development of the RDM:

“The Contractor shall analyze the following standards to form part or all of the foundation of the data model:

1. VA AViVA system standards

2. GS1

3. GLN.”

HP did evaluate AViVA. At the time the AViVA assessment was done, the program did not have a data model. AViVA was at that time still very immature and as such did not require a model. This was indicated in the assessment.

The VA has working groups that are reviewing GS1 (global standard for equipment identification) and GLN (Global Location Number). These groups are investigating the feasibility of implementing and deploying these standards within the VA network of systems as well as developing a data governance policy to version changes to these standards. At this time, these groups have indicated that the roll-out of these standards is a future endeavor.

2.3 Data Design Decisions

The RDM is designed to track assets, record and report real-time events quickly and efficiently, and support data mining and reporting. Each component of the RDM has its own data store that was developed prior to inclusion in the RDM. The following products make up the RDM:

• Censitrac – designed to track and report on medical/surgical instruments and their containers as well as sterilization. This system is designed to be used at the facility level where medical procedures are performed or sterilization activities take place.

• CenTrak – designed to track and report on active tags.

• Intelligent InSites Visibility Platform– designed to be the primary user interface at the VISN level for tracking and reporting assets. The other 4 systems provide data to Intelligent InSites.

• OATSystems – designed to track and report on passive tags.

• WaveMark EiRTLS – designed to track and report on expendable supplies. These systems have been modified, where needed, to support the exchange of data with other RDM components (see Figure 1, RTLS Data Flow Diagram) to meet the requirements of the PWS ESE TO. Where necessary, the data stores have been extended to handle VA-specific data.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 14 September 11, 2017

2.4 Data Value Standards

Data standards are documented agreements on representation, format, and definitions for common data.

Data standards are important to the RTLS enterprise architecture as a means to promote the efficient sharing of RTLS data among VA regions, VISNs, and local facilities and to improve data quality for better decision-making. Data standards allow data to be aggregated at the VISN, region, and national levels for analytics and work flow analysis.

Under the ESE TO, HP along with the RTLS partners, the VA Data Work Group, and other VA subject matter experts worked together to establish a set of data standards for the VA’s RTLS enterprise. These standards were prepared and delivered as an excel spreadsheet in the EDA v 8.1. The VA has developed a Data Standards Governance process to formalize the management of the data standards. The approved data standards are available upon request.

2.5 Naming Conventions

A single naming convention does not exist across all data stores as the RDM is a system of systems.

Within individual data dictionaries, table and field naming patterns have been identified where appropriate.

2.6 Time Synchronization

RTLS platform policy requires that all virtual machines in the RTLS solution be configured to synchronize with VA’s Network Time Protocol (NTP) server so that the local time kept by each host platform is consistent nationwide. The RTLS platform will use the time synchronization service from the NTP servers (ntp.va.gov) which is managed by the VA Network Security Operations Center (NSOC). All RTLS applications hosted on these virtual machines rely on this synchronized server local time to ensure that all RTLS-related events are recorded in the proper sequence at the correct time regardless of where they geographically reside.

2.7 Constraints

The RTLS Data Model is deployed on the following platforms:

• Microsoft SQL Server

• Oracle Database

Each platform has a variety of constraints for the applications that are built on top of them. The table below provides a list of constraints for the RTLS Data Model. The columns in the RTLS Data Model Constraints table are defined as follows:

• Constraints – the database platform restriction

• Impact – the impact on the design of the application from the constraint

• Data Store Name - this is the name of the data store

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 15 September 11, 2017

Table 4 RTLS Data Model Constraints

Constraint Impact Data Store Name Sequential number used for ID fields (not GUID).

Database cannot be split over physically separate databases.

Censis Censitrac Intelligent InSites ODS Intelligent InSites Business Intelligence Intelligent InSites Censitrac Analytical Intelligent InSites WaveMark Analytical WaveMark EiRTLS OAT Enterprise Administrator OATxpress

Character set limited to Latin based.

Non-Latin character sets (like Chinese or Arabic) are not supported.

Censis Censitrac Intelligent InSites ODS Intelligent InSites Business Intelligence Intelligent InSites Censitrac Analytical Intelligent InSites WaveMark Analytical OAT Enterprise Administrator OATxpress

Some fields do not allow special characters.

Name fields, as an example, can only contain letters or numbers.

OAT Enterprise Administrator OATxpress

Character fields do not allow for TAB’s.

Users may not enter TAB’s in data fields.

Censis Censitrac

Varchar fields contain arrays of foreign keys.

These fields do not impact database integrity and have no schema relevance.

Typically, record keys are stored in integer fields.

However, the data in these fields is strictly used to estimate location accuracy, not to enforce table relationships. Refer to the CenTrak data dictionary and the field descriptions for StarSeen and StarCount.

CenTrak GMS

Primary and/or foreign key relationships are not enforced on all tables in the database.

Relationships are enforced in the business logic layer (software) to allow for analytical and transactional processing of data within the

Censis Censitrac CenTrak GMS Intelligent InSites Business

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 16 September 11, 2017

Constraint Impact Data Store Name context of maintaining a single instance of the data.

Datetime fields capture data in integer format.

These integer values are used in the business logic layer (software) and do not affect data integrity.

CenTrak GMS

All character and string columns are nvarchar (SQL Server) or nvarchar2 (Oracle).

The application data store utilizes Unicode character encoding to support internationalization and localization.

OAT Enterprise Administrator OATxpress

The application _property tables (dms_property, physical_property, etc.) store non-string values as string.

These values are maintained by application logic and are displayed as binary if selected from the database by a general purpose tool.

OAT Enterprise Administrator OATxpress

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 17 September 11, 2017

3 Layer 2 – Conceptual Data Model A conceptual data model is a data model viewed at the highest level of abstraction. This aspect of the model represents the strategic information requirements of the enterprise within the scope of the RTLS initiative. The conceptual data model is coarse grained and is intended to show the broad set of entities and relationships under consideration. The conceptual data model provides a high-level view of the information universe under the RTLS umbrella. The conceptual data model shown in the following figure covers the RTLS Data Model across the enterprise. The terminology used in this model is general in nature and not necessarily intended to reflect official VA definitions.

Figure 2: RTLS Conceptual Data Model

The following subject areas are included in the Figure 2 above:

• Business Rules – describe the operations, definitions, policies, and constraints that apply to an item.

Within the RTLS system, business rules can be applied to groups of items or individual items based on recorded values and locations. A series of resulting actions may be executed based on the results of the completed business rules. The status of an item may be altered by the execution of one or more business rules.

• Items – are any entities that are tracked within the RTLS system. The RTLS system will track the following types of items:

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 18 September 11, 2017 o Objects – physical tangible things. An object within the RTLS system is extended to:

Equipment –are physical assets (other than land or buildings) that are used in the VA’s mission. The movement (physical locations), utilizations, and reprocessing of equipment within a facility will be recorded.

Expendable Equipment is equipment defined by VA Directive 7002 (2011) that is considered disposable. An example of expendable equipment is Medical/Surgical instruments.

Non-Expendable Equipment is equipment defined by VA Directive 7002 (2011) which retains its original identity and characteristics during its useful life. Non-expendable equipment requires accountability/control regardless of cost, life expectancy, or maintenance requirements. Non-expendable equipment will have a Category Stock Number (CSN) assigned; non-expendable equipment with assigned CSNs will be found in VA Catalog Number 3, section V. Examples of non-expendable equipment are IV Pumps, beds, endoscopes and case carts.

Supplies – are consumable items that are single use items utilized in the course of patient care. The following will be recorded in relation to supplies:

The consumption and quantities of supplies in the Cardiac Catheterization Laboratory; their utilizations

The rooms where supplies reside (locations)

The staff members who were present during the procedure

The patient who received the supplies o Persons – human beings. The RTLS system extends person entities into Staff and Patients.

Staff – staff members may be located (in future functionality), via an RTLS badge. The movement (physical locations) of staff members such as doctors and nurses may be recorded.

Patients – patients will be tracked through their visit (in future functionality). Movement of patients throughout the facility (i.e., physical locations) will be recorded by using an RTLS bracelet.

• Locations – particular places or positions. Within the RTLS system, locations of items are determined and updated using a combination of information from the sensors and the tags that are affixed to the items. Business rules executed based on the location of an item may alter the status of an item.

• Recorded Values –the recorded data of items (equipment, patients, staff, or supplies). Items can have many recorded values of various types:

o Reprocessing – details about the procedure of cleaning, disinfecting, and/or sterilizing of reusable medical equipment and medical/surgical instruments. This is comprised of a series of steps that when performed based on the device manufacturer’s recommendations readies the items for reuse.

Sterilizations – data retrieved from the process of sterilization. All the records related to the sterilization processes are retained. These include the recorded values as it pertains to the sterilization that the medical/surgical instrument or equipment went through (e.g., 200 cycles of steam sterilization at temperature of 135° Celsius).

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 19 September 11, 2017

High-Level Disinfections – data related to the processing of semi-critical items that come in contact with mucous membranes or non-intact skin. High-Level Disinfection traditionally is defined as complete elimination of all microorganisms in or on medical/surgical instrument, except for small numbers of bacterial spores with the goal of making objects safe for reuse.

“High-Level Disinfections are performed on items such as equipment that cannot withstand the rigors of sterilization.

o Utilizations – includes details about process change of items. This includes the consumption of supplies and the number of times medical/surgical instruments and equipment have been used.

o Environmental Measurements – are the recording of metrics and other data collected at remote or inaccessible points and transmitted to receiving apparatus for monitoring. The RTLS system records the following environment measurements of items:

Temperature Measurements – the measurement of heat

Humidity Measurements – the measurement of moisture in the air o Tag Events – use of information from the tag to record events other than locations and environmental measurements. A tag event includes actions such as a tag being removed from an item causing the tamper switch to be activated.

• Resulting Actions – this generalization set includes information about activities caused from the execution of business rules on items or the recorded values of items. Multiple resulting actions can be triggered based on one or more business rules. For example, if a recorded value such as a temperature monitored item goes past a preset threshold, a communication such as an alert could be sent to a technician to address the situation. Another example is a recorded value where a temperature is recorded that is within the prescribed parameters, and therefore no resulting event is triggered.

o Communications – details about the interchange of information. Information can be exchanged via alerts (need immediate human or systematic attention), notifications (inform individuals or systems), and messages (a simple exchange of information). Information exchanges happen via person-to-system, system-to-person, and system-to-system (e.g., the results of a sterilizer load will be sent from one system [Censis Censitrac] to another system [Intelligent InSites Foundation]). The following are examples of communications:

Within the equipment tracking domain, an alert could trigger a security alarm when a piece of equipment has been moved outside a secured area. Within the supply domain, an example of an alert would be when a supply is nearing its expiration date. Within the sterilization process of medical/surgical instruments, a staff member could receive an alert that medical/surgical instruments failed to be sterilized due to an error in the sterilizer.

A nurse could receive a notification via email or SMS text message when a patient has reached a certain location and is ready to be checked in.

If a piece of equipment has been broken and needs maintenance, a user can send a message to the maintenance staff about repairing the out of service equipment.

o Tasks (in future functionality) – are used as an interchange when a human or system is requesting assistance or an activity needs to be performed. For example, inventory levels are reaching restock levels, so a task is sent to a staff member to restock the inventory.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 20 September 11, 2017

• Sensors – devices that collect values to be recorded in the RTLS system. The values collected include item locations, environment levels such as temperature and humidity, and data from tags used to identify supplies. A tag within the RTLS system will be classified as one of the following:

o Active Sensors – devices used to sense when an active tag is within its range. Active tags possess internal power that enables them to originate signals to communicate with active sensors.

Examples of active sensors include:

Active Communication Devices which include Wi-Fi access points and 900 MHz stars

Active Supplemental Devices which include monitors/exciters o Passive Sensors – devices used to retrieve information from a passive tag. A passive sensor captures information from the passive tag by sending a signal to the tag which energizes it. Once the passive tag is energized, it reflects back to the passive sensor some of the sensor’s energy that is encoded with tag data for the sensor to collect. Examples of passive sensors include handheld RFID readers, equipment cabinet readers, and passive portal devices.

o Barcode Sensors – devices used to retrieve information from barcodes. Barcode sensors consist of a light source, a lens, and a light sensor translating optical impulses into electrical ones. Barcode image data is captured by the sensor and sends the barcode’s content to the sensor’s output port.

• Tags – this generalization includes information about how items will be tracked and/or monitored through the RTLS system. A tag within the RTLS system will be one of the following:

o Active Tags – a RTLS tag that initiates transmissions to a sensor and has an internal energy source such as a battery.

o Passive Tags – a RTLS tag that receives energy from an external source (i.e., portal or handheld reader) and reflects data back to the source. Passive tags do not contain batteries. The portal or handheld reader causes the passive tag to relay information back to it.

o Barcodes Tags – optical machine-readable representations of data relating to the object(s) to which they are attached. The barcodes are printed on or affixed to the object using an adhesive.

Barcodes include the following types:

1D Barcodes –a pattern of parallel lines of varying widths.

2D Barcodes – expanding upon a 1D barcode, the 2D barcode stores information in both width and height. The 2D barcode consists of an arrangement of small dots or squares, marked as either a square or rectangle.

Markings – two dimensional Electrochemical/Electro-erosion markings applied into the surface of items such as medical/surgical instruments. The table below provides a cross walk between the conceptual data model subject areas and which transactional data stores use each entity within the RTLS Systems, and which, if any specializations of the core subject areas are used within a given data store.

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Government Contract No.

VA118A-12-D-0025.

RTLS National Enterprise Data Architecture 21 September 11, 2017

Table 5 Conceptual Data Model Crosswalk

Transactional Data Stores

Censis Censitrac

CenTrak GMS Intelligent InSites

ODS

OATxpress/ OAT Enterprise Administrator

WaveMark EiRTLS

Co re

S ub je ct

A re as

Business Rules Business Rules N/A Business Rules N/A Business Rules

Items Equipment N/A Equipment N/A Supplies

Locations Locations Locations Locations Locations Locations

Recorded Values Sterilizations Humidity Measurements

Humidity Measurements N/A Patients

High Level Disinfections Tag Events Tag Events Staff

Utilizations Temperature Measurements

Temperature Measurements Utilizations

Resulting Actions Communications Communications Communications Communications Communications

Tasks

Sensors Barcode Sensors Active Sensors Active Sensors Passive Sensors Barcode Sensors

Passive Sensors Passive Sensors

Tags Barcode Tags Active Tags Active Tags Passive Tags Barcode Tags

Barcode Tags Passive Tags

Passive Tags

Notice--Notwithstanding any other lease or license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in

RTLS National Enterprise Data Architecture 22 September 11, 2017

4 Layer 3 – Data Model The Common Data Model defined in the VA RTLS ESE PWS will be referred to as the RTLS Data Model and it includes all data stores purchased as part of the RTLS System. Normally when a database is being developed for a solution, both a logical and a physical model provide value. Discussions with VA determined that only physical models are necessary since these data stores are mature products. The following data stores are part of the RTLS Data Model:

• Intelligent InSites Foundation

• CenTrak GMS

• WaveMark EiRTLS

• Censis Censitrac HL

• OATSystems OATxpress1

• OATSystems Enterprise Administrator2

• Intelligent InSites Business Intelligence

• Intelligent InSites Censitrac Analytical3

• Intelligent InSites WaveMark Analytical4

For each data store, a data model will be provided. A data model is a representation of entities and their attributes and how those entities are related to other entities in the physical landscape of a database. The union of all data store models addresses the RTLS Phase One Applications:

• Asset Tracking

• Cardiac Catheterization Laboratory supply tracking

• Sterile Processing Service (SPS) workflow and medical/surgical instrument tracking

• Temperature Monitoring

4.1 System Configuration

The RTLS System will utilize several vendors’ databases. For online-transaction-processing (OLTP) databases, Intelligent InSites, Censis, CenTrak and OAT will leverage the MS SQL Server database, and WaveMark will leverage the Oracle Database. Intelligent InSites will use MS SQL Server for their online-analytical-processing (OLAP) database.

1 OATSystems OATxpress and Enterprise Administrator are exactly the same database schema, just configured and used for different business purposes.

2 OATSystems OATxpress and Enterprise…