privacy impact assessment for the va it system called: bar ... · bar code expansion – positive...

19
Privacy Impact Assessment for the VA IT System called: Bar Code Expansion Positive Patient Identification (BCE-PPI) Phase 2 Date PIA completed: August 8, 2016 VA System Contacts: Name E-mail Phone Number Privacy Officer Andrea Wilson [email protected] 321-507-5512 Information Security Officer Diane Dixon [email protected] 817-385-3756 System Owner/Project Manager James Plastow [email protected] 801-924-2175 Person Completing the Document James Plastow [email protected] 801-924-2175

Upload: dotram

Post on 19-Nov-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

Privacy Impact Assessment for the VA IT System called:

Bar Code Expansion – Positive Patient

Identification (BCE-PPI) Phase 2 Date PIA completed:

August 8, 2016

VA System Contacts:

Name E-mail Phone Number

Privacy Officer Andrea Wilson [email protected] 321-507-5512

Information Security

Officer

Diane Dixon [email protected] 817-385-3756

System Owner/Project

Manager

James Plastow [email protected] 801-924-2175

Person Completing the

Document

James Plastow [email protected] 801-924-2175

Abstract

Bar Code Expansion - Positive Patient identification (BCE-PPI) enables clinicians to positively identify

patients using bar code scanning technology at the point of care. BCE will reduce specimen labeling and

reduce the probability of administering incompatible blood products or medication to patients. Wireless

bar code scanning accurately matches patients to specimen, blood products or medication.

Overview

The overview is the most important section of the PIA. A thorough and clear overview gives the reader the

appropriate context to understand the responses in the PIA. The overview should contain the following

elements:

The IT system name and the name of the program office that owns the IT system.

The business purpose of the program, IT system, or technology and how it relates to the program

office and agency mission.

The expected number of individuals whose information is stored in the system and a brief description

of the typical client or affected individual.

If your system is a regional GSS, VistA, or LAN, include a list of the hospitals/medical centers, or

other regional offices that fall under your system. Additionally, what region is the system under?

A general description of the information in the IT system.

Any information sharing conducted by the IT system. A general description of the modules and

subsystems, where relevant, and their functions.

A citation of the legal authority to operate the IT system.

Bar Code Expansion – Positive Patient Identification (BCE-PPI) enables clinicians to positively identify

patients using bar code scanning technology at the point of care. Bar Code Expansion (BCE) reduces the

probability of administering incompatible blood products by accurately matching patients to blood

products. In the future, BCE will reduce specimen labeling or medication distribution errors to patients.

Wireless bar code scanning lessens human error by accurately matching patients to specimens, blood

products or medications. All components of BCE are directly tied with patient safety.

The software that runs on the handhelds and workstations in the hospitals is called CareFusion Pyxis®

Transfusion Verification (CFTV). BCE data will be used for, but not limited to, patient record updates,

transfusion reports, vital sign reports and management reports. This system will typically be used for

patients receiving transfusions or present at medical centers; the number of patients’ information

contained will vary based on how many patients were seen across all medical centers in a given quarter.

The number of transfusions annually is over 200,000.

The Bar Code Resource Office is considered the Information Owner for the system. Greater detail on

information sharing can be found further into this document.

The BCE server has the task of translating barcode data into messages and Remote Procedure Calls

(RPC) calls used to transfer clinical information (blood product orders, transfusion administration

complete messages and admission/discharge/transfer data) to and from the VA systems involved in the

Pyxis® CFTV system, namely Veterans Health Information Systems and Technology Architecture

(VistA), Admission Discharge and Tracking (ADT) and VistA Blood Establishment Computer Software

(VBECS).

The legal authority to operate VBECS comes from Title 38, United States, Code, Sections 501(a) and 501(b).

Title 21, Code of Federal Regulations, parts 200-299 and Parts 600-680. Title 42, Code of Federal

Regulations, 493.1107.

This project will help VHA meet the following Joint Commission’s National Patient Safety Goals:

2010 (NPSG) 01.01.01: Use at least two patient identifiers when providing care, treatment and

services

2010 (NPSG) 01.03.01: Eliminate transfusion errors related to patient misidentification.

Section 1. Characterization of the Information

The following questions are intended to define the scope of the information requested and collected as well as

the reasons for its collection as part of the program, IT system, or technology being developed.

1.1 What information is collected, used, disseminated, created, or maintained in the system?

Identify and list all Sensitive Personal Information (SPI) that is collected and stored in the system, including

Individually Identifiable Information (III), Individually Identifiable Health Information (IIHI), Protected

Health Information (PHI), and Privacy- Protected Information. For additional information on these

information types and definitions, please see the VA Handbook 6500

(http://www.va.gov/vapubs/viewPublication.asp?Pub_ID=638&FType=2), published Sept. 2012, Appendix A.

)

If the system creates information (for example, a score, analysis, or report), list the information the system is

responsible for creating.

If a requesting system receives information from another system, such as a response to a background check,

describe what information is returned to the requesting system.

Please check any information listed below that your system collects, uses, disseminates, creates, or maintains.

If additional SPI is collected, used, disseminated, created, or maintained, please list those in the text box

below:

Name

Social Security

Number

Date of Birth

Mother’s Maiden Name

Mailing Address

Zip Code

Phone Number(s)

Fax Number

Email Address

Emergency Contact

Information (Name, Phone

Number, etc of a different

individual)

Financial Account

Information

Health Insurance

Beneficiary Numbers

Account numbers

Certificate/License

numbers

Vehicle License Plate

Number

Internet Protocol (IP)

Address Numbers

Current Medications

Previous Medical

Records

Race/Ethnicity

Veteran Vital signs, with VistA

Pre & post-transfusion order with VBECS

Patient location

Patient allergy

Patient Antibody Screen

Transfusion Record Report

Patient Order

1.2 What are the sources of the information in the system?

List the individual, entity, or entities providing the specific information identified above. For example, is the

information collected directly from the individual as part of an application for a benefit, or is it collected

from other sources such as commercial data aggregators?

Describe why information from sources other than the individual is required. For example, if a program’s

system is using data from a commercial aggregator of information or data taken from public Web sites, state

the fact that this is where the information is coming from and then in question 1.3 indicate why the system is

using this source of data.

If the system creates information (for example, a score, analysis, or report), list the system as a source of

information.

VistA is the source of the following patient information: name, social security number (SSN), date of birth,

previous medical records (including allergies), race/ethnicity, Patient Antibody Screen, ADT data, eligibility

data and clinical data for every patient. The VistA Patient Order package allows clinicians to order

medications, treatments, therapies and consults. The Transfusion Record Report is collected from VistA

Computer Patient Record System (CPRS) (the graphical user interface (GUI) for VistA); VistA CPRS pulls

information to construct a Text Integration Utilities (TIU) note that will serve as the patient’s permanent

record. VistA TIU allows the CFTV application to upload the Transfusion Record Form to the patient record

as a TIU document.

VBECS has all the Blood Bank Patient data for all transfusions. The patient is the source for vital signs.

VistA shall send the most recent patient’s vital signs via CPRS using the Vitals/Measurements GUI

Application option to the Blood Administration Point of Care (BAPOC). Patient location is known by the

nurse who is physically interacting with the patient during care.

1.3 How is the information collected?

This question is directed at the means of collection from the sources listed in question 1.2. Information may

be collected directly from an individual, received via electronic transmission from another system, or created

by the system itself. Specifically, is information collected through technologies or other technology used in the

storage or transmission of information in identifiable form?

If the information is collected on a form and is subject to the Paperwork Reduction Act, give the form’s OMB

control number and the agency form number.

Communications between VistA, VBECS and BCE are all electronic data transfers based on user activities in

the interface. All interactions with the patient are through physical contact. Nurses collect PII/PHI from the

patient in person. Nurses then enter the data in BCE via console software and handheld devices (Enterprise

Digital Assistant (EDA)).

1.4 What is the purpose of the information being collected, used, disseminated, created, or maintained?

Include a statement of why the particular SPI is collected, maintained, used, or disseminated in the system is

necessary to the program’s or agency’s mission. Merely stating the general purpose of the system without

explaining why this particular type of information should be collected and stored is not an adequate response

to this question.

If the system collects, uses, disseminates, or maintains publically available or commercial data, include a

discussion of why commercial data is relevant and necessary to the system’s purpose.

All the information collected is necessary in order to support the care of the veteran. To explain in detail,

Name allows the clinician to greet the patient by name and is a subset of the initial patient’s identity

confirmation. Social Security Number (SSN) is used as the patient identifier; it allows for patient records to

be accessed in Vista, VBECS and BCE. Date of birth is an optional field that is used as an initial

confirmation of patient’s identity; this supports the differentiation of individuals with the same name.

Previous medical records allow for a review of patient’s history. The medical records contain patient

information from VistA. Race/ethnicity is used as a subset for the initial patient confirmation. It is also

application transactions and patient information that allows for a visual verification of the patient identity.

Patient location is used as a subset for the initial patient confirmation and for entering patient data such as

vital signs or transfusion information to VistA and VBECS. The location is updated by VistA upon changes in

location. Patient allergy is pulled from VistA by clinicians to verify that there will be no issues before

rendering care. Patient Antibody Screen, also pulled from VistA by clinicians, gives verify that there will be

no issues before rendering care. Transfusion Record Report is pulled before any transfusion and updated

after any transfusion. Patient Order is used to order blood products. Pre- and Post-transfusion orders with

VBECS help track the processing and administration of the blood products to the patients. Veteran Vital

Signs is an optional data field which is gathered from the patient and sent to VistA to include in the patient

record.

1.5 How will the information be checked for accuracy?

Discuss whether and how information stored in the system is checked for accuracy. Is information in the

system checked against any other source of information (within or outside your organization) before the

information is used to make decisions about an individual? For example, is there a computer matching

agreement in place with another government agency?

If the system checks for accuracy by accessing a commercial aggregator of information, describe this process

and the levels of accuracy required by the contract.

The CFTV EDA devices and CFTV client applications perform the task of reading bar code data from patient

wristbands and blood product packaging. The bar code information is passed to the CFTV application server,

where it is compared against information received from VBECS and VistA. If the information matches, the

transfusion is allowed to proceed and completion information is passed from the CFTV application server to

VBECS and VistA. If the information does not match, the clinician is warned, investigates the problem and

corrects it.

1.6 What specific legal authorities, arrangements, and agreements defined the collection of

information?

List the full legal authority for operating the system, specifically the authority to collect the information listed

in question 1.1. Provide the authorities in a manner understandable to any potential reader, i.e., do not

simply provide a legal citation; use statute names or regulations in addition to citations. Legal authorities

include Federal laws, regulations, statutes, and Executive Orders.

Title 38, USC Section 7301(a) – Functions of Veterans Health Administration

System of Records 24VA10P2 – Patient Medical Records-VA

BCE system does have a Service Level Agreement (SLA) or a document/understanding of service level

needs/expectations as part of the system documentation at present. The level of support to be provided by the

hosting organization, Data Center Operations (DCO), appears in a copy the Service Level Agreement

Modification (SLAM), which is the contract between Product Development (PD)/ Service Delivery &

Engineering (SDE) and DCO for hosting the system. The SLAM provides the number of servers required to

support the system at the required service level. The required service level is described later in this document,

in the section on capacity planning.

Vendor Help Desk support SLA is established by the procurement vehicle agreed upon by the VHA Business

Owner and the CareFusion vendor. This contract vehicle does not contain performance and reliability metrics

concerning the operation of the vendor system/application. Performance and reliability metrics shall be

established by the Platform/hosting solution of this product during site testing and deployment as has just

been noted.

1.7 PRIVACY IMPACT ASSESSMENT: Characterization of the information

Consider the specific data elements collected and discuss the potential privacy risks and what steps, if any are

currently being taken to mitigate those identified risks.

Consider the following Fair Information Practice Principles (FIPPs) when assessing the risk to individual

privacy:

Principle of Purpose Specification: Explain how the collection ties with the purpose of the underlying mission

of the organization and its enabling authority.

Principle of Minimization: Is the information directly relevant and necessary to accomplish the specific

purposes of the program?

Principle of Individual Participation: Does the program, to the extent possible and practical, collect

information directly from the individual?

Principle of Data Quality and Integrity: Are there policies and procedures for DHS to ensure that personally

identifiable information is accurate, complete, and current?

Follow the format below when entering your risk assessment:

Privacy Risk: All information utilized is necessary for the intended usage of the software which is positively

identifying patients using bar code scanning technology at the point of care. The purpose of the software is to

eliminate transfusion errors related to patient misidentification. The bar code scanned on the patient is the

patient identifier which at this time is the patient’s SSN. BCE provides a link between the bar code readers,

VistA and VBECS.

Mitigation: Physical security in the medical centers limits who can access the patients. Patients should be

able to see the picture identification of anyone who walks up to them to look at their wristband. All medical

center staff must pass a background check to ensure the health and integrity of all patients and their

information. All medical center staff also receive yearly training in the handling of patients’ sensitive data.

Section 2. Uses of the Information

The following questions are intended to clearly delineate the use of information and the accuracy of the data

being used.

2.1 Describe how the information in the system will be used in support of the program’s business

purpose.

Identify and list each use (both internal and external to VA) of the information collected or maintained.

Name – Allows the clinician to greet the patient by name and is a subset of the initial patient’s

identity confirmation.

Social Security Number (SSN) – Used as patient identifier. Allows for patient records to be accessed

in Vista, VBECS and BCE.

Date of birth (optional) – Used as an initial confirmation of patient’s identity; supports the

differentiation of individuals with the same name.

Previous medical records – Review of patient’s history. Contains patient information from VistA.

Race/ethnicity – Used as a subset for the initial patient confirmation. Application transactions and

patient information that allows for a visual verification of the patient identity.

Patient location – Used as a subset for the initial patient confirmation and for entering patient data

such as vital signs or transfusion information to VistA and VBECS. Updated by VistA upon changes

in location.

Patient allergy – pulled from VistA by clinicians to verify that there will be no issues before

rendering care.

Patient Antibody Screen – pulled from VistA by clinicians to verify that there will be no issues

before rendering care.

Transfusion Record Report – pulled before any transfusion and updated after any transfusion.

Patient Order – used to order blood products.

Pre- and Post-transfusion orders with VBECS – tracks the processing and administration of the

blood products to the patients.

Veteran Vital Signs (optional) – gathered from the patient and sent to VistA to include in the patient

record.

2.2 What types of tools are used to analyze data and what type of data may be produced?

Many systems sift through large amounts of information in response to a user inquiry or programmed

functions. Systems may help identify areas that were previously not obvious and need additional research by

agents, analysts, or other employees. Some systems perform complex analytical tasks resulting in, among

other types of data, matching, relational analysis, scoring, reporting, or pattern analysis. Describe any type

of analysis the system conducts and the data that is created from the analysis.

If the system creates or makes available new or previously unutilized information about an individual, explain

what will be done with the newly derived information. Will it be placed in the individual's existing record?

Will a new record be created? Will any action be taken against or for the individual identified because of the

newly derived data? If a new record is created, will the newly created information be accessible to

Government employees who make determinations about the individual? If so, explain fully under which

circumstances and by whom that information will be used.

CareFusion also provides an Enterprise Digital Assistant (EDA) controller, which is a hand-held

device, for transfusionists and nurses to use to control blood product administration. EDA

provides the same functionality as the Windows Client Application, but in a more mobile fashion.

CareFusion Management Console (CFMC) - The management console is a web application

supplied as a part of CareFusion Pyxis TV which allows designated CFTV system administrators

to configure the Pyxis CFTV server applications and their interfaces.

Transfusion Record Report - VistA CPRS pulls information to construct a Text Integration

Utilities (TIU) note that will serve as the patient’s permanent record. Transfusion information is

recorded by the clinician. The TIU system allows CFTV to upload the Transfusion Record Form

to the patient record as a TIU document. This information will be available whenever someone

accesses the patient’s record such as for the next transfusion.

2.3 PRIVACY IMPACT ASSESSMENT: Use of the information

Describe any types of controls that may be in place to ensure that information is handled in accordance with

the uses described above. Example: Describe if training for users of the project covers how to appropriately

use information. Describe the disciplinary programs or system controls (i.e. denial of access) that are in

place if an individual is inappropriately using the information.

Consider the following FIPPs below to assist in providing a response:

Principle of Transparency: Is the PIA and SORN, if applicable, clear about the uses of the information?

Principle of Use Limitation: Is the use of information contained in the system relevant to the mission of the

project?

The integrity controls which restrict the loss, misuse, modification of, or unauthorized access to

information that could affect the company, client, or its customers are imposed by the VA. The VA

controls provide access to the CFTV software by using the VistA credentials of the user. An end user

who cannot authenticate to a VistA using an access code and a verify code cannot access the CFTV

server(s) mapped to that VistA.

Direct Access to the CFTV servers (by those with administrative and support roles) is controlled by the

VA in the same way that access to all servers is controlled, namely by using Lightweight Directory

Access Protocol (LDAP). In fact, CFTV servers are locked down enough to prevent vendor access.

Management operations on CFTV servers are performed by VA system administrators. If direction from

CFTV support personnel is required, it will be provided by giving instructions to VA personnel using

audio and video conferencing.

Role-based security

Role-based security will be provided for the BAPOC system, meaning that user access to information will be contingent upon their VA-defined role based permissions.

The BCE Database does not store PII data (or any other kind of patient data) permanently. While the

data remains in the BCE site-specific database it is secured by controlling access to that database. End

user access is controlled by using the authentication and authorization protocols described previously.

This applies especially to CFMC access—only users with the administrator role can possibly access

data using CFMC. Access to the CFTV site-specific database itself is only available to DCO Database

Administrators (DBA’s).

Access to the transient PII data in the CFTV site-specific database is strictly controlled using Role

Based Access Control (RBAC)

Training

All new and existing VA employees are required to complete VA Privacy and Information Security

Awareness and Rules of Behavior (TMS Course VA 10176), and Privacy and HIPAA Training (TMS

Course VA 10203) annually.

Section 3. Retention of Information

The following questions are intended to outline how long information will be retained after the initial

collection.

3.1 What information is retained?

Identify and list all information collected from question 1.1 that is retained by the system.

All patient data exchanged with VistA and VBECS is retained in the BCE CareFusion database. That

information includes: Name, SSN, Date of Birth, Previous Medical records, Race, vital signs, transfusion

orders, patient location, patient allergy, patient antibody screen, transfusion record reports and patient order.

3.2 How long is information retained?

In some cases VA may choose to retain files in active status and archive them after a certain period of time.

State active file retention periods, as well as archived records, in number of years, for the information and

record types. For example, financial data held within your system may have a different retention period than

medical records or education records held within your system, please be sure to list each of these retention

periods.

The VA records officer should be consulted early in the development process to ensure that appropriate

retention and destruction schedules are implemented.

All patient data by default is kept for 90 days after a patient’s last updated date or discharged date at which

time it is automatically purged from the system.

3.3 Has the retention schedule been approved by the VA records office and the National Archives and

Records Administration (NARA)? If so please indicate the name of the records retention schedule.

An approved records schedule must be obtained for any IT system that allows the retrieval of a record via a

personal identifier. The VA records officer will assist in providing a proposed schedule. The schedule must be

formally offered to NARA for official approval. Once NARA approves the proposed schedule, the VA records

officer will notify the system owner.

Not applicable; BCE is not a repository of patient health identification information.

3.4 What are the procedures for the elimination of SPI?

Explain how records are destroyed or eliminated at the end of the retention period. Please give the details of

the process. For example, are paper records shredded on site, or by a shredding company and accompanied

by a certificate of destruction, etc?

Not applicable.

3.5 PRIVACY IMPACT ASSESSMENT: Retention of information

Discuss the risks associated with the length of time data is retained and what steps, if any, are currently

being taken to mitigate those identified risks.

While we understand that establishing retention periods for records is a formal process, there are policy

considerations behind how long a project keeps information. The longer a project retains information, the

longer it needs to secure the information and assure its accuracy and integrity. The proposed schedule should

match the requirements of the Privacy Act to keep the minimum amount of PII for the minimum amount of

time, while meeting the Federal Records Act. The schedule should align with the stated purpose and mission

of the system.

Consider the following FIPPs below to assist in providing a response:

Principle of Minimization: Does the project retain only the information necessary for its purpose? Is the PII

retained only for as long as necessary and relevant to fulfill the specified purposes?

Principle of Data Quality and Integrity: Has the PIA described policies and procedures for how PII that is no

longer relevant and necessary is purged?

Follow the format below:

Privacy Risk: Information entered into BCE is immediately sent on to VistA and VBECS. Patient data is

kept in BCE for 90 days after the patient’s last updated date or discharged data as a precaution. If patient data

is purged too soon, there is a risk of deleting data for a current patient.

Mitigation: Ninety days from the last updated patient date allows for plenty of time for an error to be noticed

in VistA or VBECS that would necessitate calling up the data in BCE for verification. After 90 days, the data

is purged automatically. As the data purge process is automated, it removes the risk of user error in forgetting

to purge it at the appropriate time.

Section 4. Internal Sharing and Disclosure

The following questions are intended to define the scope of information sharing within VA.

4.1 With which internal organizations is information shared? What information is shared, and for what

purpose? How is the information transmitted or disclosed?

Identify and list the names of any program offices, contractor-supported IT systems, and any other

organization or IT system within VA with which information is shared.

State the purpose for the internal sharing. If you have specific authority to share the information, provide a

citation to the authority.

For each interface with a system outside your program office, state what specific information is shared with

the specific program office, contractor-supported IT system, and any other organization or IT system within

VA.

Describe how the information is transmitted. For example, is the information transmitted electronically, by

paper, or by some other means? Is the information shared in bulk, on a case-by-case basis, or does the

sharing partner have direct access to the information?

Program Office or IT

System information is

shared with

Reason why information

is shared with the

specified program or IT

system

List the specific

information types that

are shared with the

Program or IT system

Method of transmittal

VistA Blood

Establishment Computer

System (VBECS)

Allows the status of a

blood product order to be

updated based on bar

code reads.

Transfusion Order

Blood product dispense

status (Post-Transfusion

/Pre-Transfusion)

Electronic HL7

communications via the

Local Area Network

(LAN)

VistA Performs the function of

the authorization

database providing both

authentication and

authorization services.

User Login/ Access

information

Electronic Remote

Procedure Calls (RPCs)

over the Wide Area

Network (WAN)

VistA Patient Ordering Order blood products. Blood products. Electronic RPCs over the

WAN

VistA Computer Patient

Record System (CPRS)

Blood products must be

ordered through CPRS

Blood products. Electronic RPCs over the

WAN

VISTA-PIMS Admission

Discharge and Transfer

Package (ADT) module

Carry patient

demographic information

for communications but

also provide important

information about trigger

events

Patient admit, discharge,

transfer, registration,

PID (Patient

Identification) segment

PV1 (Patient Visit)

segment

Electronic RPCs over the

WAN

VistA Text Integration

Utilities (TIU)

The TIU system allows

the CFTV application to

upload the Transfusion

Record Form to the

patient record as a TIU

document.

Transfusion Record Form Electronic RPCs over the

WAN

4.2 PRIVACY IMPACT ASSESSMENT: Internal sharing and disclosure

Discuss the privacy risks associated with the sharing of information within the Department and what steps, if

any, are currently being taken to mitigate those identified risks.

Follow the format below:

Privacy Risk: When there are unencrypted automated communications between VistA, VBECS, and BCE,

then there will be unsecure patient data that may be accessed by unauthorized users that gain access to VA-

only networks/systems.

Mitigation: All communications take place on the VA Intranet; there is no public access to it. Access to the

VA Intranet is restricted to VA personnel. When VistA or its replacement system supports encryption, then an

effort will be made to encrypt all the communications. No interactions with any other VA systems occur. All

users are trained on the system and have valid, pre-approved access that is restricted by role.

Section 5. External Sharing and Disclosure

The following questions are intended to define the content, scope, and authority for information sharing

external to VA, which includes Federal, State, and local governments, and the private sector.

5.1 With which external organizations is information shared? What information is shared, and for

what purpose? How is the information transmitted and what measures are taken to ensure it is secure?

Is the sharing of information outside the agency compatible with the original collection? If so, is it

covered by an appropriate routine use in a SORN? If not, please describe under what legal mechanism

the IT system is allowed to share the information in identifiable form or personally identifiable

information outside of VA.

Identify and list the names of any Federal, State, or local government agency or private sector organization

with which information is shared.

For each interface with a system outside VA, state what specific information is shared with each specific

partner.

What legal mechanisms, authoritative agreements, documentation, or policies are in place detailing the extent

of the sharing and the duties of each party? For example, is the sharing of data compatible with your SORN?

Then list the SORN and the applicable routine use from the SORN. Is there a Memorandum of Understanding

(MOU), Computer Matching Agreement (CMA), or law that mandates the sharing of this information?

Describe how the information is transmitted to entities external to VA and what security measures have been

taken to protect it during transmission.

If specific measures have been taken to meet the requirements of OMB Memoranda M-06-15 and M-

06-16, note them here.

No information is shared with external organizations.

5.2 PRIVACY IMPACT ASSESSMENT: External sharing and disclosure

Discuss the privacy risks associated with the sharing of information outside the Department and what steps, if

any, are currently being taken to mitigate those identified risks.

Discuss whether access controls have been implemented and whether audit logs are regularly reviewed to

ensure appropriate sharing outside of the Department. For example, is there a Memorandum Of

Understanding (MOU), contract, or agreement in place with outside agencies or foreign governments.

Discuss how the sharing of information outside of the Department is compatible with the stated purpose and

use of the original collection.

Follow the format below:

Privacy Risk: As the BCE does not share data with any outside organizations, there are minimal to no

privacy risks to the data collected, stored, and maintained in the system.

Mitigation: The key mitigation to any privacy risk related to external sharing of VA data from BCE is that

the system does not connect to or share with any external organizations or systems.

Section 6. Notice

The following questions are directed at providing notice to the individual of the scope of information

collected, the right to consent to uses of the information, and the right to decline to provide information.

6.1 Was notice provided to the individual before collection of the information? If yes, please provide a

copy of the notice as an appendix. (A notice may include a posted privacy policy, a Privacy Act notice

on forms, or a system of records notice published in the Federal Register.) If notice was not provided,

why not?

This question is directed at the notice provided before collection of the information. This refers to whether the

person is aware that his or her information is going to be collected. A notice may include a posted privacy

policy, a Privacy Act statement on forms, or a SORN published in the Federal Register. If notice was

provided in the Federal Register, provide the citation.

If notice was not provided, explain why. If it was provided, attach a copy of the current notice.

Describe how the notice provided for the collection of information is adequate to inform those affected by the

system that their information has been collected and is being used appropriately. Provide information on any

notice provided on forms or on Web sites associated with the collection.

Patients are taught verbally by nurses that their wristband, which has the bar code, is used to assure they are

positively identified and to be sure the patient received the right medication, dose, blood and other products.

BCE scans bar codes on the patients and products used. The patient is aware when the nurse scans the bar

code on their wrist.

Individual information already exists in VistA or VBECS.

The Notice of Privacy Practice (NOPP) is a document which explains the collection and use of protected

information to individuals applying for VHA benefits. A signed statement acknowledging that they individual

read and understood the NOPP is scanned into each applicant’s electronic file. When updates are made to the

NOPP copies are mailed to all VHA beneficiaries.

Veteran patients consent for treatment and medical records when they register for treatment in the VA system.

Notice is provided by the system’s

.

The VA System of Record Notice (SORN), Electronic Document Management System(EDMS)-VA,

VA SORN 92VA045

The VA System of Record Notice (VA SORN) Patient Medical Records-VA, SORN 24VA10P2 (Feb.

11, 2014), in the Federal Register and online. An online copy of the SORN can be found at:

http://www.gpo.gov/fdsys/pkg/FR-2014-02-11/pdf/2014-02890.pdf

The VA System of Record Notice (VA SORN) Veterans Health Information System and Technology

Architecture (VISTA) - VA, SORN 79VA10P2 (Amended Oct. 31, 2012), in the Federal Register and

online. An online copy of the SORN can be found at: http://www.gpo.gov/fdsys/pkg/FR-2012-10-

31/pdf/2012-26804.pdf

6.2 Do individuals have the opportunity and right to decline to provide information? If so, is a penalty

or denial of service attached?

This question is directed at whether the person from or about whom information is collected can decline to

provide the information and if so, whether a penalty or denial of service is attached.

VHA Handbook 1605.1 Appendix D ‘Privacy and Release Information’, section 5 lists the rights of the

Veterans to request VHA to restrict the uses and/or disclosures of the individual’s individually-identifiable

health information to carry out treatment, payment, or health care operations. The Veterans have the right to

refuse to disclose their SSN to VHA. The individual shall not be denied any right, benefit, or privilege

provided by law because of refusal to disclose to VHA an SSN (see 38 CFR 1.575(a)).

The bar code assigned to a patient is the unique patient identifier which at this time is the patient’s Social

Security Number (SSN). The bar code itself is simply an electronically readable version of the unique patient

identifier which speeds up and improves accuracy of data entry. VHA policy requires all patients admitted to

the hospital or having a procedure to have a wristband that contains identifying information.

6.3 Do individuals have the right to consent to particular uses of the information? If so, how does the

individual exercise the right?

This question is directed at whether an individual may provide consent for specific uses or the consent is

given to cover all uses (current or potential) of his or her information. If specific consent is required, how

would the individual consent to each use?

The bar code used by BCE is an electronically readable version of the unique patient identifier (SSN

currently). VHA policy requires all patients admitted to the hospital or having a procedure to have a wristband

that contains identifying information. Therefore, the patient does not have the right to decline its usage if they

wish to receive service.

6.4 PRIVACY IMPACT ASSESSMENT: Notice

Describe the potential risks associated with potentially insufficient notice and what steps, if any, are currently

being taken to mitigate those identified risks.

Consider the following FIPPs below to assist in providing a response:

Principle of Transparency: Has sufficient notice been provided to the individual?

Principle of Use Limitation: Is the information used only for the purpose for which notice was provided either

directly to the individual or through a public notice? What procedures are in place to ensure that information

is used only for the purpose articulated in the notice?

Follow the format below:

Privacy Risk: Verbal notice is given by the clinician to the patient explaining the usage of the bar code on the

patient’s wristband. If the patient isn’t paying sufficient attention, they may miss what was conveyed to them.

Mitigation: In addition to the verbal notice given to the patient, notice was also given to the patient regarding

usage of their data when it is entered into VistA in order to fill out the patient’s wristband. See the VistA PIA

for details on notice given to patients (http://www.privacy.va.gov/privacy_impact_assessment.asp).

Section 7. Access, Redress, and Correction

The following questions are directed at an individual’s ability to ensure the accuracy of the information

collected about him or her.

7.1 What are the procedures that allow individuals to gain access to their information?

Cite any procedures or regulations your program has in place that allow access to information. These

procedures, at a minimum, should include the agency’s FOIA/Privacy Act practices, but may also include

additional access provisions. For example, if your program has a customer satisfaction unit, that information,

along with phone and email contact information, should be listed in this section in addition to the agency’s

procedures. See 5 CFR 294 and the VA FOIA Web page at http://www.foia.va.gov/ to obtain information

about FOIA points of contact and information about agency FOIA processes.

If the system is exempt from the access provisions of the Privacy Act, please explain the basis for the

exemption or cite the source where this explanation may be found, for example, a Final Rule published in the

Code of Federal Regulations (CFR).

If the system is not a Privacy Act system, please explain what procedures and regulations are in place that

covers an individual gaining access to his or her information.

Patient information can be found in either Vista or VBECS; see those systems’ PIA for details relating to

individuals accessing their information. To view these systems’ PIAs, please go to

http://www.privacy.va.gov/privacy_impact_assessment.asp. BCE reads bar codes that are assigned to

patients. The bar code number is based on information pulled from VistA for the patient, i.e. their social

security number. Individuals would request access to their VistA information where the data was stored or to

VBECS where their transfusion information is stored.

7.2 What are the procedures for correcting inaccurate or erroneous information?

Describe the procedures and provide contact information for the appropriate person to whom such issues

should be addressed. If the correction procedures are the same as those given in question 7.1, state as much.

BCE’s purpose is to prevent errors in patient care; it scans bar codes to prevent human error. Should a

transfusion status be incorrect, that information would be corrected in VBECS. Should any patient

information be incorrect, it would be corrected in VistA where the patient information is stored. See those

systems PIA’s for details on how to correct their information

(http://www.privacy.va.gov/privacy_impact_assessment.asp).

7.3 How are individuals notified of the procedures for correcting their information?

How are individuals made aware of the procedures for correcting his or her information? This may be

through notice at collection or other similar means. This question is meant to address the risk that even if

procedures exist to correct information, if an individual is not made fully aware of the existence of those

procedures, then the benefits of the procedures are significantly weakened.

See the VistA or VBECS PIA’s for their procedures for information correction

(http://www.privacy.va.gov/privacy_impact_assessment.asp). BCE is not the official record of any patient

information; the bar code is generated based on information in VistA.

7.4 If no formal redress is provided, what alternatives are available to the individual?

Redress is the process by which an individual gains access to his or her records and seeks corrections or

amendments to those records. Redress may be provided through the Privacy Act and Freedom of Information

Act (FOIA), and also by other processes specific to a program, system, or group of systems.

Example: Some projects allow users to directly access and correct/update their information online. This helps

ensures data accuracy.

See the VistA or VBECS PIA’s for their procedures for information correction

(http://www.privacy.va.gov/privacy_impact_assessment.asp).

7.5 PRIVACY IMPACT ASSESSMENT: Access, redress, and correction

Discuss what risks there currently are related to the Department’s access, redress, and correction policies

and procedures for this system and what, if any, steps have been taken to mitigate those risks. For example, if

a project does not allow individual access, the risk of inaccurate data needs to be discussed in light of the

purpose of the project. For example, providing access to ongoing law enforcement activities could negatively

impact the program’s effectiveness because the individuals involved might change their behavior.

Consider the following FIPPs below to assist in providing a response:

Principle of Individual Participation: Is the individual provided with the ability to find out whether a project

maintains a record relating to him?

Principle of Individual Participation: If access and/or correction is denied, then is the individual provided

notice as to why the denial was made and how to challenge such a denial?

Principle of Individual Participation: Is there a mechanism by which an individual is able to prevent

information about him obtained for one purpose from being used for other purposes without his knowledge?

Follow the format below:

Privacy Risk: Patients may try to get their information corrected in BCE when the proper place to correct

their information is in VBECS or VistA.

Mitigation: Patients should follow VistA’s or VBECS’ procedures for information correction; see their

respective PIAs for information relating to accessing the information kept

(http://www.privacy.va.gov/privacy_impact_assessment.asp).

Section 8. Technical Access and Security

The following questions are intended to describe technical safeguards and security measures.

8.1 What procedures are in place to determine which users may access the system, and are they

documented?

Describe the process by which an individual receives access to the system.

Identify users from other agencies who may have access to the system and under what roles these individuals

have access to the system.

Describe the different roles in general terms that have been created to provide access to the system. For

example, certain users may have "read-only" access while others may be permitted to make certain

amendments or changes to the information.

Access control for BCE is managed using VistA. This applies to both accesses to the CFTV clients (both

desktop and handheld) and to CareFusion Management Console (CFMC). Only VA personnel have access to

the application. VistA permissions are given to users based on the user access process for each individual site.

The process may be summarized as follows:

1. All users have their own account for both the client and the handheld. Every CFTV user accesses the

CareFusion Management Console and clients using his own VistA Access and Verify code. This

includes both administrators and clinical end users. The BCE Increment 2 Product Operations Manual

(POM) contains a detailed section on how authorization (logon) works and a detailed discussion on

how to troubleshoot the problem of denied access.

2. The roles granting a user a given level of access to the CFTV software are granted based on the user’s

VistA access. Roles include RN, Nurse Manager, BCE Coordinator and BCE System Administrator.

3. Clients or handhelds at hospitals authenticate to the CFTV server at the DCO data center using their

VistA Account. In other words, all users access CFTV using their VistA Access and Verify codes.

4. EDA handhelds rely on an AirBeam Client to synchronize client software updates with the application

server via FTP. This requires the setup of a local user account on the application server that only has

access to the C:\Inetpub\ftproot folder.

The bullets below specify how user authorization and authentication function for both the CFTV Client

application and CareFusion Management console web client application.

CFTV Client Application (Desktop and PDA’s):

o User Authentication – User VistA access/verify code.

o User Authorization – User must be assigned to the correct groups.

CareFusion Management Console Web Client (Internet Explorer)

o User Authentication – User VistA access/verify code.

o User Authorization – Role-based access control by the VistA secondary menus assigned to a

particular user.

The individuals who manage VistA user accounts for a given site will be managing BCE users at the same

time. The process followed for adding a VistA user or modifying a VistA user’s access level is already in

place. A given VistA site may elect to have one person manage this process for BCE but implementing that

process is the prerogative of a specific VistA site.

Server Administrator Access Hierarchy Per VA system security requirements, server administrator access is granted through a special administrative

account that requires two-factor authentications before access is granted. All users are granted administrator

access only to those systems for which they are considered system owners.

Site-based BCE Administrators (OI&T, Field Operations) Site-based BCE Administrators can administer the BCE application but are not server administrators. These

users can perform tasks such as defining new BCE users and assigning rights within BCE, but cannot alter the

server operating system in any way.

In normal operation new users are added to file 200 on the VistA side and then granted the menu keys and

options required to access BCE. A separate step to add them as BCE users is still needed, and care must be

taken to match up VistA users with BCE users

ACCESS CONTROLS:

National BCE Administrators (Field Operations) The National BCE administrators are considered system owners for all virtual guests that make up the BCE

environment. Servers included in this environment are all SQL servers and Terminal/Application servers. The

BCE project is upgrading from SQL Server 2008 to SQL Server 2012.

SQL Support Staff (Field Operations, DCO Core Systems Service Line) DCO/EO SQL support staff is considered system owners of BCE SQL servers and are responsible for

assisting the National BCE administrators in the support of all SQL technologies.

Virtual Infrastructure Support Staff (DCO Core Systems Service Line) The Core Systems Service Line/Platforms group has full responsibility for the health and availability of all

systems that make up and run within the virtual infrastructure. Access consists of full administrative

privileges on ESX hosts, VMware vCenter, and guest operating systems. Access also includes root access to

all functionality exposed by the servers’ remote management hardware.

8.2 Will VA contractors have access to the system?

If so, how frequently are contracts reviewed and by whom? Describe the necessity of the access provided to

contractors to the system and whether clearance is required.

The access rights and process for BCE is the same for all users, regardless of whether they are a VA

employee or VA contractor. For contract staff, the Contracting Officer Representative (COR) monitors the

staff on a regular basis. The frequency depends on the Quality Assurance Surveillance Plan (QASP) that was

setup during the contracting process, but it could be monthly, quarterly or annually.

8.3 Describe what privacy training is provided to users either generally or specifically relevant to the

program or system?

VA offers privacy and security training. Each program or system may offer training specific to the program

or system that touches on information handling procedures and sensitivity of information. Please describe

how individuals who have access to PII are trained to handle it appropriately.

The users of the Blood Administration portion of the BCE system are trained clinicians who

administer blood products at VAMC’s. This includes transfusionists and nurses. All users also have to complete privacy training in Talent Management System (TMS) as required of all VA employees.

While these users are proficient in the use of VistA desktop applications, specific training on both the

CareFusion TV desktop/laptop client programs and the CareFusion TV EDA devices will be provided

so users can get the most out of the bar code software when delivering and accounting for blood

products.

The project has created instructional materials and coordinated with the vendor to schedule onsite

training at each site prior to deployment. Because the training materials and training courses are

already in place, site clinicians and IT support personnel will be able to install, configure and support

both the Pyxis® CFTV handhelds and the Pyxis® CFTV desktop application.

8.4 Has Authorization and Accreditation (A&A) been completed for the system?

If so, provide the date the Authority to Operate (ATO) was granted. Please note that all systems containing

SPI are categorized at a minimum level of “moderate” under Federal Information Processing Standards

Publication 199.

An ATO with Conditions (ATOC) was granted to BCE on 2016-05-18 for 120 calendar days. The project

team will continue to work with the assigned A&A staff to update the ATO for this product until after

National Release. This document is required to receive the full ATO.

Signature of Responsible Officials

The individuals below attest that the information provided in this Privacy Impact

Assessment is true and accurate.

_________________________________________

Privacy Officer, Andrea Wilson

_________________________________________

Information Security Officer, Diane Dixon

_________________________________________

System Owner/Project Manager, James Plastow

__________________________________________

Individual Completing the PIA, James Plastow