Overview of Class 3 to Class 1 Program

1. Overview of Class 3 to Class 1 Program Presentation for TIAG Open Source VistA Custodian Agent

2. Session Outline • Definitions • Motivations • How we got to this point • How can a product be a candidate? • A product is selected – now what? • Expectations – what contributor must commit to • Existing initiatives - what we have learned • Additional resources/references • Questions

3. Definitions • Class I Software • Prioritized to meet business goals of VHA • Requirements established by group of Subject Matter Experts (SMEs) • Developed by PD • In house, via contract, or combination • Meets all technical standards • Has undergone rigorous quality assurance • Carries documentation • Supported at enterprise level by OIT

4. More Definition… • Class III Software – historical perspective • Development done by entities other than PD • Not necessarily compliant with national development standards • Products not covered by national Tier 2 or Tier 3 support • Historically focused on local need • May result in solutions that are unique to local business practices • Typically does not support enterprise business practices • Often shared among VA medical centers • Some products are very widely used even though they did not compliant with national standards or business practices

5. More Definition… • Class III software encompasses any software that invokes or impacts a production VistA environment • This includes: • MUMPS code, DELPHI code, VA FileMan Data Dictionaries, M globals, Caché server pages, Caché objects, VistA constructs (Option file, Remote Procedure Calls (RPCs), device definitions, HL7 messages, etc. • External applications that invoke Class I RPCs or APIs • Interfaces to Vendor products (COTS) that access data in VistA or report data to VistA • Wireless applications that use VistA data – e.g., Bar Code Expansion • M-based COTS that reside within VistA (e.g., Dental Record Manager) • Extracts from VistA systems (using either M or VA FileMan methods to support web sites, warehouses, national reports, Austin databases, etc.) • Imbedded products within GUI applications or that may be invoked by M code

6. Motivations – why create this program? • Leverage the value inherent in Class III development • High end-user acceptance • Relevant to high-priority needs • Highly responsive to changing requirements • Possible short development cycle and “time to market” • Most Class III solutions are small and thus pose less technical risk • Less cost risk in small software initiatives • Possible migration pathway to agile software management (rapid application development) • Manage the Class III development and deployment process • For VHA-wide benefit • Promote standardization and uniformity of quality for health care services • Ensure our systems are secure and performing at peak levels • Document customer requirements and analysis for business unit needs as well as security implications and solutions • Perform technical evaluation for systems integration and operational performance • Outcome -> Formalize Class III as an OIT and VHA asset

7. How we got to this point – History! • January 2007 – Assessment of state of Class III software – identified areas for improvement at field level • June 2007 – Established a program to identify and “elevate” Class III solutions to become Class I • October 2007 – VHA identified 3 Pilot initiatives • December 2007 – VHA added 8 additional products to the program • October 2009 – added vendor to help with assessments and remediation (KGS/dNovus) • Current – Program continuing

8. The Program – a Collaboration Current Joint Approach • Field Developers • Development of product • Write documentation • Commitment to C3>C1 Program • VHA • Business Review • Prioritization • Approval by Informatics & Data Management Committee (IDMC) • OIT/PD • Technical Review of product • Confirmation of final version to standards • National release and support

9. The Program – High Level View • Field submits products as candidates • VHA assesses and selects Class III products for the program and notifies OIT • OIT conducts a Technical Assessment Briefing • Field Developer makes necessary changes • OIT conducts quality assurance checks • OIT manages field test • OIT releases the product as Class I

10. Step 1: Can your product be a candidate? • Submit as a New Service Request (NSR) via web link • http://vista.med.va.gov/pas/ITServiceRequest.htm • Critical considerations: • Must be functionally stable (no scope creep!) • Must be in production use • Must complete/submit appropriate forms (Software Submission Form and Technical Assessment Form) • Must be willing to commit to the process

11. Step 2: VHA Review/Selection • Product must satisfy VHA business need • Product must be operational, not just an idea or incomplete • Product should not be in “competition” with existing or emerging VistA functionality • Prioritized by Health Information Systems Executive Boards (HISEBs) • Final selection done by IDMC • Approved by Under Secretary for Health • Criteria continues to be refined based on experience

12. Step 3: OI&T Technical Assessment • PD assigns a Project Manager to each Class III initiative • PD will lead a Technical Assessment Briefing with the field developer(s) • Objective is to understand the technical attributes of the product and to identify areas for remediation • Findings are documented and minutes published • Assignments are documented • Plan is developed to resolve issues

13. What are technical issues? • Adherence to published Standards and Conventions • Run-time environment is acceptable (e.g., use of tools other than M or Delphi) • Compliance with Section 508 • Compliance with Security and Privacy requirements • Documentation exists that fully supports long term support of the product • Performance characteristics are documented • Impacts on system infrastructure are evaluated • Training and Implementation impacts understood and resources available • Procurements and licensing are documented and funds are available • Whatever else we uncover…

14. Step 4: Field Developer(s) make changes • Only approved changes are made • Product must be functionally “frozen” • No scope creep, no more “neat ideas” • This is a significant culture change for field • Field Developer(s) must commit to timeline to complete the work • VHA has taken a risk that you will do the job • OIT will provide experts in areas like Section 508, Security, and Capacity Management to guide efforts • Customer (SME) may be involved as well to help resolve some issues

15. Step 5: Quality Assurance Check • PD will perform an independent QA check • Adherence to standards, Section 508, Security, Privacy, etc. • Review for Integration Agreements, guiding field developer(s) on such requests • Documentation review for completeness and accuracy

16. Step 6: Field Test • At this point, the product is under the full configuration management control of OED • OED will secure formal test agreements for production testing • Includes formal MOUs detailing expectations of test sites • Field developer(s) must respond promptly to any issues that arise during test • EIE may monitor system performance during the test; any issues may require remediation by field developer(s) • OED is authority to state that testing is complete and successful

17. Step 7: Release as Class I • PD will prepare the formal release package • Training and Implementation activities (if needed) will be ready for activation • Health Product Support (HPS) will announce release of the product • Field developer(s) are now released from the process Any new features to be added must start again at Step 1 with a new NSR

18. Completed Class III Initiatives • Shift Handoff Tool – CPRS/VistA based - Supports standardization of the physician handoff process • Medication Reconciliation – M based - Implements the ability to provide a complete list of medications to the patient on discharge from the facility • Recall Reminder – M-based - Provides a means to track and notify patients • Fee Services – COTS interfaced to VistA - Full service Fee application; Includes duplicate checking, claims scrubber, links to authorization (matched to claim), auto generated letters based on scrubber, management reports, electronic claims re-pricing, electronic claims processing, real-time claim status, fund management, and imaged medical records

19. Completed Class III Initiatives • Methicillin Resistant Staph Aureus (MRSA) – TBD - National implementation of active MRSA surveillance, including data reporting and evaluation • Suicide Hotline Phase 2 – based in VistAWeb, dotNET - Provides Suicide Prevention Hotline counselors national access to medical records and a system for Inter-facility consults; streamlines registration process for Suicide Prevention Hotline counselors, while improving workflow, case management and reporting. • Patients on Specific Drug(s) Multidivisional Enhancements – improved handling of patient medications • Immunization Documentation by BCMA –augmented bedside medication administration documentation by adding immunization data • Insurance Capture Buffer (ICB) – provided more rapid method to document patient insurance information

20. Currently Active Class III Initiatives • Patient Assessment Documentation Package (PADP) - CPRS/VistA based - Provides a standard tools for documenting assessments of patients upon admission and while the patient is in the hospital • Mobile Electronic Documentation (MED) – MS ACCESS with interface to upload to CPRS TIU templates - Allows access to health summary information from a laptop at the point of care; allows staff to document care delivered during the visit, and later upload to VistA when they have network connectivity. • Adverse Drug Event Reporting System (ADERS) – based in VistAWeb - Automates tracking, reporting and analysis of adverse drug reactions; standardizes data for reporting study trends at the national VA level and assesses probability and preventability scoring as a best practice approach for patient care

21. Currently Active Class III Initiatives • Beneficiary Travel Enhancements – enhances benefits for Veterans that must travel long distances for care; part of VA major initiative • HOWDY Lab Check-in – allows patient to self-check-in at lab using Kiosk • Medical Domain Web Services (MDWS) – provides access to VistA data for clinicians, accessing data across all VistA instances • WebHR – automates VA Human Resources actions via a web-based framework; part of VA major initiative • CAPRI DBQ – provides means to “push” templates used in document Veteran compensation and benefits exams

22. Learning from Existing Initiatives • General processes defined are working • Each effort highlights areas for refinement – none of serious nature • Identifying areas where technical resources had to be strengthened (e.g., Section 508) • Some products are taking over-long to remediate • Learning how Field, VHA and OIT can do better • Continue to tune the process accordingly

23. Additional Resources & References • Web page for Field Development • Programming standards, tools references, documentation requirements, etc. • Links to development rigor of OED (e.g., SDLCs, Testing practices, etc.) • Field Development Site: http://sds.oit.va.gov/application_support/field_development/