U.S Department of Veterans Affair

New Mobile Apps: Compliance and Deployment


This content is no longer current.
Visit the new Developing VA Apps home page for updated processes and requirements for building your VA App

Developing a New mobile application for use by Veterans that will be supplied, supported, and reviewed for compliance by VA requires the following process:

  1. The product owner that wishes to sponsor a new mobile application is required to present this information to Web and Mobile Solutions (WMS) by submitting a Mobile Applications Registration Profile in the initiation section of this website at (http://mobilehealth.va.gov/initiation), which includes:
    1. A name for the App.
    2. The business case for allocating VA resources to the App. The business case should clearly identify the audience and purpose of the App.
    3. The clinical value of the App.
    4. The cost savings to be gleaned from the use of the App, if any.
    5. The cost to develop the App, including the costs to have the App reviewd for compliance and deployed in VA’s Mobile Applications Environment (MAE).
    6. The platforms and operating systems for which the App will be developed.
    7. The sustainment plan for the App (e.g., how it is to be maintained, the annual cost of maintenance and support). A minimum of two years maintenance and support are required for each new mobile application.
    8. Requirements for usability testing and/or pilot testing.
    9. Metrics required to evaluate product effectiveness.
    10. Training requirements.
    11. Help Desk requirements.
    12. Stand-up requirements for a test system and a production system.
    13. The compliance reviews required by the VA’s CBs. NOTE: CBs refer to the following groups and departments in the Veterans Health Administration (VHA) and the VA Office of Information Technology (OIT):
      1. Usability Testing (OIA)
      2. User Interface (OIA)
      3. VA Branding (OPIA)
      4. Data and Terminology Standards Compliance (OIA)
      5. Security (OIT)
      6. Privacy (OIA)
      7. Patient Safety Assessment (OIA)
      8. 508 Accessibility (OIT)
      9. Application and Data Security
      10. Independent Validation and Verification (IVV) performed by OIT
      11. System Performance Impact Assessment (ESE) for Class 3 and Class 4 Apps.
      12. Training Strategy
      13. Help Desk (OIT)
      14. Product Effectiveness
      15. PMAS documentation (verified by OIT)
  2. WMS will register the App as a Project in the Mobile Applications Inventory System (JIRA) and record all relevant artifacts provided by the product owner. WMS will ensure that all required information is received and loaded into JIRA. WMS will alert the VA Mobile Applications Governance Board (MAGB) that the App is ready for review. Upon review by the MAGB, a decision is made whether to develop and/or certify the App.
    1. If approved, the product owner may proceed to contract with the vendor or schedule internal VHA technical resources, as determined by the MAGB.
      1. The product owner will proceed to step 3.
      2. WMS will advise the affected CBs that the App has been approved, and will specify their expected responsibilities and timeframes.
      3. A VA Project Manager will be assigned to the development project.
    2. If denied, the product owner will be notified by the WMS with appropriate justification for the denial. The product owner may appeal the decision by applying to the MAGB and presenting its grounds for an appeal.
  3. The product owner will contract with the designated development resources (internal or external as determined by the MAGB and VA’s Contracting Office), including the following in its Performance Work Statement (PWS):
    1. The clinical or product requirements for the App.
    2. The cost to develop the App and support a pilot operation for three to six months.
    3. The cost for annual support and maintenance for two years.
    4. If developed using the Agile methodology and the Scrum framework, the developer is required to include VA CBs in Scrum teams and Scrum reviews, when appropriate.
    5. Maintain a bi-weekly update to the JIRA system with App development and compliance review status.
    6. The requirements and process to achieve the Authority to Operate (ATO) in the MAE, as provided by OIT.
    7. Enable WMS to approve the PWS before it is issued to the developer.
  4. The developer will build the system using the agreed upon SDLC, including the required CBs and VA operating departments (e.g., Training, Help Desk and Product Effectiveness) during the development process, as shown in the Compliance Review Table.
    1. For Applications developed using Agile/Scrum, CBs will be included in Sprint reviews.
      1. The Scrum Master may request that a CB representative be included on the development team, especially while screens and process flows are in development.
      2. CBs may request the product owner to include specific requirements in the product backlog.
    2. The App must adhere to each individual CB’s requirements in order to pass the CB review. A passing result is required for the App in order to request review for compliance by OIT.
    3. The VA Project Manager, CBs and developers will work together to reach a successful outcome of PASS for the application. Product owners are responsible for mitigating all objections raised by CBs.
    4. Software Quality Assurance is the responsibility of the development team. Apps must be fully tested and operational prior to requesting OIT Compliance.
    5. Complete the Project Management Accountability System (PMAS) required documentation:
      1. Required Artifacts.
        1. SDD Addendum for each Mobile App (or grouping of related Mobile Apps).
        2. RSD/ARD Addendum for each Mobile App (or grouping of related Mobile Apps) .
        3. Requirements Traceability Matrix.
        4. IOC/Pre-production Test Results (Defect Log)(if applicable).
        5. User Guide (unique for each app.
        6. Test Team/Independent Verification Intake Form.
      2. Additional Artifacts – Provide Content Changes.
        1. SDD – Overarching program level document for MAE, VAMF, Health Adapter (i.e. Code, Components, Architecture used by many and/or all mobile apps).
        2. RSD – Overarching program level document for Non- functional requirements common to all mobile apps.
        3. Version Description Document.
  5. The VA Project Manager is responsible for:
    1. Updating the JIRA database on a regular basis from reports provided by the product owners and the CBs containing the development status, compliance review status, certification status, and related artifacts.
    2. Initiating OIT Certification and release into production by submitting the IV&V Intake form to the Mobile Health External Development (MHED) team, along with all required PMAS documentation.
    3. Coordinating with VA resources to update the appropriate website (internal or external) with deployment information.
  6. WMS will:
    1. Provide bi-weekly summary reports of the Mobile Application inventory to the MAGB identifying the following:
      1. App in development.
      2. App submitted for compliance reviews.
      3. Apps submitted for OIT certification.
      4. Apps behind schedule or in disagreement with CBs, along with an explanation.
      5. Apps approved and deployed for pilot or general release.
      6. Apps in operation organization-wide.
      7. Apps operating issues (Help Desk Report).
    2. Maintain the Mobile Applications Registration Profile information, including additions and changes.
    3. Maintain the database of CB requirements.
    4. Manage each App as it follows the OIT certification process.
    5. Work with the product owner to implement a deployment plan specifically created for the App by the owner and the WMS.
  7. If the VA Mobile Applications Governance Board determined that a pilot is required, then a pilot project will be established by the WMS.
  8. Upon deployment, the Sustainment Plan will come into effect.
  9. Product Effectiveness will extract the metrics that have been established for the product and report their finding to the MAGB monthly.