Business Requirements Document Template



Automatic VHIE Opt-In

Work Effort #20151107

Business Requirements Document

[pic]

June 2016

Revision History

Note: The revision history cycle begins once changes or enhancements are requested after the Business Requirements Document has been accepted.

|Date |Description |Author |

|March 2015 |Initial version |Sam Bordelon |

|September 14, 2016 |Accepted version |Margaret Donahue (date of approval)|

|Date BRD submitted to OI&T for|Accepted version |OI&T Name (date of acceptance) |

|sign-off | | |

Table of Contents

1. Purpose 1

2. Overview 1

3. Scope 2

4. Customer and Primary Stakeholders 2

5. Goals/Objectives and Outcome Measures 2

6. Enterprise Need/Justification 3

7. Business Requirements 4

7.1. Business Need (Epic), Business Requirement (User Narrative) 4

7.2. User Access Levels 4

7.3. Known Interfaces and Data Sources 5

7.4. Related Projects or Work Efforts 6

7.5. Availability 8

7.6. Capacity & Performance 8

7.7. Interfaces and Security 9

8. Other Considerations 9

8.1. Alternatives 9

8.2. Assumptions 10

8.3. Dependencies 10

8.4. Constraints 11

8.5. Business Risks and Mitigation 11

Appendix A References 12

Document References: 12

Appendix B Models 14

Appendix C Stakeholders, Users, and Workgroups 15

Stakeholders 15

Stakeholder Support Team (BRD Development) 16

Appendix D Enterprise Requirements 17

Appendix E Non-Functional Requirements 24

Appendix F User Interface/User Centered Design Principles 30

Appendix G Acronyms and Abbreviations 32

Purpose

The Business Requirements Document (BRD) is authored by the business community for the purpose of capturing and describing the business needs of the customer/business owner identified within the New Service Request (NSR) #20151107 Automatic Veterans Health Information Exchange (VHIE) Opt-In[1]. The BRD provides insight into the AS-IS and TO-BE business areas, identifying stakeholders and profiling primary and secondary user communities. It identifies what capabilities the stakeholders and the target users need and why these needs exist, providing a focused overview of the request requirements, constraints, and other considerations identified. This document is a business case and does not mandate a development methodology, however the requirements are written using agile methodology deliverables. The intended audience for this document is the Office of Information and Technology (OI&T) to facilitate project planning when the project is approved and funded. These requirements are not documented at a level sufficient for development.

Overview

The Veterans Authorizations and Preferences (VAP) application provides management and tracking of authorizations and forms required to be completed by the Veteran or Servicemember (SM), and their family members, for processing by the Department of Veterans Affairs (VA). These authorizations/forms authorize or restrict the Release of Information (ROI) for healthcare, benefits, and other VA related services for which they are eligible. Electronic management of these forms (whether submitted manually or electronically) and tracking of the information disclosed is accomplished in the VAP application.

The current VAP process that allows a Veteran to participate in exchanging health data originates with a signed Authorization form (Opt-In).This authorization allows the VAP system to exchange information that is protected by policy (Title 38 USC 7332[2], VIP, Employee etc.). The VA requires these authorizations for all Veterans, regardless of whether policy protected information is present in their health data records or not. The majority of Veterans’ health data does not have such protected information, yet the Veteran is still required to provide an authorization to participate in the exchange of health data for treatment purposes. The majority of signed authorizations are paper based and, as a result, are manually processed, resource intensive, and burdensome. Over the previous 5 years, the VA Health Information Exchange (HIE) program has collected an annual average of 54,000 authorizations (270,000 total or 3% of the 8.76 million actively enrolled Veterans). At this pace, to provide coverage for all enrolled Veterans, it would take 162 years! The authorizations collected are only valid for 5 years with a significant percentage of the authorizations need to be renewed each year. Finally, the low rate of Veterans participation contributes to the low rate of health information exchange transactions resulting in missed opportunity for care coordination and outcome improvements.

The functionality outlined within this NSR seeks to implement an “implied consent” based system for Veterans who do not have any policy protected information within their health data. The updated system would allow Veterans without protected information to be automatically eligible for exchanging their health data for treatment purposes without the need to provide an authorization, resulting in “Automatic Opt-In”.

Veterans who have protected information would not be eligible for automatically opting in unless they have submitted an authorization to do so, or if the protected information were masked or redacted in accordance with Veterans Health Administration (VHA) policy. Automatic Opt-In functionality streamlines the process of making Veterans’ health data more available to providers while maintaining the appropriate level of privacy of Veterans with protected conditions as per U.S.C. Title 38 Section 7332.

Scope

This work effort covers the below functionality;

• Provide the ability to exchange Veteran health data without a signed authorization for treatment purposes or when legally permitted when no policy protected information exists within the health data.

• Provide the ability to restrict the exchange of Veteran health data when policy protected information exists within the health data.

• Provide the ability to identify Veterans for whom information has been requested and who have protected conditions but no authorization on file so that an authorization can be obtained.

Future functionality:

• Provide the ability to remove (e.g., mask, redact, etc.) specific protected health information in accordance with policy.

• Provide the ability to exchange Veteran health data containing removed, redacted, or masked information when a signed authorization is not on file.

This work includes both the changes to existing VA Health Information Exchange components, including eHealth Exchange and Direct, as well as the new service to automatically dectect the presence or absence of privacy sensitive conditions within various documents (e.g., C-CDA CCDs, C32s, C62s, and others).

The new workflows associated with this work are described in Appendix B.

Customer and Primary Stakeholders

Margaret Donahue, Director, representing the Office of Health Informatics (OHI), is the primary stakeholder for this request. Review Appendix C for the complete list of primary and secondary stakeholders.

Goals/Objectives and Outcome Measures

|Goal/Objective and Desired Outcome |Impact/Benefit |Measurement |

|Eliminate the need for signed authorizations for |Remove the burden of obtaining |Percentage of Veterans who participate in the |

|treatment purposes on Veterans with no policy |authorizations in treatment situations|health data exchange program would grow rapidly |

|protected information within their health data. |for Veterans with no protected |once this was implemented. |

| |conditions, freeing up useful | |

| |resources. | |

|In order to participate in health data exchange, |Maintains privacy for Veterans with |Number of new signed authorizations would be |

|require a signed authorization only in situations |these conditions. |limited to applicable Veterans, rather than all |

|when the Purpose of Use is Treatment and the | |Veterans where an authorization would not be |

|Veteran has policy protected information within | |necessary. |

|their health data. | | |

|Mask, remove, or redact information protected by |Would allow for Veterans with |The only Veterans not exchanging health data, |

|policy from Veteran health information if no |protected information and no signed |protected or otherwise, would be those who have |

|authorization is on file, making the data eligible|authorization to exchange health data,|managed their preferences and restricted data |

|for exchange (future functionality goal). |while not disclosing their protected |exchange. |

| |information to partners. | |

|Locate Veterans with policy protected information |Will allow for staff to contact |Percentage of Veterans with protected conditions |

|within their health data who do not have signed |Veterans and obtain authorizations, |and no authorization on file would begin to |

|authorizations on file when their health data has |boosting the level of care available |decrease once outreach efforts took place. |

|been requested. |to Veterans with protected conditions.| |

|Ensure the VAP system and related policy decision |Privacy compliance will be maintained.|Updates will be made to the system in accordance |

|engine components are updated and enhanced to | |with privacy policies. |

|remain compliant with privacy regulations. | | |

|Ensure the VA eHealth Exchange Adapter and Direct |Privacy compliance will be maintained.|Updates will be made to the system in accordance |

|are updated to remain compliant with privacy | |with privacy policies. |

|regulations. | | |

Enterprise Need/Justification

In support of the VA Fiscal Year (FY) 2014-2020 Strategic Plan goal to Enhance and Develop Trusted Partnerships,[3] this project will allow VA to meet interoperability needs between VA, Department of Defense (DoD), Social Security Administration (SSA), and outside providers. Specifically, the enhancements are in support of compliance with mandatory exchange agreements, and with the Master Veteran Index (MVI), Health Information Management Service (HIMS), and privacy mandates.

Enabling the efficient management of authorizations and information sharing also supports the VA FY 2014-2020 Strategic Plan goal to Manage and Improve VA Operations to Deliver Seamless and Integrated Support.[4]

In addition, this project is supporting the VHA’s Priorities for Strategic Actions (PSA). The PSAs in line with this project include High Performance Network[5] and Best Practices[6].

Lastly, this work effort seeks to greatly improve the number of Veterans participating in the VLER program. Currently, the VA HIE has only authorized 270,000 Veterans to participate. As a result, the VA releaseas only 2% of requests received from partner facilities due to the lack of signed authorization consent from Veterans. This work effort would drastically increase the use and utility for Veterans, their care providers, and the VA.

Business Requirements

1 Business Need (Epic), Business Requirement (User Narrative)

Epics, user narratives, user stories, and acceptance criteria will be captured in the Requirements Traceability Matrix (RTM). The requirements table below provides a list of the epics that are detailed in the RTM for the Automatic VHIE Opt-In project. The RTM is stored as a separate document and can be accessed via the Requirements Traceability Link located in the New Service Request Database:

VHIE Opt-In_RTM.xlsx

Automatic VHIE Opt-In Requirements Table

|Category |Description |

|Epic Description |Restrict/Authorize Information Types: Provides the ability for Veterans to manage their participation in an |

| |electronic health information exchange program. Current functionality is based around authorizing information to|

| |be exchanged with approved providers. In the “To Be” state, implied consent to exchange non policy protected |

| |information would be implemented. Policy protected information may include US Title 7332 protected conditions, |

| |VIP status, or Employee data. Policy protected information would require a signed authorization to be exchanged.|

| |The functionality outlined within this Epic allows for the Veteran to restrict some or all of their sharing of |

| |health data and/or authorizing (Opt-In) the exchange of policy protected information. The consent management |

| |tool used by Veterans is accessible through the MyHealtheVet or eBenefits portal. |

|Epic Value Statement |For: Veterans |

| |Who: need the ability to manage how their health information is exchanged with internal or external partner |

| |facilities. |

| |The process: allows a Veteran to control the sharing of their health data as allowed by policy. |

| |That: maintains the Veteran’s ability to control their level of participation in health information exchanges |

| |Unlike: the status quo, where a Veteran can only restrict certain exchange partners. |

| |Our process: offers Veterans control over restricting/authorizing specific types of information and who can |

| |receive such data. |

|Success Criteria |The Veteran can manage authorizations and restrictions of policy protected information sharing from any location|

| |where they can access their MyHealtheVet or eBenefits account 100% of the time. |

|In Scope |Provide Veterans the ability to restrict (Opt-Out), partially or fully, of sharing health data. |

| |Provide Veterans the ability to authorize (Opt-In) sharing of certain policy protected information (e.g., 7332 |

| |protected conditions, Employee, V.I.P., etc.) |

|Out of Scope |Providing a Graphical User Interface (GUI) where the Veteran can manage such authorizations and restrictions. |

|Non-functional |The system shall reflect updates or changes to authorization status in real time. |

|Requirements |The system shall require confirmation from a user when changes to authorizations and restrictions is submitted. |

| |The system shall alert the user if the submitted changes to authorizations or restrictions were not able to be |

| |saved for any reason. |

|Category |Description |

|Epic Description |Automatic Opt-In: Enable the VA to automatically allow the disclosure of health data without a signed patient |

| |authorization when policy protected health information (e.g. Title 7332 protected conditions, VIP status, |

| |Employee etc) is not present within the health data being disclosed. Current policy requires all Veterans to |

| |submit signed authorizations to electronically exchange health data, even when policy protected data is not |

| |present within the health data. |

|Epic Value Statement |For: Veterans |

| |Who: want to participate in the sharing of health data within the electronic health information exchange |

| |program. |

| |The: process would automatically allow the disclosure of non-protected health data. |

| |That: assumes “implied consent” to sharing of non-protected health data. |

| |Unlike: the status quo of requiring a signed authorization for exchange of all health data |

| |Our process: improves the efficiency of the health information exchange process by requiring signed |

| |authorizations only when protected conditions are present in Veteran’s health data, making important health data|

| |available to the Veteran’s health care providers. |

|Success Criteria |Disclosure of health data containing no policy protected health information is accomplished with no human |

| |intervention 100% of the time, without requiring a signed authorization prior to disclosure. |

|In Scope |Automatic authorization of Veterans with non-protected information in their health data. |

|Out of Scope |Required changes to any policy or legislation that is required for this functionality to be implemented. |

|Non-functional |The system shall reflect updates or changes to authorization status in real time. |

|Requirements |The system shall require confirmation from a user when changes to authorizations and restrictions is submitted. |

| |The system shall alert the user if the submitted changes to authorizations or restrictions were not able to be |

| |saved for any reason. |

|Category |Description |

|Epic Description |Authorize or Redact Protected Information: Enable the VA to exchange health data for those Veterans with |

| |protected health data (e.g.7332 conditions, VIP, Employee etc.), if they have a signed authorization on file, or|

| |if the protected information is removed or redacted in accordance with policy. |

|Epic Value Statement |For: Veterans |

| |Who: have protected health information in their health data |

| |The: process would allow the sharing of protected health data if a valid signed authorization is obtained and on|

| |file, or if the protected information is removed or redacted. |

| |That: maintains the Veteran’s privacy while allowing them to share health data in accordance with their |

| |preferences. |

| |Unlike: the status quo, which prevents sharing of any health data, including valuable non- protected health |

| |data, if no authorization is on file. |

| |Our process: improves the efficiency of the health information exchange process and the quality of care Veterans|

| |with protected conditions receive by either exchanging their health data with all conditions (obtained |

| |authorization on file) or by removing/redacting protected conditions, making other important health data |

| |available to the Veteran’s health care providers. |

|Success Criteria |100% of Veterans with protected conditions present in their health data would be eligible for exchanging health |

| |data. A signed authorization and/or the redaction/removal of protected conditions in lieu of a signed |

| |authorization would make these Veterans eligible for health information exchange. |

|In Scope |Redact/Remove policy protected health data from Veteran’s health data when a signed authorization is not on |

| |file, making the data eligible to be shared under the implied consent requirement. |

| |Run reports to identify Veterans with protected conditions and no authorization on file |

|Out of Scope |Actual Veteran outreach seeking authorizations for those with protected conditions but no authorizations on |

| |file. |

|Non-functional |Exchange times should be consistent with existing standards. |

|Requirements | |

3 User Access Levels

|User Level |Role |Responsibilities |VAP Access Level |

|Primary Users |VA Medical Center |Run reports, add Veteran information |Read/Write Access |

| |(VAMC) Employees | | |

|Primary Users |ROI Staff |Run reports, add Veteran information |Read/Write Access |

|Primary Users |VHA Office of |Run reports, add Veteran information |Read/Write Access |

| |Informatics and | | |

| |Analytics (OIA) Staff| | |

|Primary Users |Health Information |Run reports, add Veteran information |Read/Write Access |

| |Management (HIM) | | |

| |Staff | | |

|Secondary Users |Healthcare Identity |Run reports, add Veteran information |Read/Write Access |

| |Management (HC IdM) | | |

|Secondary Users |OI&T System |Run reports, add Veteran information |Full Access |

| |Administrators | | |

|Secondary Users |Veterans Benefits |Run reports |Read/Write Access |

| |Administration (VBA) | | |

| |Call Centers | | |

4 Known Interfaces and Data Sources

This is the business community’s best understanding of known/existing interfaces and may not be a comprehensive listing.

|Name of Application |Description of current application |Interface Type |

| | | |

|My HealtheVet |The Veteran’s Personal Health Record |Web Based |

|NwHIN Adapter |A VA system enabling the discovery of shared patients with trusted partners, and the |Bi-Directional |

| |sending and receiving of standard-based health information for these shared patients. | |

| |This component is between the ‘NwHIN Gateway’ and the VA EHR. It is also called eHealth | |

| |Exchange Adapter, Exchange Adapter, VLER Adapter, or just Adapter. | |

|eHealth Exchange |Nationwide Health Information Network is a secure standard-based mechanism for |Automated |

| |healthcare data exchange among trusted healthcare organizations. | |

|Occupational Health |Web-based portal application that provides a central interface for users to access |Bi-Directional |

|Record-keeping System |information and applications necessary for their roles. | |

|(OHRS) | | |

|Identity Access Management |Receives, manages, and enforces VA and Veteran security and privacy policies. |Bi-Directional |

|(IAM) | | |

|MVI |Master Veterans Index: The authoritative identity service within the VA, establishing, |Bi-Directional |

| |maintaining and synchronizing identities for VA clients, Veterans and beneficiaries. | |

|IdM |Integration of VAP with MVI |Bi-Directional |

|Veteran Point of Service | Kiosks are self-service, touchscreen devices that allow enrolled Veterans to securely |Bi-Directional |

|(VPS)/Kiosk |perform basic tasks | |

|VBMS |Veterans Benefits Management Systems: System that manages Veteran benefits claims. |Automated |

|eBenefits |Portal, web-based, online presence that allows Veterans and Service Members to browse or|Bi-Directional |

| |search military service-related and Veteran benefits information. | |

|Computerized Patient Record|Enables you to enter, review, and continuously update all the information connected with|Automated |

|System (CPRS) |any patient. | |

|VistAWeb | Clinician portal accessible through CPRS, and is the user interface for remote data in |Automated |

| |all VistAs. | |

|Virtual Lifetime Electronic|VLER DAS is a system of middleware used to transport clinical and non-clinical |Bi-Directional |

|Record (VLER) Data Access |information between Producer and Consumer applications. | |

|Service (DAS) | | |

|Access VA |Online portal for accessing VA services. |Web Based |

|VAPii |Access, retrieve, complete and store the required forms that must be completed |Bi-Directional |

| |for processing by VA for entitlements, benefits, or services. | |

|VAP |Veterans Authorization Preferences: a system used to record and manage patient |Web-based |

| |authorization preferences. In addition, it provides the interface to the IAM Access | |

| |Control System (Policy Decision Engine) and is also the interface for several reports | |

| |including accounting of disclosures. | |

|SLS |Security Labeling Service, a service that automatically detect privacy sensitive |Service |

| |conditions in provided data and can label it, based on HL7 standards | |

|PPS |Privacy Protection Service: this component conforms to HL7 standards and is used to |service |

| |redact privacy sensitive information, after it has been labeled by the SLS service | |

5 Related Projects or Work Efforts

NSR #20100102, NwHIN Enhancements



This is a request to (1) Expand the information that will be exchanged in the pilot (a subset of Health Information Technology Standards Panel [HITSP] C32 information is being exchanged between San Diego VAMC, Kaiser Permanente, and DoD) (2) Provide the infrastructure needed to expand beyond the 3 sites (3) Automate identity management processes (correlation of identities between the entities) (4) Electronically manage, integrate, and enforce VA consumer preferences, as well as organizational and U.S. security and privacy policies relative to Health Information Exchange (HIE). (Consumer Preferences and Policy (CPP) Management requirements have been documented in the BRD developed for NSR 20090624. The BRD for this request will incorporate all of the requirements documented in the 20090624 BRD.)

NSR #20110320, CPP/VAP Expand Capabilities to Accept an SSA Authorization



Under the VLER Initiative, there is a desire to pilot an exchange of Veteran health information with SSA using the NwHIN. In order to provide health information to SSA, VA requires an authorization from the Veteran by way of SSA or the Veteran. The current process for releasing a Veteran’s health information to SSA for disability benefits claims is a time consuming manual process completed by the ROI office. The ROI office either receives the authorization via US Postal Mail or uses an SSA online portal that allows the authorization to be uploaded to the portal. VA ROI staff must frequently enter the online portal to manually validate the authorization and also upload the medical information that they can.

Veterans Online Application II (VONAPP) Direct Connect (VDC)



VONAPP II, which includes a redesign of legacy VONAPP, will leverage the eBenefits portal, a web-based, online presence that allows users to browse or search military service-related and Veteran benefits information. Veterans, beneficiaries, military SMs, and other eligible claimants will use VONAPP II for submitting claims electronically for the following VBA benefits: Compensation and Pension (CP), Education, and Vocational Rehabilitation and Employment (VRE). VONAPP II/eBenefits users will be allowed to establish secure accounts with a unique username and password and will be able to receive personalized and customized information relevant to them, as well as conduct online transactions related to the application for VBA benefits and services and maintenance of those VBA benefits and services. Access to VONAPP II through eBenefits will provide a secure form of e-authentication by comparing information entered by the customer with the VA corporate database, Beneficiary Identity Records Locator System (BIRLS), VA/DoD Identity Repository (VADIR), Defense Enrollment Eligibility Reporting System (DEERS) data, and other authoritative VA data sources. This will eliminate the need for end users to enter several different sites. Portal users will have the ability to access information securely, depending on their user profiles, from anywhere at any time.

NSR #20111003, VPS Kiosk



The VPS Kiosk project will implement kiosks for administrative functions at all VAMCs and some Community-Based Outpatient Clinics (CBOC). The kiosk thin client application is provided by Vecna and will interface with the VistA Application Programming Interface (API)/Remote Procedure Calls (RPC) for Veteran information. The interface can be direct from Vecna, Medical Domain Web Services (MDWS) middleware, or third party (Harris) custom middleware.

NSR #20111209, Disability Benefits Questionnaire (DBQ) Services



In order to support claims transformation initiatives that will improve VA CP examination processes, IT enhancements are requested to support the business need to expedite the distribution, completion, and transmission of VA CP evaluation results. The requested changes would improve how examiners choose the method to document the evaluation results, automate to the maximum extent possible the CP evaluation documentation process, provide for secure transmission and/or collection, and provide the information in the evaluation results to end user consumers in a format compatible with the applications used in the CP process (Rating Veterans Service Representatives [RVSR], Veterans Service Representatives (VSR), CP Clinicians, etc.) In addition, the requested changes will support the use of contract providers and Veterans’ private providers who do not have VA system access and are not familiar with VA processes. Automated changes will align with the VLER long-term initiative’s solution.

NSR #20120303, VLER DAS



As part of the HIE subgroup chartered by the Interagency Clinical Informatics Board (ICIB), multiple clinical priorities were evaluated by the major stakeholders of the VA-DoD HIE and identified the following major performance and usability enhancement: Improve the performance and usability issues (including response time/timeouts/incomplete viewable data) associated with the viewing of VA and DoD data transmitted over the VLER DAS. History: VA and DoD have previously exchanged information via the Bidirectional Health Information Exchange (BHIE) for the past ten years. BHIE currently enables the exchange of 31 data domains. VHA has determined that BHIE is going into sustainment with no further development. The VLER DAS is the next generation mechanism for transfer of data, offering a web-based capability that provides high performance, reliability, adaptability, and sustainability.

NSR #20090803, Personal Identification Verification (PIV) Integration: Access Control Services (ACS)



This project is to support the end-to-end integration of legacy VistA and HealtheVet-VistA applications to the PIV Project’s IAM and ACS by providing the assured access control decision information, end-user authorization attributes, trust, and privacy to a common architecture supporting VHA’s need to provide patient care within a connected healthcare community.

6 Availability

|Service Level Requirement (SLR) Question |SLR Criteria |Description |

|How much time should the system be available |99.9% (8.76 hours down time) | |

|(and how much down time is acceptable due to | | |

|incident [unexpected] outage)? | | |

|When should the system be available (what |24x7 | |

|will be the core operating hours of the | | |

|system)? | | |

|How soon should the system fully recover from|Minutes | |

|an outage? (Includes Mean Time to Restore) | | |

|How much data will be restored when outage is|100% (continuous back-up) | |

|recovered? | | |

|What time period should be considered for |Overnight | |

|maintenance periods? | | |

|What standard time zone will the system |All time zones | |

|operate in? | | |

7 Capacity & Performance

|SLR Question |SLR Criteria |Description |

|How many users will be on the system hourly? |>1000 | |

|How many transactions will each average user |1-10 | |

|perform each hour? | | |

|What are the anticipated peak user times |Business day (7am-7pm) |Standard clinical hours across all time zones |

|during the day? | | |

|What is the anticipated peak transaction load|Business day (7am-7pm) |Standard clinical hours across all time zones |

|(when do you think that there will be the | | |

|most transactions being performed on the | | |

|system) during the day? | | |

|How many new users will be added in one year?|>1000 | |

|How many more (if any) transactions will be |Unknown | |

|added in one year? | | |

|What kind of information will be stored |Small documents (example pdf or Word file) | |

|(specify average of each kind per month)? |Forms & Documents that are formatted | |

| |(example forms or documents with images) | |

|What kind of search capacity is required? |Heavy (greater than 1,000 per hour) | |

|What type of system(s) is/are required? |Internet (public) |With approved credentials |

|Is there a need for heavy application |End of day | |

|reporting? If yes, when? | | |

8 Interfaces and Security

|SLR Question |SLR Criteria |Description |

|Does this system interact with other existing|Yes |Multiple different clinical related systems, see|

|systems? | |list in section 7.3 |

|Will this system require additional |Yes |TBD |

|monitoring for Information Technology system | | |

|metrics? | | |

|Will this system contain Personally |Yes |All sources standard with health data |

|Identifiable Information, PHI, HIPAA | | |

|information, or other confidential/regulated | | |

|data? | | |

|Who will be the anticipated users of this |VA |VA and approved partners. |

|system? |Public | |

Other Considerations

1 Alternatives

VHA is seeking legislative relief to the requirement under 38 U.S.C. 7332 for obtaining a signed, written authorization in order to disclose protected conditions to a provider for treatment purposes. Congressman O’Rourke has drafted a bill that would amend 38 U.S.C. 7332 to permit disclosures to providers for treatment purposes without the authorization of the Veteran. If this bill is passed, some of the business requirements within this document may be eliminated or modified.

It is not certain that Congressman O’Roarke’s efforts will succeed. House and Congressional action is not certain nor is it known when or if this effort will be brought forward to an actual vote. Regardless of whether the exemption for “Treatment” eventually passes, other considerations exist supporting the need for security labeling for the secure control of information exchanges both between systems inside and outside of VA:

• The waiver allows sharing without an authorization for “treatment” only. The waiver does not remove the basic sensitivity of the information under 38USC7332. Hence while it can be shared for treatment, it still must be labeled “Restricted” if it indeed contains 38USC7332 information.

• 38USC7332 also requires labeling such as “Do not further re-disclose without patient consent”. While 38USC7332 may not apply to a partners information, it does apply to the labeling and handling instructions that VA applies.

• The authorization waiver does not apply to any othery purpose of use such as Research, Marketing, Payment, Operations, Veteran Self-Declared, “VIP, Employee, Legal Hold”, etc.,

• Security labels for C-CDA and Fast Healthcare Interoperability Resources are mandated by ONC Meaningful Use and by HL7 standards as the governing authority.

• iEHR Security recognized both role and attribute-based access control as required. This continues into eHMP.

• The urgent need to address the current issue regarding VA’s inability to release information on the likely 70-80 percent of our population that do not have 38USC733 conditions demand simmediate action as specified in BRD 20151107.

Therefore, there remains an ongoing need for VAP to implement a “Security Labeling Service” capability as a high priority as specified.

3 Assumptions

An assumption is a statement that is presumed to be true without concrete evidence to support it. The following assumptions pertain to the solution for this effort:

• VA will implement updated regulations for 38 U.S.C. 7332 that will be amended to no longer consider negative Human Immunodeficiency Virus (HIV) and sickle cell anemia test results to be protected conditions.

• Trusted partners/sources are capable of sending electronic consent directives that VHA can incorporate into their systems/processes. 

• The electronic consent directives received from trusted partners/sources will be credentialed/authorized at an appropriate level.

• The VA has approved the use of COTS products that will affect this work effort. The COTs product will address the Security Labeling Service (SLS) that will detect and tag protected health data in CCDAs. This work includes the changes to the existing VHIE components as well as integration of the SLS service.

• Stakeholder continuity will be upheld where possible to help ensure the success of this project moving forward. Stakeholders will be available for further requirements elaboration as necessary.

• Subject Matter Experts (SME) and key stakeholders will be identified in collaboration with the Business Owner or designee and remain engaged throughout the lifecycle of the work effort.

• Project priorities have been established and funding is likely.

• Appropriate technical staff will be assigned and engaged to participate in the work effort.

4 Dependencies

• This functionality requires that a risk tolerance be determined for the new functionality. This tolerance level has not been determined and will need to be determined before functionality can be implemented.

• VAP analysis and development resources will be available for continued elaboration.

• Interfacing mechanisms between VAP and trusted partners/sources and internal systems will exist and will be available.

• Requirements elaboration: the requirements contained in this document require further detailed analysis and the development of use cases and/or other supporting analysis artifacts before moving into product development.

• MVI integration component will be in place (IAM_PY20120221.2, IAM_PY20120221.1 IAM_SR20110405.3).

• Technical capabilities will exist to support external partners’ requests for Special Access Control (SAC) and Credentialing Audit Reporting (CAR)-compliant audit capabilities.

• The solution provided will need to not only support current applications and requirements, but also be flexible enough to support future IAM needs without a complete process and application redesign.

• The development of any tools, repositories, or applications in support of the eHealth Exchange goals and processes must adhere to the VHA HC IdM enterprise requirements, to ensure that the integrity of the patient correlations is of the highest level and that no degradation of VHA patient information is experienced.

5 Constraints

• A proof of concept was developed to test this functionality. The proof of concept proved that it can function as intended, but the sample size was not statistically significant. This technology has not yet been tested with a statistically significant data set to ensure it is within the acceptable error and risk tolerance levels.

• Requirements Analyst and Business Architect staff availability may be limited.

• Availability of resources may be limited due to strategic priorities or funded work efforts.

6 Business Risks and Mitigation

|Business Risks |Mitigation |Category |

|The proof of concept has not been tested with a statistically |No health information will be exchanged unless a |Risk Tolerance |

|significant data set size. While the proof of concept worked |Veteran authorization is on file during the pilot | |

|well with a very small data set, there are no assurances at this |testing. | |

|point that it will work with a much larger data set. This needs | | |

|to be accomplished to determine if it can operate with a | | |

|significant data set and maintain an acceptable error tolerance. | | |

|An Error and Risk tolerance level associated with this |Determine acceptable error and risk tolerances |Risk Tolerance |

|functionality has not been determined. |using pilot data. | |

|VAP will need to make updates to the system to remain compliant |Privacy staff will work with VAP personnel to |Privacy |

|with privacy regulations. |ensure such regulations are known and understood. | |

|If the compressed time frames used to elicit, document, and |If additional requirements are needed and |Schedule |

|demonstrate the business requirements for this BRD are followed, |determined within scope by a joint effort of | |

|then there is an inherent risk that the BRD will not capture the |business stakeholders and input from development | |

|full scope of the request. |regarding impact mitigation, a Change Request must | |

| |be submitted through the NSRD. | |

|If the Known Interfaces section is not 100% complete, then the |Ensure that this list is reviewed during |Known Interfaces |

|project may not have had all associated requirements identified. |elaboration and captured as needed within any | |

| |additional documentation – such as a Requirements | |

| |Elaboration Document (RED). | |

Appendix A References

The authority to produce the BRD, which is authored by the business community, is found in the following:

• OneVA Enterprise Architecture ETA Compliance Criteria

• Requirement Level Guide

Document References:

• Audit Trails – NIST:

• Dialog Medical iMED Consent:

• eBenefits:

• HL7 SLS Standards

[pic]

• Master Patient Index (MPI):

• NSR #20100102, NwHIN Enhancements:

• NSR #20110320, CPP/VAP Expand Capabilities to Accept an SSA

Authorization:

• NwHIN Overview, Christina Palumbo:

• Privacy Act, 5 U.S.C. 552a. THE PRIVACY ACT OF 1974, 5 U.S.C. § 552a – As Amended



• Security Service: (telecommunication)

• VA Handbook 6500 – Information Security Program



• VA NwHIN Adapter



• VONAPP II

• VHA Handbook 1605.1 – Privacy and Release of Information

• VLER Fact Sheet



Appendix B Models

VAP – Opt-In AS-IS Model

[pic]

VAP – Automatic Opt-In Restrictions

[pic]

VAP – Partner Requests Health Data - To Be

Appendix C Stakeholders, Users, and Workgroups

Stakeholders

|Type of Stakeholder |Description |Responsibilities |

|Requester |Eric Kettler |Submitted request. Submits business requirements. |

| |Project Analyst |Monitors progress of request. Contributes to BRD |

| | |development. |

|Endorser |Margaret Donahue, |Endorsed this request. Provides strategic direction to |

| |Director, Health Informatics |the program. Elicits executive support and funding. |

| | |Monitors the progress and time lines. |

|Business Owner/Program Office |Margaret Donahue, |Provides final acceptance of BRD with sign-off authority.|

| |Director, Health Informatics |Provides strategic direction to the program. Elicits |

| | |executive support and funding. Monitors the progress and|

| | |time lines. |

|Business SMEs |Todd Turner |Provide background on current system and processes. |

| |Program Analyst, Health Informatics |Describe features of current systems, including known |

| |Robert Clipper |problems. Identify features of enhancement. |

| |Program Specialist, Health Informatics | |

|Technical SMEs |Omar Bouhaddou |Provide technical background information about the |

| |Business Analyst, VLER Health |current software and requested enhancements. |

| |Stephania Griffin, | |

| |Director, Information Access & Privacy Office | |

| |Peggy Pugh | |

| |Privacy Specialist, VHA | |

| |Monique Allen | |

| |Management Analyst, VLER | |

| |Mike Davis | |

| |Security Architect, VHA | |

| |Jennifer Teal | |

| |HIM Specialist, VHA OIA/Health Information | |

| |Governance (HIG) | |

Stakeholder Support Team (BRD Development)

|Type of Stakeholder |Description |Responsibilities |

|Health Care Security |Rhonna Clark, |Responsible for determining and providing guidance on |

|Requirements SME |VHA Security Specialist, VHA OIA HIG Health Care |compliance with the HIPAA Security Rule and other health |

| |Security Requirements |care security requirements. |

|Service Coordination SME |Richard Murray. Management Analyst, OI&T |Responsible for ensuring all aspects of non-functional |

| | |requirements have been accurately recorded for this |

| | |request. |

|Requirements Analyst |Sam Bordelon |Responsible for working with all stakeholders to ensure |

| |Business Analyst, Requirements Development and |the business requirements have been accurately recorded |

| |Management |for this request. |

Appendix D Enterprise Requirements

Below is a subset of Enterprise-level Requirements that are of particular interest to the business community. These requirements MUST be addressed within each project resulting from this work effort. If OI&T cannot address these Enterprise-level requirements, the Business Owners responsible for each area MUST be engaged in any waiver discussions prior to any decisions being made. This section is not meant to be a comprehensive list of all Enterprise-level requirements that may apply to this work effort and should not preclude the technical community from reviewing all Enterprise-level requirements and identifying others that should apply to this work effort as well.

|Identifier |Requirement Type |Description |

|688477 |Security |All VA security requirements, as defined in VA Handbook 6500, shall be followed. To assist BRD |

| | |development, the Security Requirements Steering Committee (SRSC) has made available an |

| | |authoritative extract of those requirements. |

| | |All National Institute of Standards and Technology (NIST) SP 800-53 security control family |

| | |requirements shall be followed. An extract of VA cross-cutting enterprise security and privacy |

| | |requirements (categorized by current NIST SP 800-53 security control families) is available from|

| | |the VA SRSC. |

| | |Based on Federal Information Processing Standard 199 and NIST SP 800 60, the recommended |

| | |Security Categorization is High. The Security Categorization will drive the initial set of |

| | |minimal security controls required for the information system. Minimum security control |

| | |requirements are addressed in NIST SP 800-53 and VA Handbook 6500. |

|463749 |Performance Measurement |Make the performance measurements available to the Information Technology (IT) Performance |

| |Availability |Dashboard to enable display of “actual” system metrics to customers and IT staff. |

|413869 |Security and Privacy |All VA security requirements as defined in VA Handbook 6500 shall be followed. To assist BRD |

| | |development, the Security Requirements Steering Committee (SRSC) has made available an |

| | |authoritative extract of those requirements. |

|413867 |Security and Privacy |All NIST SP 800-53 security control family requirements shall be followed. An extract of VA |

| | |cross-cutting enterprise security and privacy requirements (categorized by current NIST SP |

| | |800-53 security control families) is available from the VA SRSC. |

|432211 |Security and Privacy |Relevant HIPAA security and privacy requirements shall be followed. An extract of HIPAA |

| | |requirements is available from the VA SRSC. An extract of HIPAA security requirements to be |

| | |implemented in health care-related projects is available from the Veterans Health Administration|

| | |(VHA) Health Care Security Requirements. |

|413839 |Security and Privacy |Provide data sensitivity and segmentation support for Health Level 7 (HL7) Version 3 Standard: |

| | |Privacy, Access, and Security Service; Release 1, Section 6.1.1, table 5: Data Segmentation |

| | |Business Requirements. |

|413859 |Privacy (Standard) |All VA Privacy requirements will be adhered to. Efforts that involve the collection and |

| | |maintenance of individually identifiable information must be covered by a Privacy Act system of |

| | |records notice. |

|590347 |User Access to Sensitive |Commercial software must provide a mechanism for collecting and reporting user access to |

| |Records |sensitive records that conforms to data standards (such as HL7) to support patient privacy and |

| | |security requirements related to unauthorized patient access. |

|413868 |508 Compliance (Standard) |All Section 508 requirements will be adhered to. Compliance with Section 508 will be determined|

| | |by fully meeting the applicable requirements as set forth in the VHA Section 508 checklists |

| | |(1194.21, 1194.22, 1194.24, 1194.31 and 1194.41) located at: |

| | | or as otherwise specified. Checkpoints will be|

| | |established to ensure that accessibility is incorporated from the earliest possible design or |

| | |acquisition phase and successfully implemented throughout the project. |

|413836 |Executive Order (Standard) |All executive order requirements will be adhered to. |

|413850 |Identity Management |All Enterprise Identity Management requirements will be adhered to. These requirements are |

| |(Standard) |applicable to any application that adds, updates, or performs lookups on persons. |

|413843 |Identity Services |All Enterprise Identity Management requirements will be followed. These requirements are |

| | |applicable to any application that adds, updates, or performs lookups on persons. |

| | |For specific guidance refer to the Identity Services BRD |

| | | |

| | |Adherence to the guidance provided in these documents ensures compliance with NIST Access |

| | |management policies as well as Federal Identity, Credential, and Access Management (FICAM) |

| | |Guidance. |

|413848 |Identity and Access |All Enterprise Identity and Access Control requirements will be followed. These requirements |

| |Management |are applicable to any application that uses or manages identity information, and/or requires |

| | |control of user access at any level. |

| | |For specific guidance refer to the Enterprise Identity and Access Management BRD |

| | |(

| | |gnedOfficial%20Documents/Forms/AllItems.aspx). Adherence to the guidance provided in these |

| | |documents ensures compliance with NIST Access management policies as well as FICAM Guidance. |

|628952 |Terminology Services |Adopt nationally accepted administrative and clinical standard vocabulary code set |

| |(Standard) |specifications for representing data elements to achieve clinical health information |

| | |interoperability including but not limited to the Systemized Nomenclature of Medicine Clinical |

| | |Terms, Logical Observation Identifiers, Names, and Codes, and RxNorm. |

|628953 |Terminology Services |Conform to nationally accepted content exchange standards that specify the structure and |

| |(Standard) |semantics for the purpose of electronic health information exchange including but not limited to|

| | |Health Level 7 2.x, Consolidated Clinical Document Architecture, Fast Healthcare |

| | |Interoperability Resources, National Council for Prescription Drug Programs Script or Digital |

| | |Imaging and Communications in Medicine. |

|628954 |Terminology Services |Comply with nationally accepted transport standards and implementation specifications for |

| |(Standard) |exchanging structured information including but not limited to Hypertext Transfer Protocol in |

| | |support of RESTful approaches and Simple Object Access Protocols. |

|628955 |Terminology Services |Adhere to the VA Enterprise Terminology Service guidelines for all data and terminology |

| |(Standard) |standardization efforts. |

|628956 |Terminology Services |Adhere to the specifications of the VA Enterprise Terminology Service informatics architecture |

| |(Standard) |to store nationally accepted standard vocabularies identifiers such as Concept ID and |

| | |Designation IDs or one or more Universally Unique Identifiers. |

|628957 |Terminology Services |Adhere to the specification of the VA Enterprise Terminology Service informatics architecture |

| |(Standard) |for internal VA consumers to receive nationally accepted standard vocabularies identifiers and |

| | |is not limited to Concept ID, Designation ID, or Universal Unique Identifiers. |

|411351 |HIPAA |Computer systems shall track accounting of disclosure information when the system is accessed by|

| | |a non-VA user. |

|411346 |HIPAA |Computer systems shall allow for the correction or amendment of any piece of individually |

| | |identifiable information. |

|411347 |Interoperability |The system shall be compliant with the interoperability standards, specifications, and |

| | |certification criteria issued by the U.S. Department of Health and Human Services (HHS). |

|411345 |EHR Certification / |The Electronic Health Record (EHR) shall be certified and be compliant with the standards, |

| |Meaningful Use |specifications, and certification criteria issued by HHS and maintain that certification |

| | |throughout its lifecycle. EHR Certification includes Meaningful Use (MU) requirements. The EHR|

| | |shall adhere to all MU Objectives and Standards for Eligible Providers and Eligible Hospitals |

| | |(42 CFR 495.6(d)-(g)) as published or modified through the Office of the National Coordinator |

| | |from the Health Information Technology (HIT) Policy and HIT Standards Committees, as well as |

| | |Certification Criteria (45 CFR 170.302, 170.304, &170.306) and Standards (45 CFR 170.205, |

| | |170.207, & 170.210). |

|411348 |Patient Driven Care and |The system shall have the capability of incorporating patient self-entered data in order to |

| |Care Coordination |provide context-specific care. This may include results of home monitoring and patient-reported|

| | |functional outcomes (e.g., Veterans RAND 12-Item Health Survey, Functional Independence |

| | |Measurement, Patient Health Questionnaire-9, Patient Reported Outcomes Measurement Information |

| | |System, etc.) provided as structured documents that use structured encoded data elements. The |

| | |system shall support self-entered data by authenticated patients and clearly identify this as |

| | |patient-entered data so that providers may consider this in their review and interpretation. |

| | |Authenticated and labeled self-entered data will be available across applications. The system |

| | |must capture in standard format (e.g., HL7 Clinical Document Architecture) the plan of care |

| | |(including individualized treatment considerations and goals) which will be shared with the |

| | |patient and members of the treatment team. The system shall generate a summary record that |

| | |meets MU standards. The system shall have the capability to generate, at all user-defined |

| | |levels, a list and summary of all patients meeting defined criteria (e.g., diagnosis of |

| | |diabetes), for purposes of panel management and care coordination. The system shall be |

| | |compliant with and support the criteria of the National Committee for Quality Assurance for |

| | |Patient Centered Medical Home, Level 3 recognition program. |

|411350 |Cognitive Support / |The system shall provide ready access to cognitive support, knowledge management, and Clinical |

| |Knowledge Management / |Decision Support (CDS) tools that will prompt the user in context-sensitive ways that are |

| |Clinical Decision Support |appropriate for the patient, provider, and health care setting. CDS tools will leverage such |

| |(for CDS requests only) |resources as VA-Department of Defense evidence based practice guidelines, appropriateness |

| | |criteria, treatment algorithms and clinical protocol/pathways, drug and disease reference |

| | |information sources, risk and similar mathematical calculators, and other tools and resources |

| | |that will be defined in the future. CDS systems will support clinical practice that is |

| | |concordant with evidence-based guidelines where appropriate, while capturing exceptions within |

| | |the individualized patient care plan. CDS systems should be designed with workflow, patient |

| | |safety, and patient-centered care in mind. CDS will be utilized in a manner consistent with |

| | |usability criteria in section 8.3.9 and provide CDS at key points within the clinical workflow |

| | |without causing hindrance. Cognitive support for health care professionals and patients will be|

| | |model-driven and will help end-users place the data into context in ways that make clinical |

| | |sense for that patient and support shared decision-making between patient and clinician. CDS |

| | |tools will build on model-driven cognitive support to integrate patient-specific data and |

| | |evidence-based practice guidelines and research results into daily practice. Cognitive support |

| | |shall provide relevant information to prevent defined clinical errors and function to address |

| | |patient safety, improved quality, improve efficiencies, and enable cost reductions. The system |

| | |shall facilitate the users’ ability to do what is “right” and make it difficult to make errors |

| | |in the provision of best practice health care. To that end, the system shall rely on |

| | |Guidance-Based methods and provide recommendations based on Clinical Practice |

| | |Guidelines/Diagnosis/Standard treatment options, but avoid interfering with patient treatment |

| | |decisions. The system shall provide guidance tailored to be as specific as possible to the |

| | |patient being treated utilizing patient-specific data (e.g., relevant labs, the problem list, |

| | |relevant medications, antimicrobial profiles, and context-specific diagnostic and treatment |

| | |recommendations). The CDS system will allow multiple capabilities to access the same CDS |

| | |widgets. Each CDS widget will access a centralized CDS database. It is important that there is|

| | |flexibility in the CDS capability in order to stimulate innovation and include emerging |

| | |capabilities (e.g., predictive modeling, text mining, population and public health |

| | |considerations, and mobile tools for remote activity monitoring) and data integration. |

|411349 |Business Intelligence / |The system requires the capability to generate aggregate reports as needed (e.g., MU Quality |

| |Analytics |Measures, quality monitoring, performance accountability, research initiatives, etc.), with the |

| | |ability to strip personally identifying information. Structured clinical data will be collected|

| | |according to recognized standards within MU (Systemized Nomenclature of Medicine, LOINC, RxNorm,|

| | |etc.). The system requires a variety of reporting tools (e.g., patient-centric, |

| | |facility-centric, region/service-centric, enterprise-level, and population-based, etc.). These |

| | |reporting tools shall be relevant, adaptable, and easily used by the end-user. The reports |

| | |generated and their associated data shall also be easily exportable. The system requires the |

| | |capability to identify, track, and report aggregate performance stratified by key patient |

| | |characteristics such as gender, race/ethnicity, Benefit Category, diagnostic categories (e.g., |

| | |mental illness diagnoses, etc.) and other factors, in order to track health disparities and |

| | |address the needs of vulnerable populations. System tools may include predictive modeling. It |

| | |is imperative that impact on workflow (both system performance and health care team processes |

| | |and outcomes) is tracked when modifications are made to the system. |

|520049 |Infrastructure |The system shall be capable of capturing, storing, and rendering multidivisional facility |

| | |information. |

Appendix E Non-Functional Requirements

Functional requirements describe what a system must be able to perform—that is, the system behavior. All other requirements are non-functional. This section describes the non-functional requirements from a business need perspective.

|Identifier |Brief Name |Non-Functional Requirements Category |

| | |Operational Environment Requirements |

|429605 |System Response Times |System response times and page load times shall be the same or better than the current |

| | |system. |

|429606 |System Maintenance |Maintenance, including maintenance of externally developed software incorporated into the |

| | |application(s), shall be scheduled during off peak hours or in conjunction with relevant |

| | |maintenance schedules. The business owner should provide specific requirements for |

| | |establishing system maintenance windows when planned service disruptions can occur in support|

| | |of periodic maintenance. |

|390684 |Operational Environment - |Information about response time degradation resulting from unscheduled system outages and |

| |Response Time Degradation |other events that degrade system functionality and/or performance shall be disseminated to |

| | |the user community within 30 minutes of the occurrence. The notification shall include the |

| | |information described in the current Automated Notification Reporting (ANR) template |

| | |maintained by the VA Service Desk. The specific business impact must be noted in order for |

| | |OI&T to provide accurate data in the service impact notice of the ANR. |

|390673 |Operational Environment - |Provide a real-time monitoring solution to report agreed/identified critical system |

| |Real-Time Monitoring |performance parameters. |

|391896 |Critical Business Performance|Critical business performance parameters shall be identified e.g., transaction speed, |

| |Parameters |response time for screen display/refresh, data retrieval, etc. in a manner that data capture |

| | |can occur to support metric reporting and support the OI&T performance dashboard display. If|

| | |no such performance metrics are required or provided there will be no program specific |

| | |Service Level Agreements (SLA) created, nor shall there be any active/real time monitoring |

| | |through OI&T Performance Dashboard to provide the business owners any performance metrics. |

|390678 |Operational Environment - |Notification of scheduled maintenance periods that require the service to be offline or that |

| |Notification of Scheduled |may degrade system performance shall be disseminated to the business user community a minimum|

| |Maintenance |of 48 hours prior to the scheduled event. |

| | |Documentation Requirements |

|429609 |Training Curriculum |The training curriculum provided by the applicable Program Office shall state the expected |

| | |training and task completions time(s) for primary users and secondary users to become |

| | |proficient at using any IT application or system that is enhanced or created as a result of |

| | |this NSR. |

|429610 |Training Curricula_User |All training curricula, user manuals, and other training tools, shall be developed and/or |

| |Manuals_Training Tools |updated by the applicable Program Office(s) and delivered to all levels of users prior to |

| | |release of any IT application or system that is enhanced or created as a result of this NSR. |

| | |The curricula shall also reflect necessary updates to business processes and procedures that |

| | |are changed as a result of this NSR. |

|392051 |Documentation for System |IT will provide the level of documentation required to support the system and maintain |

| |Support |operations and continuity. Documentation shall represent minimal programmatic and lifecycle |

| | |operations support documentation artifacts as defined by VA standards in ProPath and as |

| | |required by the VA Enterprise System Engineering Lifecycle and Release Management office for |

| | |sustained operations, maintenance, and support |

| | |() prior to approval by any VA change control |

| | |board and release into production. |

| | |Implementation Requirements |

|429612 |Technical Help Desk Support |Technical Help Desk support for the application shall be provided for users to obtain |

| | |assistance. |

|390674 |Implementation - Comply With |The IT solution shall be designed to comply with the applicable approved Enterprise SLA. |

| |Approved Enterprise SLAs | |

|429613 |Implementation Complete |The implementation must be completed by timeframes agreed upon by both the Business Owner and|

| | |OI&T. |

| | |Data Protection/Back-up/Archive Requirements |

|392156 |Back-up and Data Recovery |Based upon the criticality of the system, provide a back-up and data recovery process for |

| | |when the system is brought off-line for maintenance or technical issues/problems. |

|431707 |Data protection measures - |Data protection measures, such as back-up intervals and redundancy shall be consistent with |

| |Mission Critical |systems categorized as mission critical (12 hour restoration). |

| | |Data Quality/Assurance Requirements |

|391305 |Monitoring Process Ensuring |A monitoring process shall be provided to ensure that data is accurate and up-to-date and |

| |Data Accuracy |provides accurate alerts for malfunctions while minimizing false alarms. |

| | |User Access/Security Requirements |

|390698 |User Access/Security - |Ensure the proposed solution meets all VHA Security, Privacy, and Identity Management |

| |Security, Privacy, and |requirements including VA Handbook 6500 (see the Enterprise Requirements section of the BRD).|

| |Identity Management | |

| | |Usability/User Interface Requirements |

|392110 |User Interface/User Centered |Adhere to good User Interface/User Centered Design (UI/UCD) principles as outlined in the |

| |Design |User Interface/User Centered Design Principles Appendix of the BRD. |

| | |Conceptual Integrity |

|392052 |Conceptual Integrity |Provide standards based messaging and middleware infrastructure needed to support future |

| | |deployments. |

| | |Availability |

|392024 |Availability Maintenance |Maintenance window, including maintenance of externally developed software incorporated into |

| |Window |the application(s), will be by mutual agreement between OI&T and the VHA Point of Contact for|

| | |the affected facility(ies). VHA will provide POCs for each facility. |

|392338 |Unavailability |Application unavailability due to an unplanned outage or planned outages that exceed the |

| | |defined maintenance window will not exceed 8.76 hours per year and will not exceed 43.8 |

| | |minutes per month (99.9% availability). |

|392336 |Availability |The application shall be available 24 hours a day, seven days a week, with an uptime of |

| | |99.9%. |

|392335 |System Updates and Scheduled |All system updates and scheduled maintenance should occur between the hours of 1800 and 0600 |

| |Maintenance |(per local time), when clinical usage would be lightest. |

| | |Interoperability |

|392343 |HL7 |The system shall support all recognized health system standards i.e., HL7, Fast Healthcare |

| | |Interoperability Resources (). |

|392346 |Heterogeneous and Agnostic |Systems must be heterogeneous and agnostic for operating systems and code bases. |

|392345 |Transfer Large Files |Provide the ability to securely transfer large files (of 4-8 gigabyte) from an external |

| | |source to VA systems. |

|392350 |Remote Access |Provide access to the system over a remote access solution, maintaining normal baseline |

| | |performance. |

| | |Manageability |

|392352 |Service Desk/Incident |Provide Service Desk/Incident and Problem Management tracking related to maintenance events |

| | |of patient care systems with priority over non-patient care systems. |

|392344 |Maintenance Events |Provide data related to maintenance events, both routine and exceptional, including key |

| | |metadata: |

| | |Predicted routine work |

| | |Occurrences where maintenance is completed, including restart from down time |

| | |Identity of the organization performing maintenance |

| | |User performing maintenance (if available) |

| | |Identity of the system |

| | |Date/time, physical location |

| | |Systems impacted |

| | |Does it affect patient care |

| | |Non-urgent or emergent |

|392355 |Audit Capabilities |Provide audit capabilities for system access and usage with settings that are configurable to|

| | |support internal and external audits based on federal and VHA mandates. |

|392362 |VA Directive 6300 |The system must comply with VA Directive 6300 Records and Information Management and with VHA|

| | |Records Control Schedule 10-1, in general and specifically with Electronic Final Version of |

| | |Health Record: Destroy/Delete 75 years after last episode of patient care, or longer (if |

| | |specified). |

| | |Performance |

|392347 |Infobutton Query Responder |Provide an Infobutton Query Responder on all platforms with a response time of less than .5 |

| | |seconds. |

|392351 |Manage Lost Data |The system shall recognize, report, and retransmit lost data, with less than 0-1% chance of |

| | |incomplete patient records. |

|392348 |Data Return .5 seconds |Provide patient data (for data within the system) transactions (e.g., capture, search, |

| | |request for data) within .5 seconds. |

|392349 |User Interface Controls |Mouse or key-based UI controls, e.g., menus, checkboxes shall provide instantaneous |

| | |responsiveness ( ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download