Presentation for TIAG Open Source VistA Custodian Agent

1

2

Session OutlineDefinitionsMotivationsHow we got to this pointHow can a product be a candidate?A product is selected – now what?Expectations – what contributor must commit

toExisting initiatives - what we have learnedAdditional resources/referencesQuestions

3

DefinitionsClass I Software

Prioritized to meet business goals of VHARequirements established by group of Subject

Matter Experts (SMEs)Developed by PD

In house, via contract, or combinationMeets all technical standardsHas undergone rigorous quality assuranceCarries documentationSupported 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 environmentThis 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 VistAWireless applications that use VistA data – e.g., Bar Code

ExpansionM-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 CollaborationField 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

Current Joint Approach

9

The Program – High Level View1. Field submits products as candidates2. VHA assesses and selects Class III

products for the program and notifies OIT3. OIT conducts a Technical Assessment

Briefing4. Field Developer makes necessary changes5. OIT conducts quality assurance checks6. OIT manages field test7. 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 linkhttp://vista.med.va.gov/pas/

ITServiceRequest.htmCritical considerations:

Must be functionally stable (no scope creep!)Must be in production useMust complete/submit appropriate forms

(Software Submission Form and Technical Assessment Form)

Must be willing to commit to the process

11

Step 2: VHA Review/SelectionProduct must satisfy VHA business needProduct must be operational, not just an idea

or incompleteProduct should not be in “competition” with

existing or emerging VistA functionalityPrioritized by Health Information Systems

Executive Boards (HISEBs) Final selection done by IDMCApproved by Under Secretary for HealthCriteria continues to be refined based on

experience

12

Step 3: OI&T Technical AssessmentPD assigns a Project Manager to each Class

III initiativePD 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 documentedPlan is developed to resolve issues

13

What are technical issues?Adherence to published Standards and ConventionsRun-time environment is acceptable (e.g., use of

tools other than M or Delphi)Compliance with Section 508Compliance with Security and Privacy requirementsDocumentation exists that fully supports long term

support of the productPerformance characteristics are documentedImpacts on system infrastructure are evaluatedTraining and Implementation impacts understood

and resources availableProcurements and licensing are documented and

funds are availableWhatever else we uncover…

14

Step 4: Field Developer(s) make changes

Only approved changes are madeProduct 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 workVHA 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 checkAdherence to standards, Section 508, Security,

Privacy, etc.Review for Integration Agreements, guiding

field developer(s) on such requestsDocumentation review for completeness and

accuracy

16

Step 6: Field TestAt this point, the product is under the full

configuration management control of OEDOED will secure formal test agreements

for production testingIncludes formal MOUs detailing expectations

of test sitesField developer(s) must respond promptly

to any issues that arise during testEIE 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 packageTraining and Implementation activities (if

needed) will be ready for activationHealth Product Support (HPS) will announce

release of the productField 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 InitiativesShift Handoff Tool – CPRS/VistA based - Supports

standardization of the physician handoff processMedication 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 InitiativesMethicillin 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 workingEach effort highlights areas for

refinement – none of serious natureIdentifying areas where technical resources

had to be strengthened (e.g., Section 508)Some products are taking over-long to

remediateLearning how Field, VHA and OIT can do

betterContinue to tune the process accordingly

23

Additional Resources & References

Web page for Field DevelopmentProgramming 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/