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