1 / 23

Overview of Class 3 to Class 1 Program

Overview of Class 3 to Class 1 Program. Presentation for TIAG Open Source VistA Custodian Agent. 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

cybele
Download Presentation

Overview of Class 3 to Class 1 Program

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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/

More Related