Presentation for TIAG
Open Source VistA Custodian Agent
1
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
2
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
3
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
4
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
5
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
6
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
7
The Program
–
a
Collaboration
Current Joint Approach
Field Developers
VHA
• Development of
product
• Business Review
• Prioritization
• Write
documentation
• Commitment to
C3>C1 Program
OIT/PD
• Technical Review of
product
• Confirmation of
final version to
standards
8
• National release and
support
• Approval by
Informatics & Data
Management
Committee (IDMC)
The Program – High Level View
Field submits products as candidates
2. VHA assesses and selects Class III products for
the program and notifies OIT
3. OIT conducts a Technical Assessment Briefing
4. Field Developer makes necessary changes
5. OIT conducts quality assurance checks
6. OIT manages field test
7. OIT releases the product as Class I
1.
9
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
10
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
11
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
12
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…
13
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
14
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
15
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
16
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
17
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
18
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
19
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
20
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
21
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
22
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_develop
ment/
23