Document Title:
Open-Source EHR System Architecture,
Product Definition and Roadmap
Date Submitted:
December 6, 2011
Requested Action:
Please submit suggestions for improvement at
http://www.osehra.org/node/47/content/discussions
Prepared for:
Department Of Veterans Affairs and
OSEHR Open Source Community
Technical Lead:
Dr. Stephen P. Hufnagel PhD
OSEHRA Architecture Work Group
Virginia Tech, Arlington Innovation Center
900 N Glebe Rd
Arlington, VA
HufnagelS@OSEHRA.org
703-575-7912
Preface
In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates agreed
on a common EHR technical architecture, data and services and exchange standards for the
joint EHR system (aka iEHR), where the joint EHR will include both proprietary and open source
software. The secretaries of the Veterans Affairs and Defense Departments met on May 2 and
June 30, 2011 to determine their next steps toward developing a single electronic health record,
for the two agencies.
“VA is developing an open source track to modernize VistA and will incorporate the
approach in the joint EHR", Shinseki said. “One of my objectives is to have minimal disruption
in the hospitals as we evolve from VistA to the joint EHR system What I think you will see us do
is replace modules, do incremental upgrades.” … “In five or 10 years, there may not be one line
of code left from VistA. And in my ideal world, the users will have no idea that I have made any
changes,” VA Secretary Eric Shinseki said.
“Our goals are to bring in as many private sector modules as possible and selecting the
same thing to run between VA and DOD so that we end up with a single, common electronic
health record system,” Roger Baker, VA CIO said. OSEHRA sees private modules including
both open source or commercial; OSEHRA intends to foster innovation at the module level and
encourages Darwinian selection among competing modules based on cost, performance and
support preferences.
"We planned, as part of this EHR framework, to release all the documents, architecture, all
these things. It will no longer be, 'you figure it out, you tell us a solution,'" said Col. Hon Pak, the
Army medical department's chief information officer. "The open-source custodial agent, largely
a VA-led effort but we also participate, really gives you an opportunity in ways that we've never
had before." … "Having that venue now equalizes the playing ground so that small, innovative
organizations can come and help us figure things out." said Pak. Opening the door to nimble,
innovative technologies is a core focus for Pak, who said “DoD is looking for more modular
capabilities.” All the services "have pretty much bet the farm" that patient-centered medical
home will change healthcare, but he said they need the right tools to get there. "This idea
around [health information exchange], telehealth, mobile health, patient-centered medical home
are really going to be the necessary ingredients that have to be formulated to drive some of the
transformation," Col. Pak said.
“Prompted by President Obama’s push for medical facilities to adopt electronic records,
hospitals may pay companies to modify the open-source code likely to power the governmentdeveloped system, rather than buying commercial systems”, said Ed Meagher, former Veterans
Affairs deputy chief information officer.
OSEHRA’s System Architecture, Product Definition and Roadmap documents the
journey to implement the vision expressed above.
Open Source Electronic Health Record Custodial Agent
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap
Page ii
Revision History



17 Sep 11 – 2011 Initial Baseline: OSEHR System Architecture, Product Definition & Roadmap

6 Dec 11 – Section 2 Product Definition and Roadmap and Section 3 System Architecture verified.
28 Sep 11 – Add “Section 1.5 Anacronyms” and “Section 2.2 VistA Subsystems”
30 Oct 11 – Updated undocumented modules after getting clarification from VA during weekly OSEHRA
Architecture Work Group. Updated package dependencies with continuation of QA process.
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap
Page iii
Open Source EHR (OSEHR) System Architecture,
Product Definition and Roadmap
Table of Contents
1
INTRODUCTION
9
1.1
Executive Summary
9
1.2
Architecture Working Group
10
1.3
References
11
1.4 Contract Deliverables
1.4.1
System Architecture Approach (Task 5.9)
1.4.2
Product Definition Approach (Task 5.11)
13
13
13
1.5
15
Acronyms
1.6 Legend, Meta-Model and Glossary
1.6.1
Color Conventions for System Architecture Model
1.6.2
Glossary for System Architecture Model Elements and Constructs
2
PRODUCT DEFINITION AND ROADMAP
2.1 OSEHR Components
2.1.1
Clinical
2.1.2
Infrastructure
2.1.3
Financial-Administrative
2.1.4
HealtheVet
18
18
19
23
24
27
28
28
28
2.2 VistA Subsystems
2.2.1
Vista 1.0
2.2.2
Vista 1.5 (aka HealtheVet)
2.2.3
Master Patient Index (MPI)
2.2.4
Health Eligibility Center (HEC)
2.2.5
External Entities
2.2.6
DoD Information Sharing
2.2.7
Corporate Databases
2.2.8
Centralized Data Repositories
2.2.9
Health Data Repository (HDR)
2.2.10
Corporate Data Warehouse (CDW)
2-1
2-1
2-4
2-7
2-11
2-14
2-16
2-19
2-21
2-23
2-34
2.3 GT.M Subsystems
2.3.1
GT.M Language Subsystem
2.3.2
GT.M Database Subsystem
2.3.3
GT.M Tools and Utility Subsystem
2.3.4
GT.M-LINUX Operating System
2.3.5
Other (Optional) GT.M/LINUX Components
2-35
2-36
2-36
2-37
2-38
2-39
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap
Page iv
2.4 Caché Subsystems
2.4.1
Caché Development Environment
2.4.2
Caché Database Subsystem
2.4.3
Caché Tools and Utilities Subsystem
2.4.4
Caché-Windows Operating System
2.4.5
Other (Optional) Caché/Windows Components
2-39
2-39
2-40
2-40
2-41
2-42
2.5 Product Roadmap
2.5.1
2011 System Architecture (Conceptual View)
2.5.2
Future-State Architecture (Conceptual View)
2.5.3
Plan of Actions and Milestones (POA&M)
2-42
2-43
2-44
2-46
3
SYSTEM ARCHITECTURE (SA)
3.1 Clinical
3.1.1
ADT-Admission, Discharge, Transfer/Registration
3.1.2
Ambulatory Care Reporting
3.1.3
AMT-Anticoagulation Management Tool
3.1.4
ASCD-Automated Service Connected Designation
3.1.5
Beneficiary Travel
3.1.6
Blind Rehabilitation
3.1.7
Care Management
3.1.8
Clinical Case Registries
3.1.9
Clinical Procedures
3.1.10
CHDR-Clinical/ Health Data Repository
3.1.11
CPRS-Computerized Patient Record System
3.1.12
CPRS: ART-Adverse Reaction Tracking
3.1.13
CPRS: ASU-Authorization Subscription Utility
3.1.14
CPRS: Clinical Reminders
3.1.15
CPRS: Consult/ Request Tracking
3.1.16
CPRS: Health Summary
3.1.17
Electronic Wait List
3.1.18
CPRS: Problem List
3.1.19
CPRS: TIU-Text Integration Utility
3.1.20
Dentistry
3.1.21
EDIS-Emergency Department Integration Software
3.1.22
FIM-Functional Independence Measurement
3.1.23
Group Notes
3.1.24
HDR-Hx - HDR-Historical
3.1.25
HBPC-Home Based Primary Care
3.1.26
Home Telehealth
3.1.27
ICR-Immunology Case Registry
3.1.28
IRT-Incomplete Records Tracking
3.1.29
Intake and Output
3.1.30
Laboratory
3.1.31
Laboratory: Anatomic Pathology
3.1.32
Laboratory: Blood Bank
3.1.33
Laboratory: Blood Bank Workarounds
3.1.34
LEDI-Laboratory: Electronic Data Interchange
3.1.35
EPI-Laboratory: Emerging Pathogens Initiative
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap
3-49
3-50
3-51
3-53
3-57
3-57
3-58
3-59
3-60
3-62
3-64
3-66
3-67
3-70
3-71
3-72
3-74
3-74
3-76
3-79
3-80
3-81
3-82
3-83
3-85
3-86
3-88
3-91
3-92
3-93
3-94
3-96
3-97
3-99
3-99
3-100
3-101
Page v
3.1.36
3.1.37
3.1.38
3.1.39
3.1.40
3.1.41
3.1.42
3.1.43
3.1.44
3.1.45
3.1.46
3.1.47
3.1.48
3.1.49
3.1.50
3.1.51
3.1.52
3.1.53
3.1.54
3.1.55
3.1.56
3.1.57
3.1.58
3.1.59
3.1.60
3.1.61
3.1.62
3.1.63
3.1.64
3.1.65
3.1.66
3.1.67
3.1.68
3.1.69
3.1.70
3.1.71
3.1.72
3.1.73
3.1.74
3.1.75
3.1.76
3.1.77
3.1.78
3.1.79
3.1.80
3.1.81
3.1.82
3.1.83
3.1.84
3.1.85
Laboratory: Howdy Computerized Phlebotomy Login Process
Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form
POC-Laboratory: Point of Care
Laboratory: Universal Interface
VBECS-Laboratory: VistA Blood Establishment Computer Software
Lexicon Utility
Medicine
Mental Health
MH: Addiction Severity Index
MRSA-Methicillin Resistant Staph Aurerus
MED-Mobile Electronic Documentation
NHIN-Nationwide Health Information Network Adapter
Nursing
NFS-Nutrition and Food Service
Oncology
PAIT-Patient Appointment Information Transmission
PADP-Patient Assessment Documentation Package
PCE-Patient Care Encounter
Visit Tracking
Patient Record Flags
AR/WS-Pharmacy: Automatic Replenishment/ Ward Stock
BCMA-Pharmacy: Bar Code Medication Administration
PBM-Pharmacy: Benefits Management
Pharmacy: Consolidated Mail Outpatient Pharmacy
Pharmacy: Controlled Substances
Pharmacy: Data Management
Pharmacy: Drug Accountability
Pharmacy: Inpatient Medications
Pharmacy: National Drug File
Pharmacy: Outpatient Pharmacy
PPP-Pharmacy: Pharmacy Prescription Practices
PCMM-Primary Care Management Module
Prosthetics
QUASAR-Quality: Audiology And Speech Analysis And Reporting
Radiology/ Nuclear Medicine
RAI/MDS-Resident Assessment Instrument/ Minimum Data Set
ROES-Remote Order Entry System
Scheduling
Shift Handoff Tool
Social Work
Spinal Cord Dysfunction
STS-Standards & Terminology Services
Data Standardization
Terminology Services
Surgery
TBI-Traumatic Brain Injury
Virtual Patient Record
VistA Imaging System
VistAWeb
VIST-Visual Impairment Service Team
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap
3-102
3-103
3-104
3-105
3-107
3-108
3-111
3-113
3-115
3-118
3-118
3-119
3-120
3-122
3-124
3-126
3-128
3-128
3-130
3-131
3-132
3-133
3-135
3-137
3-137
3-139
3-139
3-140
3-145
3-147
3-152
3-153
3-155
3-157
3-158
3-160
3-161
3-162
3-164
3-165
3-167
3-168
3-170
3-171
3-172
3-175
3-175
3-176
3-179
3-180
Page vi
3.1.86
3.1.87
Vitals/ Measurements
Womens Health
3-180
3-183
3.2
Financial-Administrative
3.2.1
AR-Accounts Receivable
3.2.2
ASISTS-Automated Safety Incident Surveillance Tracking System
3.2.3
AICS-Automated Information Collection System
3.2.4
AMIE-Automated Medical Information Exchange
3.2.5
Clinical Monitoring System
3.2.6
CAPRI-Compensation and Pension Records Interchange
3.2.7
CPT-Current Procedural Terminology
3.2.8
DSS-Decision Support System Extracts
3.2.9
DRG-Diagnostic Related Group Grouper
3.2.10
ECME-Electronic Claims Management Engine
3.2.11
AEMS/MERS-Engineering
3.2.12
EAS-Enrollment Application System
3.2.13
Equipment/ Turn-In Request
3.2.14
Event Capture
3.2.15
Fee Basis
3.2.16
FFP-Fugitive Felon Program
3.2.17
GCS-Generic Code Sheet
3.2.18
HEC-Health Eligibility Center
3.2.19
HINQ-Hospital Inquiry
3.2.20
ICD-9-CM
3.2.21
IFCAP-Integrated Funds Distribution, Control Point Activity, Accounting, and Procurement
3.2.22
Incident Reporting
3.2.23
IVM-Income Verification Match
3.2.24
IB-Integrated Billing
3.2.25
Integrated Patient Funds
3.2.26
Library
3.2.27
Occurrence Screen
3.2.28
Patient Representative
3.2.29
PAID-Personnel and Accounting Integrated Data
3.2.30
Police and Security
3.2.31
Quality Management Integration Module
3.2.32
Record Tracking
3.2.33
ROI-Release of Information Manager
3.2.34
VIC/PICS-Veteran Identification Card
3.2.35
VSS-Voluntary Service System
3.2.36
Wounded Injured and Ill Warriors
3-186
3-189
3-191
3-193
3-194
3-195
3-196
3-198
3-199
3-200
3-202
3-204
3-207
3-208
3-209
3-211
3-213
3-214
3-216
3-219
3-221
3-222
3-225
3-226
3-228
3-232
3-233
3-235
3-238
3-242
3-243
3-246
3-247
3-248
3-249
3-251
3-252
3.3 Infrastructure
3.3.1
CMT-Capacity Management Tools
3.3.2
Duplicate Record Merge
3.3.3
E3R-Electronic Error and Enhancement Reporting
3.3.4
EELS-Enterprise Exception Log Service
3.3.5
FatKAAT
3.3.6
VA FileMan
3.3.7
FMDC-FileMan Delphi Components
3.3.8
Health Data Informatics
3.3.9
Health Level Seven (HL7) (VistA Messaging)
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap
3-253
3-256
3-256
3-259
3-259
3-259
3-260
3-262
3-263
3-265
Page vii
3.3.10
3.3.11
3.3.12
3.3.13
3.3.14
3.3.15
3.3.16
3.3.17
3.3.18
3.3.19
3.3.20
3.3.21
3.3.22
3.3.23
3.3.24
3.3.25
3.3.26
3.3.27
3.3.28
3.3.29
3.3.30
3.3.31
3.3.32
3.3.33
3.3.34
3.3.35
3.3.36
3.3.37
IFR-Institution File Redesign
KAAJEE-Kernel Authentication & Authorization for Java 2 Enterprise Edition
Kernel
KDC-Kernel Delphi Components
Kernel Toolkit
Kernel Unwinder
List Manager
M-to-M Broker
MailMan
MPI-Master Patient Index
MDWS-Medical Domain Web Services
Name Standardization
NOIS-National Online Information Sharing
National Patch Module
NHE-Network Health Exchange
PDX-Patient Data Exchange
RPC-Remote Procedure Call Broker
Resource Usage Monitor
SSO/UC-Single Signon/User Context
SlotMaster (Kernel ZSLOT)
SQLI-SQL Interface
Standard Files and Tables
SAGG-Statistical Analysis of Global Growth
Survey Generator
STK-System Toolkit
VDEF-VistA Data Extraction Framework
VistALink
XML Parser (VistA)
3.4 HealtheVet
3.4.1
CISS-Clinical Information Support System
3.4.2
ESig-Electronic Signature
3.4.3
HWSC-HealtheVet Web Services Client
3.4.4
My HealtheVet
3.4.5
NUMI-National Utilization Management Integration
3.4.6
OHRS-Occupational Health Record-keeping System
3.4.7
PATS-Patient Advocate Tracking System
3.4.8
Person Services
3.4.9
Registries
3.4.10
SCIDO-Spinal Cord Injury and Disorders Outcomes
3.4.11
VES-VA Enrollment System
3.4.12
VPFS-Veterans Personal Finance System
4
APPENDIX A: PRODUCT DEFINITION
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap
3-268
3-270
3-274
3-276
3-276
3-278
3-279
3-281
3-282
3-284
3-288
3-289
3-291
3-291
3-292
3-293
3-295
3-296
3-297
3-298
3-299
3-301
3-302
3-303
3-305
3-306
3-306
3-308
3-310
3-312
3-313
3-313
3-315
3-316
3-318
3-319
3-321
3-322
3-323
3-325
3-328
4-1
Page viii
1 Introduction
Section 1 provides an executive summary of OSEHRA’s System Architecture, Product
Definition and Roadmap (SAPD&R) initiative, provides references, defines abbreviations,
overviews the SAPD&R and presents the OSEHRA-VistA Meta-Model and Glossary.
1.1 Executive Summary
The Veterans Health Information Systems and Technology Architecture (VistA) is
an enterprise-wide healthcare information system built around an Electronic Health
Record (EHR), used throughout the United States Department of Veterans Affairs (VA)
medical system, since the 1980s. VistA is a collection of about 168 integrated application
packages/modules, containing over 26,000 software-code routines.
By 2003, the VHA was the largest single medical system in the United States, providing
care to over 4 million veterans, employing 180,000 medical personnel and operating 163
hospitals, over 800 clinics, and 135 nursing homes. About a quarter of the nation's
population is potentially eligible for VA benefits and services because they are veterans,
family members, or survivors of veterans.
Historically, the VA made VistA available to the open source community; open source
VistA has a large national and international user base (MedSphere, DSS, WorkdVistA,
IHS, nations, states, universities, etc.). In August 2011, the VA began providing VistA to
the open source community through the non-profit Open Source EHR Custodial Agent
(OSEHRA) and the resultant product is called Open Source EHR (OSEHR), which is
free. OSEHR is intended to encourage and incorporate innovation by the open-source
EHR community.
The OSEHRA’s System Architecture, Product Definition and Roadmap (SAPD&R) is
intended for a broad spectrum of OSEHR stakeholders, who wish to understand or
navigate through the huge OSEHR-VistA codebase, related documents and/or test and
certification artifacts. It is intended to be used to support strategic planning, transition
planning, research, analysis, development, as well as operational support. Both MS
Word and PDF document and HTML web-browser navigatable versions of the OSEHR
SAPD&R are periodically (e.g., weekly) produced and made available on
www.OSEHRA.com in the Architecture Work Group section.
Stakeholders are
encouraged to drink from the OSEHR well and bring back their lessons learned and
innovative ideas to improve the OSEHR baseline as we transition to a national and
international interoperable EHR (iEHR).
Section 1 Introduction provides an executive summary of OSEHRA’s System
Architecture, Product Definition and Roadmap (SAPD&R) initiative, gives references,
defines abbreviations, overviews the SAPD&R and presents the OSEHRA-VistA MetaModel and Glossary. Section 2 Product Definition and Roadmap presents the high level
OSEHR Product Definition and Roadmap, including Caché/Windows and GT.M/Linux
environments. Section 3 System Architecture (SA) presents the detailed OSEHR System
Architecture (SA) and links to source documents and related artifacts. Section 4 SDK for
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 9
Future-State iEHR Architecture presents a Software Development Kit (SDK) for the
future-state interoperable EHR System (iEHR) solution and how to document
Interoperability Specification for its component modules. The OSEHR System
Architecture, Product Definition and Roadmap will be refined and updated to reflect the
journey to the future-state iEHR architectural vision summarized in the Prefix and
discussed in Section 2.5.2.
OSEHRA’s (Open Source EHR Custodial Agent’s) software started with the August 2011 FOIA
release of the VA VistA software, which is known as OSEHR (Open Source EHR).
Open-source EHR custodial-agent key milestones are:
17-Jun-11 OSEHRA Contract Signed
17-Aug-11 Custodial Agent Established as 501-c6 non-profit org.
18-Aug-11 VA published the initial OSEHR-FOIA baseline
17-Sep-11 OSEHR Initial-2011-Baseline System-Architecture
17-Oct-11
Custodial Agent Fully Operational
06-Dec-11 OSEHR Verified-2011-Baseline System-Architecture
06-Mar-12 “Strawman” OSEHR Product Definition & Roadmap
06-Jun-12 “Ironman” OSEHR Product Definition & Roadmap
OSEHR’s System Architecture, Product Definition and Roadmap (SAPD&R) started with
the 17-Sep-11 Initial-2011-Baseline. A modeling tool was used to generate section 2, 3
and 4 of the SAPD&R document. The SAPD&R is the open source communities’
knowledge repository; it is constantly being updated as we transition to a future-state
interoperable EHR (iEHR). Periodic (e.g., monthly) working draft updates are published
at www.OSEHRA.org , under the Architecture Working Group; also see
http://architecture.OSEHRA.org for the web-browser navigable HTML version. Feedback
from the VA, DoD, Open Source Community and OSEHR stakeholders are incorporated
into OSEHRA’s SAPD&R.
OSEHR System Architecture, Product Definition and Roadmap’s
latest revision is available at:
SAPD&R HTML version http://architecture.osehra.org
SAPD&R MS-Word & PDF version at http://www.osehra.org/node/47/content/documents
Please submit suggestions for improvement at: http://www.osehra.org/node/47/content/discussions
Distributed development without an architectural vision is virtually impossible.
1.2 Architecture Working Group
Anyone can participate in OSEHRA and its Architecture Working Group (AWG):
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 10
Weekly Open-Source EHR - Architecture Work Group (AWG) Telecom
DATE & TIME: Every Tuesday 4:00 pm ET WebEx: https://tiag.webex.com/
PHONE: +1-408-600-3600 Access code: 629 453 409 or use VOIP
DOCUMENTS at: http://www.osehra.org/node/47/content/documents
DISCUSSION at: http://www.osehra.org/node/47/content/discussions
WIKI at: http://www.osehra.org/node/47/content/wikis
HTML SYSTEM ARCHITECTURE at: http://architecture.osehra.org … can be viewed with a web browser.
VISUAL CROSS-REFERENCE at: http://code.osehra.org/dox/
REQUESTED ACTIONS:
 Joining OSEHRA is free; please join at www.OSEHRA.org.
 Please join the OSEHRA AWG at: http://www.osehra.org/groups to participate and receive AWG e-mail.
 Add your comments and suggestions-for-improvement to the AWG discussion forum or Wiki.
1.3 References
Publically available web site links:













See http://www.va.gov/vdl/ for VistA Documentation Library (VDL).
See http://downloads.va.gov/ VA FOIA site for VistA codebase Library.
See http://www.va.gov/trm for VA TRM public site.
See http://www.va.gov/TRM/TRMHomePage.asp for http://www.va.gov/TRM/TRMHomePage.asp, the One-VA
TRM, which includes the Standards Profile and Product List, collectively serve as a technology roadmap and as a
tool for supporting Office of Information & Technology (OIT).
See www.OSEHRA.org for OSEHRA deliverable Library.
See http://en.wikipedia.org/wiki/SOAP for SOAP-style web service consumption used by HealtheVet XOBW
See http://en.wikipedia.org/wiki/Representational_State_Transfer for for REST-style web service consumption,
used by HealtheVet XOBW
See http://tinco.pair.com/bhaskar/gtm/doc/books/ao/OpenVMS_manual/titlepage.html for GT.M
Administration and Operations Guide
See http://docs.intersystems.com/ for Caché documentation
See www.vehu.va.gov/ for VA eHealth University (VeHU) is VA’s major annual training conference that provides
education on the Computerized Patient Record System (CPRS) and related clinical software (VistA) developed by
the Veterans Health Administration (VHA).
http://vista.med.va.gov/pas/NewITRequestForm.asp Request for New Information Technology Services:
Requests for new software or software enhancements must be endorsed by and submitted to the VHA NLB
Information Data Management Committee (IDMC). The initial review and recommendation must go through the
IDMC Screening Committee prior to submitting to IDMC for final approval. This site provides an on-line request
form along with guidance on submissions.
VHA Enterprise Architecture: http://www.ea.oit.va.gov/index.asp VHA developed an Enterprise Architecture
that provides a technical framework to promote a one technology vision across the Department so that all
systems are interoperable.
Capital Investment Planning: http://www.va.gov/budget/capital/ Planned IT capital asset expenditures that
exceed $10 million acquisition or $30 million life cycle costs, or have high levels of risk or visibility, must
apply to the Capital Investment Board for approval. The VA Capital Investment Board (VACIB) oversees
the approval of all capital investment proposals that exceed certain threshold requirements, represent a high
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 11






risk or high visibility or are cross-cutting. Approved proposals constitute the VA Capital Plan and support annual
budget requests.
VistA Monograph on the Internet: See http://www.va.gov/vista monograph/
Corporate Database Monograph: http://vaww.va.gov/../nds/CorporateDatabasesMonograph.asp The Corporate
Database Monograph provides an overview of the active VHA national databases. Information contained in
this monograph allows stakeholders to identify opportunities for database consolidations, determine authoritative
data sources, and work with VHA Data Quality committees to implement data standardization and quality control
processes for corporate databases.
VA Information Technology Strategic Plans: http://www.itsegov.oit.va.gov/docs/it strat plan.pdf
See https://www.voa.va.gov/ for the public facing Virtual Office of Acquisition (VOA) portal which includes links for
the following two libraries:
o VA Software Development Standards for VistA
o VA Interface Control Registrations (ICRs)
o ‘vendor version’ of ProPath (process templates)
See http://www.ehealth.va.gov/EHEALTH/CPRS_Demo.asp for a good representation of the VistA product. Most
of the test patients do not have sufficient data to show what all of the functions can do, but as an overall visual
look and feel, it's identical to the live instances.
http://code.osehra.org/dox/index.html - VistA Cross Reference Documentation Page. This documentation is
generated with the results of XINDEX utility running against the VistA code base pulled from the repository. This
documentation provides direct dependency information among packages, as well as direct call graph information
and source code for individual routines.
Internal VA web site links:

See, for test services web site: http://vaww.oed.portal.va.gov/engineering/testing/default.aspx

See http://vista.med.va.gov/migration/analysis/ for the VistA As-Is Model and the Analysis Organization
(AO) Doc the research work Library.


http://vaww.vista.med.va.gov/sacc/ SACC home page for Standards and Conventions (SAC).
See download.vista.med.va.gov anonymous.software directories on the Office of Information Field Office (OIFO)
File Transfer Protocol (FTP) download sites

See http://trm.oit.va.gov for VA Technical Reference Manual (TRM), that explicitly describes allowed use
of tools and if any constraints are established. There are constraints on M(UMPS).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 12
1.4 Contract Deliverables
This document provides the deliverables for Tasks 5.9 and 5.11 of the OSEHRA-VA contract.
 Task 5.9 Manage EHR Open Source Architecture
o Item 0003AG: Initial architecture documentation to be completed IAW PWS Paragraph 5.9
NLT 30 days after activation of the Custodial Agent (deliverable due 17 Sep 2011).
o Item 0003AH: Architecture updates to be completed IAW PWS Paragraph 5.9 to be
submitted on an “as needed” basis (default will be quarterly with task 5.11 CDRL).
 Task 5.11 Manage EHR Open Source Product Definition
o Item 0003AJ: Published product definition and product roadmap to be completed IAW PWS
Paragraph 5.11, with quarterly updates NLT 30 days after activation the Custodial Agent
operations (deliverable due 17 Sep 2011, 17 Dec 2011, …).
The task 5.9 and 5.11 initial deliverable is a System Architecture (SA) model. Task 5.9’s and task 5.11
Contract Deliverables (CDRLs) will be an SA-tool-generated report. The SA model is based-on and includes
links-to the online VistA documentation library1 plus the GT.M and InterSystems Cache environment
components. The SA model will ultimately be based-on and include links-to the OSEHR documentation
library, codebase, test fixtures and test and certification results. The SA tool will contain architectural views,
including but-not-limited to modules modeled as UML classes, showing:
– module descriptions and functions, module-to-module dependencies, module-to-data dependencies
– Links to available Documentation, code, test fixtures, test reports, certifications.
. The OSEHRA website will contain an SA-tool-generated HTML-navigable SA model, appropriately linked to
online OSEHR/VistA artifacts. Over the first year, the Task 5.9 and 5.11 SA model fidelity and deliverables
will be incrementally extended, to the extent that information is available. The System Architecture will be
updated and will be kept current as we migrate to the future-state iEHR architectural vision, discussed in
Section 2.5.2.
1.4.1 System Architecture Approach (Task 5.9)
Over the first year, the Task 5.9 SA model fidelity and deliverables will be incrementally extended to ultimately include:
• Application Program component Interfaces (APIs)
• Component functional-descriptions linked to component UML classes
– based on HL7 EHR System Functional Model (EHR-S FM),
– Including EHR-S FM conformance criteria to support test and certification,
– Including ARRA Meaningful use objectives and criteria, mapped via EHR-S-FM,
– Including VA Business Functional Framework (BFF) mapped to odules
– Including HHS mandated HITSP-constructs, mapped via EHR-S-FM,
– Including HHS/ONC EHR Standards and Interoperability (S&I) specifications and certification criteria,
mapped via EHR-S-FM.
1.4.2 Product Definition Approach (Task 5.11)
Task 5.11 (A) states that the CA shall maintain a definition of the Open Source EHR product, including a functional
description of the software and features as well as supported components (e.g., client and server operating systems,
1
The VistA Documentation Library is available at http://www.va.gov/vdl/
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 13
database managers, application program interfaces, etc.). The product definition shall describe an installable version
of the EHR Open Source product. For task 5.11 the following will be included:
• Integration Control Registrations (ICRs) formerly known as Data Base Integration Agreements (DBIA)
• Component-level codebase-analysis conclusions-and-recommendations
• GT.M & Cache deployment environment components plus RPCs and APIs modeled in UML
– Patch sequence order to update deployed systems (as distributed internal within VA)
• Roadmap of configuration-baselines of product-deployment release-contents (quarterly)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 14
1.5 Acronyms
AA
Authentication and Authorization
ACOS
American College of Surgeons
ACOS
Associate Chief of Staff
ACRP
Ambulatory Care Reporting Program
ADC
Active Dual Consumers
ADR
Administrative Data Repository
ADR
Adverse Drug Reactions
ADT
Admission/Discharge/Transfer
AEMS/M ERS Automated Engineering Management
System/Medical Equipment Reporting Systems
AICS
Automated Information Capture System
AICS
Automated Information Collection System
AITS
Austin Information Technology Center
AJCC
American Joint Commission on Cancer
AMIE
Automated Medical Information Exchange
AMS
Acc-Med Services
ANSI
American National Standards Institute
API
Application Program Interface
APs
Associate Primary Providers
API
Application Programmers Interface
AR
Accounts Receivable
ARAMIS American Rheumatology Associations Medical
Information System
ART
Adverse Reaction Tracking
ART
Allergy/Adverse Reaction Tracking
AR/WS
Automatic Replenishment/Ward Stock
ASCII
American Standard Code for Information Interchange
ASIA
American Spinal Injury Association
ASI-MV
Addiction Severity Index Multimedia Version
ASISTS
Automated Safety Incident Surveillance Tracking
System
ASU
Authorization/Subscription Utility
BMA
Bone Marrow Aspirates
BMB
Bone Marrow Biopsies
BCMA
Bar Code Medication Administration
BDK
Broker Developer Kit
BHIE
Bi-Directional Health Information Exchange
BRC
Blind Rehabilitation Centers
BROS
Blind Rehabilitation Outpatient Specialist
BSE
Broker Security Enhancement
C&P
Compensation &Pension
CAIP
Cross-Application Integration Protocol
CAPRI
Compensation and Pension Records Interchange
CBO
Chief Business Office
CCOW
Clinical Context Object Workgroup
CCPC
Consolidated Copayment Processing Center
CCSHS
Center for Cooperative Studies in Health Services
CCR
Clinical Case Registries
CDC
Center for Disease Control
CDR
Cost Distribution Report
CHART
Craig Handicap Assessment and Reporting
Technique
CHDR
Clinical/Health Data Repository
www.oserha.org
CIS
CMOP
CMS
COC
COTS
CP
CPM
CPRS
CPT
CPWM
CRUD
CSAR
CS idM
CS/OS
CS/PS
D&PPM
DBIAs
DCHP
DDC
DHCP
DICOM
DUSOI
DLL
DMC
DMI
DNR
DNS
DoD
DRG
DRG
DSD
DSM
DSM-IV
DSS
DUE
DUR
DVA
EAS
ECG
ECME
EDI
EDSS
EEOB
EGD
EIS
EM
ERCP
ESN
FAM
FatKAAT
FDA
FHIE
FIM
Clinical Information Systems
Consolidated Mail Outpatient Pharmacy
Centers for Medicare and Medicaid Services
Commission on Cancer
Commercial-off-the-Shelf
Clinical Procedures
Critical Path Method
Computerized Patient Record System
Current Procedural Terminology
Compensation and Pension Worksheet Module
Create, Read, Update and Deactivate
Controlled Substance Administration Record
Common Services Identity Management
Common Services/Organization Service
Common Services/Person Service
Drug and Pharmaceutical Products Management
Data Base Integration Agreements
Decentralized Hospital Computer Program
Denver Distribution Center
Decentralized Hospital Computer Program
Digital Imaging and Communications in Medicine
Duke University Severity of Illness Index
Dynamic Link Library
Debt Management Center
Data Migration Initiative
Do Not Resuscitate
Domain Name Service
Department of Defense
Diagnostic Related Group
Inpatient Care Grouping
Delivery Service Delegate
Diagnostic and Statistical Manual of Mental Disorders
Diagnostic and Statistical Manual of Metal Disorders
Decision Support Decision
Drug Use Evaluation
Drug Utilization Review
Department of Veterans Affairs
Enrollment Application System
Electrocardiogram
Electronic Claims Management Engine
Expanded Disability Status Scales
Electronic Data Interchange
Electronic Explanation of Benefits
Esophageal Gastrodoudenoscopy
Enterprise Information System
Electron Microscopy
Endoscopic Retrograde Cholangiogram and
Pancreatogram
Enterprise Service Network
Functional Assessment Measure
Fat-Client Kernel Authentication
Food and Drug Administration
Federal Health Information Exchange
Functional Independence Measure
OSEHR System-Architecture, Product Definition and Roadmap
Page 15
FIPS
FMS
FOIA
FORDS
FPDS
FTEE
GAF
GEC
GUI
GWOT
HAIISS
Federal Information Processing Standards
Financial Management System
Freedom of Information Act
Facility Oncology Registry Data Standards
Federal Procurement Data System
Full-Time Employee Equivalent
Global Assessment of Functioning
Geriatric Care Referral
Graphical User Interface
Global War on Terror
Healthcare Associated Infection and Influenza
Surveillance System
HBHC
Home Based Health Care
HCPCS
Healthcare Common Procedure Coding System
HDR
Health Data Repository
HDR DW Data Warehouse
HDR Hx
Historical Data
HDR IMS Interim Messaging Service
HDR II
Definitive HDR
HDS
Health Data Systems
HEC
Health Eligibility Center
HINQ
Hospital Inquiry
HIPAA
Health Insurance Portability and Accountability Act
HISA
Home Improvement Structural Alterations
HITS
Health IT Sharing
HIV
Human Immunodeficiency Virus
HLLP
Hybrid Lower Level Protocol
HLO
Health Level Seven Optimized
HL7
Health Level Seven
HOST
Hybrid Open System Technology
HSR&D
Health Services Research and Development
HWSC
HealtheVet Web Services Client
ICN
Integration Control Number
IMDQ
Identity Management Data Quality
I&O
Intake and Output
IB
Integrated Billing
ICD-9
International Classification of Diseases
ICD-9-CM International Classification of Diseases – 9th Edition
– Clinical Modification
ICR
Immunology Case Registry
IDMC
Information Data Management Committee
IFCAP
Integrated Funds Control, Accounting and
Procurement
IHD
Ischemic Heart Disease
IMDQ TK Identity Management Data Quality Toolkit
IP
Internet Protocol
IRM
Information Resources Management
IRS
Internal Revenue Service
IRT
Incomplete Records Tracking
IT
Information Technology
IV
Intravenous
IVM
Income Verification Match
JCAHO
Joint Commission on Accreditation of Healthcare
Organizations
www.oserha.org
JMS
JPTA
J2EE
KAAJEE
KDC
KIDS
LDSI
LDSI
LEDI
LIS
LM
MAS
MCCF
MDD
MEM
MHA
MHV
MLLP
MPI
MPI/PD
MSADBAA
MSH
MUMPS
N&FS
NANDA
NDC
NDS
NHE
NPCD
NCPDP
NPI
NSQIP
NTE
NTRT
O/E
OIF/OEF
OS
OSHA
OTC
PACS
PAID
PATS
PBM
PBM
PCE
PCE
PCMM
PCP
PDHRA
PDM
Java Messaging Service
Joint Patient Tracking Application
Java 2 Enterprise Edition
Kernel Authentication and Authorization for J2EE
Kernel Delphi Components
Kernel Installation and Distribution System
Laboratory Data Sharing Initiative
Lab Data Sharing Interoperability
Laboratory Electronic Data Interchange
Laboratory Information Systems
List Manager
Medical Administration Service
Medical Care Collections Fund
Major Mood Disorder
Message Exception Manager
VistA Mental Health Assistant
My HealtheVet
Minimum Lower Level Protocol
Master Patient Index
Master Patient Index/Patient Demographics
Microsoft Active Directory-based Authentication and
Authorization
Message Header
Massachusetts General Hospital Utility MultiProgramming System
Nutrition and Food Service
North American Nursing Diagnosis Association
National Drug Code
Naming Directory Service
Network Health Exchange
National Patient Care Database
National Council for Prescription Drug Programs
National Provider Identifier
National Surgical Quality Improvement Program
Network Health Exchange
New Term Rapid Turnaround
Observed –to-Expected
Operation Iraqi Freedom/Operation Enduring
Freedom
Organization Service
Occupational Safety & Health Administration
Over The Counter
Picture Archiving Communication Systems
Personnel and Accounting Integrated Data
Patient Advocate Tracking System
Pharmacy Benefits Management
Pharmacy Benefits Management Strategic Health
Group
Patient Care Encounter
Patient Care Evaluations
Primary Care Management Module
Primary Care Provider
Post Deployment Health Reassessments
Pharmacy Data Management
OSEHR System-Architecture, Product Definition and Roadmap
Page 16
PDTS
PDX
PICS
PIMS
PPDHA
PPP
PS
PSC
PSD
PSL
PTF
QUASAR
Pharmacy Data Transaction Service
Patient Data Exchange
Patient Image Capture Software
Patient Information Management System
Pre and Post Deployment Health Assessments
Pharmacy Prescription Practices
Person Service
Person Service Construct
Person Service Demographics
Person Service Lookup
Patient Treatment File
Quality: Audiology and Speech Analysis and
Reporting
QUERI
Quality Enhancement Research Initiative
RAID
Rapid Application Interface Development
RAI/MDS Resident Assessment Instrument/Minimum Data Set
RAPs
Resident Assessment Protocols
RDI
Remote Data Operability
ROs
Regional Offices
ROES
Remote Order Entry System
RPC
Remote Procedure Call
RUG-III
Resource Utilization Groups
RUG
Long Term Care Grouping
SADR
Standard Ambulatory Data Record
S-BAR
Situation, Background, Assessment,
Recommendations
SCD
Spinal Cord Dysfunction
SCS
Subscription Control Service
SD&D
System Design & Development
SDDM
Site Demographic Data Migration
SDOs
Standards Development Organizations
SEER
Surveillance, Epidemiology, and End Results
Reporting
SNOMED CT Systematized Nomenclature of Medicine –
Clinical Terminology
SOA
Service Oriented Architecture
SOCS
Security and Other Common Services
SP
Surgical Pathology
www.oserha.org
SSA
SSD
SSO/UC
SSPIs
STS
T&L
TBI
TCP
TCP/IP
TF
TIU
TMDS
UD
UI
VA
VACIB
VALNET
VAMC
VBA
VDEF
VDL
VERA
VETS
VHA
VIC
VIE
VISN
VistA
VPFS
VPID
VSS
VTA
VTK
VUID
WHO
XML
Social Security Administration
Secure Software Development
Single Sign-On/User Context
Security Service Provider Interfaces
Standards & Terminology Services
Time and Leave
Traumatic Brain Injury
Transmission Control Protocol
Transmission Control Protocol/Internet Protocol
Treating Facilities
Text Integration Utility
Theatre Medical Data System
Unit Dose
User Interface
Department of Veterans Affairs
VA Capital Investment Board
VA Library Network
Veterans Administration Medical Centers
Veterans Benefits Administration
VistA Data Extraction Framework
Virtual Due List
Veterans Equitable Resource Allocation
VHA Enterprise Terminology Services
Veterans Health Administration
Veteran Identification Card
VistA Interface Engine
Veterans Integrated Services Network
Veterans Health Information Systems and
Technology Architecture
Veterans Personal Finance System
VA-wide Person Identifier
Voluntary Service System
Veterans Tracking Application
Voluntary Timekeeping System
Veteran’s Health Administration Unique Identifier
World Health Organization
Extensible Markup Language
OSEHR System-Architecture, Product Definition and Roadmap
Page 17
1.6 Legend, Meta-Model and Glossary
Figure 1-1 shows the OSEHRA-VistA meta-model; its coloring conventions are described in Section
1.6.1 and its elements and constructs are defined in Section 1.6.2.
Figure 1-1 OSEHR System Architecture (SA) Meta-Model
1.6.1 Color Conventions for System Architecture Model
Subsystem Level, depicted in pink, is a high-level view of VistA relationships. OSEHR is composed of the VistA 1.0
and VistA 1.5 (also known as HealtheVet) subsystems documented in Section 3 and does not include all of the other
Section 2 subsystems, depicted in pink.


This overview level is the starting point for viewing the enterprise-wide model. It shows the relationships and
business interfaces/inter-dependencies between the element groups, VistA 1.0 and VistA 1.5. For example,
a dependency exists between VistA 1.5 and the Master Patient Index (MPI) utilizing the Vitrea Interface
Engine (VIE), Delivery Service, and HL7 2.4. A representational VistA 1.0 instance is included in this model,
rather than capturing the many code differences between local sites.
In the cases of MPI, Health Eligibility Center (HEC), and Corporate Data Warehouse (CDW), drilling down
from the Overview level will result in a simplified view of that same level, rather than a view of the
Transitional or Detail levels.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 18
Transitional level, depicted in green, provides a breakdown of three of the element categories first shown in the
Overview level of the model: VistA 1.0, Corporate Databases and Centralized Data Repositories (CDR).
 In the case of VistA 1.0, the Transitional level is used to group applications into the Clinical,
Financial/Administrative, and Infrastructure categories, based on the classifications within the VA Software
Document Library (VDL). These element categories are further broken down in the Section 3 Detail level.

In the case of Corporate Databases, this level is used to group databases into the Clinical,
Financial/Administrative and Infrastructure categories, based on the classification of the VistA 1.0
applications on which the databases depend.

In the case of Clinical Data Repository (CDR), the Transitional level shows the collection of data repositories
that interact with the VistA system. No further breakdown is given.
Package (aka Module or Application) Level, depicted in blue, is the next lower level of the model. With the
exception of OSEHR 1.0 (formerly known as VistA 1.0) and OSEHR 1.5 (formerly known as VistA 1.5 and also
known as HealtheVet), the package/module level provides a final breakdown of the element categories shown in the
transition levels of the model. Due to the extensive number of OSEHR/VistA 1.0 and OSEHR/VistA 1.5 application
packages (approximately 168 packages/modules and 26k+ routines), it was not feasible to document all of the
interdependencies and relationships in Section 2. Therefore, the user must drill-down on each OSEHR application in
Section 3 to view its interdependencies and relationships. These application packages aka modules or applications
were derived from the VDL plus XINDEX utility and code-level research. External Entities, depicted as grey “UMLNode” elements, are outside of the OSEHR/VistA system boundaries.
Routine and Data-File Level, depicted in yellow, is the lowest level of the model. Routines and data-files reside
within MUMPS Namespaces.
1.6.2 Glossary for System Architecture Model Elements and Constructs
 An Aggregation connector (has-a) is a type of association that shows that an element contains or is composed
of other elements. It is used in Class models, Package models and Object models to show how more complex
elements (aggregates) are built from a collection of simpler elements (component parts; for example, a car from
wheels, tires, motor and so on). A stronger form of aggregation, known as Composite Aggregation, is used to
indicate ownership of the whole over its parts. The part can belong to only one Composite Aggregation at a time.
If the composite is deleted, all of its parts are deleted with it.

An Application Programming Interface (API) serves as an interface between different software modules and
facilitates their interaction, similar to the way the user interface facilitates interaction between humans and
computers, such as those written in JAVA, C++, Delphi, etc.

An Association Connector implies two model elements have a relationship, usually implemented as an
instance variable in one Class. This connector can include named roles at each end, multiplicity, direction and
constraints. Association is the general relationship type between elements. To connect more than two elements
in an association, you can use the N-Ary Association element.

Boundary is a UML element to group similar or associated element, such as a set of MUMPS Globals.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 19

a Class diagram is a type of static structure diagram that describes the structure of a system by showing
modules as UML class elements, their interrelationships (including inheritance, aggregation, and association),
and the operations (or methods) and attributes of the classes.

Component element is used to model a physical deployable component (e.g., FileMan, Kernel, Cache), which
is part of the software product definition. Components may have “Provided Interfaces” and “Required
Interfaces”, which are APIs or RPCs.

A Dependency in the Unified Modeling Language (UML) exists between two defined elements if a change to the
definition of one may result in a change to the other. In UML this is indicated by a dashed line pointing from the
dependent (or client) to the independent (or supplier) element.

Entity is a UML Model element representing a Mumps global namespace. Globals contain files and routines.

File is a component of a MUMPS namespace, is a part of the MUMPS "database", which contains one-or-more
arrays which are accessed by MUMPS routines.

Integration Control Registrations (ICRs) formerly known as Data Base Integration Agreements (DBIA) allow
modules to share Global Namespace File Attributes. As an example, DBIA #2923 with PAID allows ASISTS the
use of $Order through the top level of ^PRSPC(I). ASISTS gets a count of the number of PAID employees at
each facility who are not separated. That information is used in statistical analysis for blood-borne pathogen
reporting. After getting the IEN of each PAID employee, the routine will use a FileMan read to determine
whether the employee is separated. The routine will be executed on a monthly basis. DBIA #936 with the
KERNEL which allows ASSISTS the use of the routine XUSESIG. This routine, when called from the top, allows
the user to setup a personal electronic signature code. It is used within application code to allow the user
immediate 'on-the-fly' access to setup the electronic signature, rather than force the user to leave the application
and enter a different option to do the same.
As an example, the following are the steps you may take to obtain database integration agreements for the
Clinical Monitoring System package.
DBIA AGREEMENTS - CUSTODIAL PACKAGE
1. FORUM
2. DBA Menu
3. Integration Agreements Menu
4. Custodial Package Menu
5. Active by Custodial Package Option
6. Select Package Name: CLINICAL MONITORING SYSTEM
DBIA AGREEMENTS - SUBSCRIBER PACKAGE
1. FORUM
2. DBA Menu
3. Integration Agreements Menu
4. Subscriber Package Menu
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 20
5. Print Active by Subscriber Package Option
6. Start with subscriber package: QAM to QAMZ

The Generalization relationship ("is a") indicates that one of the two related classes (the subclass) is
considered to be a specialized form of the other (the super type) and superclass is considered as
'Generalization' of subclass. In practice, this means that any instance of the subtype is also an instance of the
superclass. An exemplary tree of generalizations of this form is found in binomial nomenclature: human beings
are a subclass of simian, which are a subclass of mammal, and so on. The relationship is most easily
understood by the phrase 'an A is a B' (a human is a mammal, a mammal is an animal).

An Information Flow represents information items or classifiers flowing between two elements in any diagram.
The connector is available from the Common page of the Toolbox and from every Quick Link menu. You can
have more than one Information Flow connector between the same two elements, identifying which items flow
between the two under differing conditions.

Module (aka package or application) contains one-or-more routines, which is analogous to what is also
commonly called a capability (e.g., The capacity to be used, treated, or developed for a specific purpose .. a
History & Physical or Immunization capability). A MUMPS module is composed of one-or-more MUMPS
routines. A Toolkit is a form of Module.

Global contain 1 or more files or routines. All MUMPS systems use "Globals" as the basis of their storage
mechanism. Put simply, a Global is a persistent, sparse, dynamic, multi-dimensional array, containing a text
value; they are managed by FileMan, which is OSEHR’s DBMS component. MUMPS allows the use of both
persistent and non-persistent multi-dimensional arrays, the latter known as “local arrays”. Somewhat unusually,
MUMPS allows the use of both numeric and textual subscripting. So in MUMPS, you can have an array such as:
Employee(company,country,office,employeeNumber) = employeeDetails

o
^ - All variable names prefixed with the caret character ("^") use permanent storage, will maintain their
values after the application exits, and will be visible to (and modifiable by) other running applications.
o
Non caret character ("^") prefixed variable names may be temporary and private. That is, they are in
the symbol table and accessible to any program that is executing in the same stack (unless it was
NEWed). Some programs, like FileMan use structured variables to receive input to the program that
aren't passed as globals (e.g. ^DIC) that may have the same name as a global or variable. This works
because the symbol table is shared by processes executing in the same stack. Example: I need to
lookup a value in FileMan: I setup the DIC (local variable) then call ^DIC (routine) which looks in the
symbol table for DIC (local variable) to get its instructions on what to do.
Example code:
S DIC="^DIZ(16150,",DIC(0)="QEAL" D ^DIC
I Y=-1 K DIC Q ;quit if look-up fails
Here ^DIZ is a global, DIC is a local variable and ^DIC is a routine. It is all about context
a Namespace, as far as OSEHR is concerned, is a 2-4 character string that uniquely identifies a package in the
system so namespaces encompass: variables, globals, routines, etc. For example the Kernel has the
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 21
following: XU, A4A7, USC, XG, XIP, XLF, XNOA, XPD, XQ, XVIR, ZI, ZOSF, ZOSV, ZT, ZU, %Z, -XQAB, -XUC,
-XUR, -ZIN, -ZTED (- means exclude). You can see routines that fall in these namespaces as well as globals
(and variables).
o “%” typically means the item is in the system or manager namespace. This is a bit of VistA
history: early on programmers stored parts of the VistA system in the system/manager namespace that
were common to all VistA systems that were running on that computer (since computers were
expensive at the time and had less resources) to be stored once and used by all of the VistA
environments. There were some down sides: if you had to upgrade these items all VistA instances had
to upgrade, etc. Eventually the M vendors locked programmers out of the system/manager namespace
(by making it read-only), so VistA had to adapt. We now do routine and global mappings to the OSEHR
namespace that contains these items.

A Node is a physical piece of equipment on which a system is deployed, such as a workgroup server or
workstation. A Node usually hosts components and other executable pieces of code, which again can be
connected to particular processes or execution spaces. Typical Nodes are client workstations, application
servers, mainframes, routers and terminal servers. Nodes are used in Deployment diagrams to model the
deployment of a system, and to illustrate the physical allocation of implemented artifacts. They are also used in
web modeling, from dedicated web modeling pages in the Toolbox. Node (External) represents an external
system, which interact with VistA.

A Package is used "to group elements, such as routines, and to provide a namespace for the grouped
elements". A package may contain other packages, thus providing for a hierarchical organization of packages.

Realize Connector, in the model, is an association between a package and its contents. A source object
implements or Realizes its destination object. Realize connectors are used in a Use Case, Component or
Requirements diagram to express traceability and completeness in the model. A business process or
Requirement is realized by one or more Use Cases, which in turn are realized by some Classes, which in turn
are realized by a Component, and so on. Mapping Requirements, Classes and such across the design of a
system, up through the levels of modeling abstraction, ensures the big picture of a system reflects all the details
that constrain and define it.

Routine is a component of a MUMPS Namespace, which is a part of a software package/module/application. A
routine contains one-or-more M-coded methods, functions or procedures and generally accesses MUMP'S
namespace (data) files.

a Remote Procedure Call (RPC) aka Remote Invocation or Remote Method Invocation is an inter-process
communication that allows a computer program to cause a subroutine or procedure to execute in another
address space (commonly on another computer on a shared network). An RPC is M code that can take optional
parameters to perform a task and then return either a single value or an array to the client application. In the
message sent to client applications will include the name of the requested RPC to be activated. These RPCs
are registered in the REMOTE PROCEDURE file (#8994) containing available and authorized RPCs. RPCs may
also be used in MUMPS routines to invoke remote routines in non-MUMPS modules. RPC Broker enables the
client/server system within the OSEHR environment. It enables client applications to communicate and
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 22
exchange data with M servers; in the client/server system, a Remote Procedure Call is a procedure stored on
the Server, which is executed to return data to the Client.
LESSON LEARNED: When searching OSEHR/VistA Technical, Install and Patch documentation for architectural
relevant information; we found the following search terms helpful: Package, Module, Routine, Patch, DBIA,
Integration Agreement, ICR, Journal, Toolkit, Global, Namespace, External, Internal, API and RPC.
 See http://www.va.gov/vdl/ for VistA Documentation Library (VDL).
2 Product Definition and Roadmap
This section summarizes the OSEHR Product Definition, VistA subsystems, GT.M and Caché environments, LINUX
and MS Windows platforms and optional components. It then provides the Product Roadmap.
"Product Definition" is the inventory of modules, which comprise OSEHRA/VistA, where:
 The FOIA release is the “core” set of modules.
 We flag FOIA modules, no longer used by the VA (e.g., HealtheVet)
 We list non-mumps modules used by the VA with appropriate comments.
 We list non-FOIA open-source and commercial modules used by the VA with appropriate comments/links.
 We list the 4 regional and 1 administrative class 2 modules with appropriate comments.
 We list VA approved class 3 modules, used by individual hospitals with appropriate comments/links.
 We list re-factored and in-flight modules with appropriate comments.
 We list the Cache environment & related modules as the primary VA platform.
 We list the GT.M environment & related modules as the available open-source platform.
 We include links to the Visual Cross Reference tool, source code/package directory, documentation Wikis,
discussion groups, tests and entries per package.
Note that a particular build will require the selection of a subset from the OSEHRA/VistA Product Definition; as an
example there may be alternative modules, which do the same function (e’g’, graphical user interfaces).
For each module, we define:
 Module grouping (e.g., Clinical, Admin/Finance/ HealtheVet)
 Class (e.g., 1, 2, 3)
 Core FOIA (yes/no)
 Module Name
 FOIA Package Name)
 Version
 Namespace
 Patch Number
 Comment
Appendix A provides a complete listing of the OSEHRA/VistA Product Definition.
The “Product Roadmap” is planned to be initially defined in March 2012 to cover:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 23






Modernization of VistA (main road)
Better GT.M support (branch)
VA hospital definitions (branch)
iEHR transition (branch)
Vender code alternatives/unification (branch)
Other branches
2.1 OSEHR Components
class OSEHR Product Definition
VistA 1.0:
Clinical
OSEHR
VistA 1.0:
Infrastructure
has-a
has-a
37
81
1
1
has-a
VistA 1.5:
HealtheVet
Database
Subsystem
has-a
12
36
runs with
Cache
runs with
0..1
0..1
has-a
GT.M
has-a
has-a
has-a
Language
Subsystem
Database
Subsystem
has-a
has-a
Utility
Subsystem
VistA 1.0:
Administrativ eFinancial
Language
Subsystem
Utility
Subsystem
runs on
runs on
MS Window s
GNU/LINUX
Figure 2-1
Open Source EHR (OSEHR) is derived from the Veterans Health Information Systems
and Technology Architecture (VistA), now known as OSEHR which is an enterprisewide information system built around an Electronic Health Record (EHR), used
throughout the United States Department of Veterans Affairs (VA) medical system,
known as the Veterans Health Administration (VHA). It's a collection of about 168
integrated software packages/modules and over twenty-six thousand software routines.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 24
The VHA was the largest single medical system in the United States, providing care to
over 4 million veterans, employing over 180,000 medical personnel and operating
approximately 163 hospitals, over 800 clinics, and 135 nursing homes. About a quarter
of the nation's population is potentially eligible for VA benefits and services because
they are veterans, family members, or survivors of veterans. By providing electronic
health records capability, VistA is thereby one of the most widely used EHRs in the
world. Nearly half of all US hospitals that have a full implementation of an EHR are VA
hospitals using VistA. This code is being make available to anyone.
Features

The Department of Veterans Affairs (VA) has had automated data processing
systems, including extensive clinical and administrative capabilities, within its
medical facilities since before 1985. Initially called the Decentralized Hospital
Computer Program (DHCP) information system, DHCP was enshrined as a recipient
of the Computerworld Smithsonian Award for best use of Information Technology in
Medicine in 1995.

VistA supports both ambulatory and inpatient care, and includes several significant
enhancements to the original DHCP system. The most significant is a graphical user
interface for clinicians known as the Computerized Patient Record System (CPRS),
which was released in 1997. In addition, VistA includes computerized order entry,
bar code medication administration, electronic prescribing and clinical guidelines.

CPRS provides a client–server interface that allows health care providers to review
and update a patient's electronic medical record. This includes the ability to place
orders, including those for medications, special procedures, X-rays, nursing
interventions, diets, and laboratory tests. CPRS provides flexibility in a wide variety
of settings so that a consistent, event-driven, Windows-style interface is presented to
a broad spectrum of health care workers.

In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates
agreed on a common EHR technical architecture, data and services and exchange
standards for the joint EHR system (aka iEHR), where the joint EHR will include both
proprietary and open source software, focusing on semantic interoperability among
trading partners.
VistA/OSEHR was developed using the M or MUMPS language/database. The VA
currently runs a majority of VistA systems on the proprietary InterSystems Caché
version of MUMPS, but an open source MUMPS database engine, called GT.M, for
Linux and Unix computers can also be used. Although initially separate releases,
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 25
publicly available VistA/OSEHR distributions are now often bundled with the Caché or
GT.M database in an integrated package. This has considerably eased installation. In
addition, the free and open source nature of GT.M allows redundant and cost-effective
failsafe database implementations, increasing reliability for complex installations.
An open source project called EsiObjects has also allowed the (ANSI- Standard)
MUMPS language and database technology to evolve into a modern object-oriented
language (and persistent-object store) that can be integrated into mainstream, state-ofthe-art technologies. For the Caché MUMPS database, a similar object-oriented
extension to MUMPS called Caché ObjectScript has been developed. Both of these
have allowed development of the MUMPS database environment (by programmers)
using modern object-oriented tools.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 26
Packages/Modules
This section lists the 168 OSEHRA packages/modules,
which comprise the system codebase, documented at the
VistA Documentation Library (VDL) at
http://www.va.gov/vdl/
2.1.1
Clinical
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
Admission Discharge Transfer (ADT)
Ambulatory Care Reporting
Anticoagulation Management Tool (AMT)
Automated Service Connected Designation (ASCD)
Beneficiary Travel
Blind Rehabilitation
Care Management
Clinical Case Registries
Clinical Procedures
Clinical/Health Data Repository (CHDR)
Computerized Patient Record System (CPRS)
CPRS: Adverse Reaction Tracking (ART)
CPRS: Authorization Subscription Utility (ASU)
CPRS: Clinical Reminders
CPRS: Consult/Request Tracking
CPRS: Health Summary
CPRS: Problem List
CPRS: Text Integration Utility (TIU)
Dentistry
Electronic Wait List
Emergency Department Integration Software (EDIS)
Functional Independence Measurement (FIM)
Group Notes
HDR - Historical (HDR-Hx)
Home Based Primary Care (HBPC)
Home Telehealth
Immunology Case Registry (ICR)
Incomplete Records Tracking (IRT)
Intake and Output
Laboratory
Laboratory: Anatomic Pathology
Laboratory: Blood Bank
Laboratory: Blood Bank Workarounds
Laboratory: Electronic Data Interchange (LEDI)
Laboratory: Emerging Pathogens Initiative (EPI)
Laboratory: Howdy Computerized Phlebotomy Login
Process
37. Laboratory: National Laboratory Tests (NLT)
Documents and LOINC Request Form
38. Laboratory: Point of Care (POC)
www.oserha.org
39. Laboratory: Universal Interface
40. Laboratory: VistA Blood Establishment Computer
Software (VBECS)
41. Lexicon Utility
42. Medicine
43. Mental Health
44. Methicillin Resistant Staph Aurerus (MRSA)
45. Mobile Electronic Documentation (MED)
46. Nationwide Health Information Network Adapter
(NHIN)
47. Nursing
48. Nutrition and Food Service (NFS)
49. Oncology
50. Patient Appointment Info. Transmission (PAIT)
51. Patient Assessment Documentation Package (PADP)
52. Patient Care Encounter (PCE)
53. Patient Record Flags
54. Pharm: Automatic Replenish / Ward Stock (AR/WS)
55. Pharm: Bar Code Medication Administration (BCMA)
56. Pharm: Benefits Management (PBM)
57. Pharm: Consolidated Mail Outpatient Pharmacy
58. Pharm: Controlled Substances
59. Pharm: Data Management (PDM)
60. Pharm: Drug Accountability
61. Pharm: Inpatient Medications
62. Pharm: National Drug File (NDF)
63. Pharm: Outpatient Pharmacy
64. Pharm: Prescription Practices (PPP)
65. Primary Care Management Module (PCMM)
66. Prosthetics
67. Quality Audiology and Speech Analysis and Reporting
(QUASAR)
68. Radiology / Nuclear Medicine
69. RAI/MDS
70. Remote Order Entry System (ROES)
71. Scheduling
72. Shift Handoff Tool
73. Social Work
74. Spinal Cord Dysfunction
75. Standards & Terminology Services (STS)
76. Surgery
77. VistA Imaging System
78. VistAWeb
79. Visual Impairment Service Team (VIST)
80. Vitals / Measurements
81. Womens’ Health
OSEHR System-Architecture, Product Definition and Roadmap
Page 27
2.1.2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
Capacity Management Tools
Duplicate Record Merge: Patient Merge
Electronic Error and Enhancement Reporting (E3R)
Enterprise Exception Log Service (EELS)
FatKAAT
FileMan
FileMan Delphi Components (FMDC)
Health Data Informatics
HL7 (VistA Messaging)
Institution File Redesign (IFR)
KAAJEE
Kernel
Kernel Delphi Components (KDC)
Kernel Toolkit
Kernel Unwinder
List Manager
MailMan
Master Patient Index (MPI)
Medical Domain Web Services (MDWS)
M-to-M Broker
Name Standardization
National Online Information Sharing (NOIS)
National Patch Module
Network Health Exchange (NHE)
Patient Data Exchange (PDX)
Remote Procedure Call (RPC) Broker
Resource Usage Monitor
Single Signon/User Context (SSO/UC)
SlotMaster (Kernel ZSLOT)
SQL Interface (SQLI)
Standard Files and Tables
Statistical Analysis of Global Growth (SAGG)
Survey Generator
System Toolkit (STK)
VistA Data Extraction Framework (VDEF)
VistALink
XML Parser (VistA)
2.1.3
1.
2.
3.
4.
5.
6.
7.
8.
Infrastructure
Financial-Administrative
Accounts Receivable (AR)
Auto Safety Incident Surv Track System (ASISTS)
Automated Information Collection System (AICS)
Automated Medical Information Exchange (AMIE)
Clinical Monitoring System
Compensation Pension Records Interchange (CAPRI)
Current Procedural Terminology (CPT)
Decision Support System (DSS) Extracts
www.oserha.org
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
Diagnostic Related Group (DRG) Grouper
Electronic Claims Management Engine (ECME)
Engineering (AEMS / MERS)
Enrollment Application System
Equipment / Turn-In Request
Event Capture
Fee Basis
Fugitive Felon Program (FFP)
Generic Code Sheet (GCS)
Health Eligibility Center (HEC)
Hospital Inquiry (HINQ)
ICD-9-CM
IFCAP
Incident Reporting
Income Verification Match (IVM)
Integrated Billing (IB)
Integrated Patient Funds
Library
Occurrence Screen
Patient Representative
Personnel and Accounting Integrated Data (PAID)
Police and Security
Quality Management Integration Module
Record Tracking
Release of Information (ROI) Manager
Veterans Identification Card (VIC/PICS)
Voluntary Service System (VSS)
Wounded Injured and Ill Warriors
2.1.4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
HealtheVet
Clinical Information Support System (CISS)
Electronic Signature (ESig)
HealtheVet Web Services Client (HWSC)
My HealtheVet
National Utilization Management Integration (NUMI)
Occupational Health Record-keeping System (OHRS)
Patient Advocate Tracking System (PATS)
Person Services
Registries
Spinal Cord Injury and Disorders Outcomes (SCIDO)
VA Enrollment System (VES)
Veterans Personal Finance System (VPFS)
OSEHR System-Architecture, Product Definition and Roadmap
Page 28
1
2
3
4
5
6
2.2 VistA Subsystems
This section is being provided for context. OSEHR is composed of the VistA 1.0 and VistA 1.5 (also known
as HealtheVet). Section 3 documents VistA 1.0 and VistA 1.5 subsystems in detail; but, Section 3 does not
include the other subsystems overviewed in Section 2.
class VistA Subsystems
Name:
Package:
Version:
Author:
VistA Subsystems
VistA Subsystems
Dec 2011
OSEHRA
Centralized Data Repositories
VistA 1.5
Master Patient Index (MPI)
External Entities
DoD Information Sharing
VistA 1.0
Corporate Data Warehouse (CDW)
7
8
9
10
11
12
13
14
15
16
17
18
19
Health Eligibility Center (HEC)
Corporate Databases
Figure 2-2
2.2.1 Vista 1.0
Description: Veterans Health Information Systems and Technology Architecture (VistA) v. 1.0, formerly known as
DHCP (Decentralized Hospital Computer Program), is a mature, highly integrated framework of shared services that
support user applications consistently and robustly. VistA includes clinical, administrative, financial, and infrastructure
applications.
VistA 1.0 is built on a client-server architecture that links both workstations and personal computers with graphical
user interfaces at Veterans Health Administration (VHA) facilities, as well as software developed by local medical
facility staff. VistA also provides the links that allow commercial off-the-shelf software and products to be used with
existing and future VistA technologies. The Decision Support System (DSS) and other national databases that might
be derived from locally generated data lie outside the scope of VistA.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-1
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Development Language:
• MUMPS
• Delphi
Deployment Infrastructure:
• Varies by location
• 128 field Instances currently deployed
Depends On:
Health Eligibility Center
Master Patient Index (MPI)
Department of Defense (DoD) Information Sharing
• Bidirectional Health Information Exchange (BHIE)
• Clinical Data Repository/Health Data Repository (CHDR)
• Federal Health Information Exchange (FHIE)
VistA 1.5
• VA Enrollment System (VES)
• VistA Blood Establishment Computer Software (VBECS)
External Entities
• Third Party Insurance
• Veterans Benefits Administration (VBA)
Centralized Data Repositories
• HDR Historical (HDR Hx)
• HDR Interim Messaging Solution (HDR IMS)
• HDR National (HDR II)
• Health Data Repository (HDR)
The following entities depend on VistA 1.0:
VistA 1.5
• Blind Rehabilitation
• Clinical Information Support System (CISS)
• Electronic Signature (ESig)
• Kernel Authentication & Authorization for J2EE (KAAJEE)
• My HealtheVet
• National Utilization Management Integration (NUMI)
• Patient Advocate Tracking System (PATS)
• Patient Service Construct (PSC)
• Person Service Lookup (PSL)
• VistA Blood Establishment Computer Software (VBECS)
Master Patient Index (MPI)
External Entities
• Defense Finance and Accounting Service (DFAS)
• VA Nationwide Health Information Network (NHIN)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-2
64
65
66
67
68
69
70
71
72
73
74
75
76
• Veterans Benefits Administration (VBA) Master Veteran Record (MVR)
Corporate Databases
Health Eligibility Center (HEC)
Corporate Data Warehouse
Department of Defense (DoD) Information Sharing
• Bidirectional Health Information Exchange (BHIE)
• Clinical Data Repository/Health Data Repository (CHDR)
• Federal Health Information Exchange (FHIE)
• Laboratory Data Sharing Interoperability (LDSI)
Centralized Data Repositories
• HDR Historical (HDR Hx)
• HDR Interim Messaging Solution (HDR IMS)
• HDR National (HDR II)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-3
77
class VistA 1.0
Name:
Package:
Version:
Author:
VistA 1.0
VistA 1.0
Dec 2011
OSEHRA
Health Eligibility Center (HEC)
Master Patient Index (MPI)
VistA 1.5
Clinical
Corporate Databases
Financial-Administrativ e
External Entities
A
Infrastructure
Centralized Data Repositories
Corporate Data Warehouse (CDW)
DoD Information Sharing
78
79
80
81
82
83
84
85
86
87
Figure 2-3
2.2.2 Vista 1.5 (aka HealtheVet)
Description: Veterans Health Information Systems and Technology Architecture (VistA) v. 1.5 (formerly known as
HealtheVet) is a strategy developed to move VistA 1.0 toward an ideal health information system to support the
veterans, VistA 2.0. A proposed strategy has been developed for both VA and Veterans Health Administration (VHA)
needs.
The strategy is built around five major systems and integrates five cross-cutting issues:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-4
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
1. The Health Data System [health data repository (HDR)] will create a true longitudinal health care record including
data from VA and non-VA sources. The health data system will support research and population analyses, facilitate
patient access to data and sharing of information across VHA, and improve data quality and data security.
2. Provider Systems support healthcare providers' care for veterans and feed information to VistA today and the HDR
in the future. These include CPRS, VistA Imaging, Blood Bank, Pharmacy, Laboratory, Federal Health Information
Exchange (FHIE), and Scheduling.
3. Management/Financial Systems include four applications that are each ten or more years old and will be replaced:
the Financial Management System, Billing and Accounts Receivable (AR), and Fee Basis (paying providers).
4. Information and Education Systems with an emphasis on “eHealth” include prescription refills, appointments,
fillable forms online, and My HealtheVet (access to health record, online health assessment tools and high quality
health information).
5. Registration, Enrollment, and Eligibility Systems will be developed as a single, department-wide data system and
demographic database that supports registration and eligibility for the three Administrations and makes this
information more accessible and consistent.
6. Cross-Cutting Issues include the VA and VHA architectures, information security, data quality, and leadership and
management. These issues cut across all systems and ensure effective implementation and operations of the major
systems.
VistA 1.5 comprises those systems that are currently being reengineered, for which the target architecture has not
yet been defined. These systems will be in operation for some time in the future and are considered temporary
solutions.
The VistA 1.5 applications have the following characteristics:
• When implemented, each VistA 1.5 application will replace the equivalent VistA 1.0 application from which it was
transitioned.
• Some of the VistA 1.5 applications may be new applications which do not exist in VistA 1.0.
• When a Vista 1.5 application is made fully operational, the corresponding VistA 1.0 application is retired.
Programming Language:
• J2EE
• .NET
• MUMPS
Deployment Infrastructure:
• BEA WebLogic 8.1
• Oracle 10g
• Crystal Reports XI
• Crystal Enterprise 10
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-5
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
•
•
•
Business Objects Repository
IIS Server
SQL Server
Depends On:
VistA 1.0
• Admission Discharge Transfer (ADT)/Registration
• Computerized Patient Record System (CPRS)
• CPRS: Text Integration Utility (TIU)
• FileMan
• HL7 (VistA Messaging)
• Kernel
• Kernel Alerts
• Kernel Authentication & Authorization for J2EE (KAAJEE)
• Kernel Toolkit
• MailMan
• Personnel and Accounting Integrated Data (PAID)
• Remote Procedure Call (RPC) Broker
• Scheduling
• VistALink
Master Patient Index (MPI)
Health Eligibility Center (HEC)
Centralized Data Repositories
• Administrative Data Repository (ADR)
Corporate Databases
• National Patient Care Database (NPCD)
External Entities
• Internal Revenue Service (IRS)
• Social Security Administration (SSA)
The following entities depend on VistA 1.5:
VistA 1.0
• Integrated Billing (IB)
• Scheduling
Master Patient Index (MPI)
Health Eligibility Center (HEC)
Department of Defense (DoD) Information Sharing
• Laboratory Data Sharing Interoperability (LDSI)
Centralized Data Repositories
• Administrative Data Repository (ADR)
Corporate Databases
• National Patient Care Database (NPCD)
• Patient Advocate Database
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-6
176
177
178
179
180
181
182
For more information, reference:
• VA Software Document Library: http://www.va.gov/vdl/section.asp?secid=4 VA Office of Enterprise Development
(OED) Project Repository:
• Active/On-Hold/Parked Project Notebook List for HealtheVet:
http://tspr.vista.med.va.gov/warboard/HealtheVet.asp
• VistA Monograph (2009): N/A
class VistA v . 1.5
Name:
Package:
Version:
Author:
VistA v. 1.5
VistA 1.5
Dec 2011
OSEHRA
Blind
Rehabilitation/Visual
Impairment Serv ice
Team
My HealtheVet
VES-VA
Enrollment
System
183
184
185
186
187
188
189
190
191
192
193
194
CISS-Clinical
Information Support
System
NUMI-National
Utilization
Management
Integration
ESig-Electronic
Signature
HWSC-HealtheVet
Web Serv ices
Client
KAAJEE-Kernel
Authentication &
Authorization for Jav a 2
Enterprise Edition
OHRS-Occupational
Health Record-keeping
System
PATS-Patient
Adv ocate
Tracking System
PSIM-Person
Serv ice-Identy
Management
Person Serv ice
Lookup
SCIDO-Spinal
Cord Inj ury and
Disorders
Outcomes
VPFS-Veterans
Personal Finance
System
VSS-Voluntary
Serv ice System
SDS-Standard
Data Serv ice
VBECS-Laboratory:
VistA Blood
Establishment
Computer Softw are
Figure 2-4
2.2.3
Master Patient Index (MPI)
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Description: The Master Patient Index (MPI) database is the primary vehicle for assigning and maintaining unique
patient identifiers. A gateway in VistA establishes connectivity between VA Medical Center (VAMC) systems and
patient registration processes and links to the MPI for message processing and patient identification. The MPI has
been created to support maintenance of a unique patient identifier and a single master index of all Veterans Health
Administration (VHA) patients and to allow messaging of patient information among the institutional partners [i.e.,
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-7
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
VHA, Veterans Benefits Administration (VBA), Board of Veterans Appeals (BVA), National Cemetery Service (NCS),
and Department of Defense (DoD).
The MPI maintains a central index to correctly identify each patient and track the sites of interest. MPI data is
maintained in a centralized, dynamic database that is available to meet multiple information needs across many
applications and systems. The MPI central database, located at VA Austin Information Technology Center, is
composed of a unique list of patients and a current list of systems to which each patient entry is correlated. This
enables the sharing of patient data between operationally diverse systems. Each record (or index entry) in the MPI
contains a small amount of identity/demographic data used to identify individual entries. It is primarily used by VistA
applications requiring the need to enumerate unique patients at their facilities.
The MPI assigns each patient (1) a unique patient identifier (Integration Control Number, or ICN) and (2) initially
assigns the requesting site as the Coordinating Master Of Record (CMOR), which represents the system that is
presently the authoritative source for the patient's identity data. Each index entry in the MPI also contains the
patient's identifying information (e.g., name, SSN, date of birth, gender) and a current list of facilities where the
patient has been seen. The MPI is updated as new patients are added or demographic information is updated at the
correlated system. Once a CMOR has been assigned to a patient, the MPI will only accept changes and/or updates
to patient identity information from the CMOR site. The CMOR can be changed at any time, when necessary, to
reflect the authoritative source for this data.
The Master Patient Index/Patient Demographics (MPI/PD) software enables sites to:
• Request an ICN assignment
• Query the MPI for known data
• Update the MPI when changes occur to demographic fields stored on the index itself or to other facilities and
systems of interest.
Development Language:
• MUMPS
Deployment Infrastructure:
• Research pending
Depends On:
VistA 1.0
• Admission Discharge Transfer (ADT)/Registration
• Clinical Information Resource Network (CIRN)
• FileMan
• HL7 (VistA Messaging)
• Kernel
• Kernel TaskMan
• Kernel Toolkit
• List Manager
• MailMan
• Remote Procedure Call (RPC) Broker
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-8
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
VistA 1.5
• VA Enrollment System (VES)
The following entities depend on Master Patient Index (MPI):
VistA 1.0
• Admission Discharge Transfer (ADT)/Registration
• Clinical Information Resource Network (CIRN)
• Clinical Procedures/Medicine
• Compensation Pension Records Interchange (CAPRI)/Automated Medical Information Exchange (AMIE)
• Computerized Patient Record System (CPRS)
• CPRS: Consult/Request Tracking
• Decision Support System (DSS) Extracts
• Enrollment Application System
• Fee Basis
• Home Telehealth
• Hospital Inquiry (HINQ)
• Income Verification Match (IVM)
• Integrated Billing (IB)
• Kernel Duplicate Record Merge: Patient Merge
• Kernel Toolkit
• Laboratory
• Mental Health
• Patient Appointment Information Transmission (PAIT)
• Patient Record Flags
• Pharmacy: Bar Code Medication Administration (BCMA)
• Pharmacy: Benefits Management (PBM)
• Pharmacy: Outpatient Pharmacy
• Prosthetics
• Quality Audiology Speech Analysis & Reporting (QUASAR)
• Release of Information (ROI) Manager
• Remote Order Entry System (ROES)
• Scheduling
• Surgery
• Veterans Identification Card (VIC)
• Vista Imaging System
• VistA 1.5
• Person Service Lookup v. 4.0.4.4
• Person Service Lookup v. 4.0.4.3
• Patient Service Construct v. 2.0.0.7
• Patient Service Construct v. 2.0.0.8
• My HealtheVet
• VistA Blood Establishment Computer Software (VBECS)
• Person Service Identity Management (PSIM)
Centralized Data Repositories
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-9
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
Health Data Repository (HDR)
• HDR Historical (HDR Hx)
• HDR Intermediate Messaging Solution (HDR IMS)
• HDR Clinical Data Services (CDS)
• HDR National (HDR II)
• Administrative Data Repository (ADR)
Department of Defense (DoD) Information Sharing
• Federal Health Information Exchange (FHIE)
• Bidirectional Health Information Exchange (BHIE)
• Clinical Data Repository/Health Data Repository (CHDR)
Corporate Databases
• National Database Integration (NDBI)
External Entities
• VA Nationwide Health Information Network (NHIN)
•
For more information, reference:
• VA Software Document Library (VDL): http://www.va.gov/vdl/application.asp?appid=16
• VistA Monograph (2009): http://www4.va.gov/vista_monograph/
• Office of Enterprise Development (OED) Project Repository:
• MPI FY09 Changes Project Notebook:
http://tspr.vista.med.va.gov/warbOARD/anotebk.asp?proj=1288&Type=Active
• Master Patient Index V. 1.0 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=151
• Master Patient Index / Patient Demographics Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=38
• MPI Changes – ISS Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=682
• MPI Changes – Iteration 01 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=734
• MPI Changes – Iteration 02 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=784
• MPI Changes – Iteration 03 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=954
• MPI Changes – MS Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=683
• MPI FY08 Changes Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1252
• MPI FY09 Changes Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1288
• MPI FY10 Changes Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1353
• MPI Health Eligibility Center Enumeration – MPI/HEC Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1008
• MPI Integration at HEC Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=430
• MPI Master of Record Enhancements Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=488
• MPI/PD Phase III Enhancements Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=482
• Master Patient Index (MPI) Homepage: http://vista.med.va.gov/mpi/index.asp
• Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
• National Data Systems (NDS) Master Patient Index (MPI) website:
http://vaww4.va.gov/NDS/MasterPatientIndex.asp
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-10
class Master Patient Index (MPI)
Name:
Package:
Version:
Author:
Master Patient Index (MPI)
Master Patient Index (MPI)
Dec 2011
OSEHRA
Centralized Data Repositories
VistA 1.0
DoD Information Sharing
Master Patient Index (MPI)
VistA 1.5
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
Figure 2-5
2.2.4
Health Eligibility Center (HEC)
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Description: The Health Eligibility Center (HEC) v. 1.0 supports VA's health care enrollment system while providing
centralized eligibility verification and determination services. This office supports VA by verifying veterans' eligibility
and processing enrollment applications. The HEC supports, coordinates, and implements VHA's financial
assessment process, consolidating financial eligibility determinations for VA health care.
The HEC also:
• Conducts VHA's income verification process for veterans whose financial assessments exempt them from
medical care co-payments
• Validates Social Security numbers from the Social Security Administration
• Verifies income from the Internal Revenue Service and the Social Security Administration
• Receives information from VBA to determine Veterans’ eligibility and enrollment assignment
• Implements information system enhancements to support CBO vision of application, eligibility and enrollment
processing
• Assists in the maintenance of the Enrollment Database by performing data management functions focused on
improving the integrity of veterans' personal, eligibility, and financial information
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-11
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
•
•
Is the authoritative source and Data Steward for Demographic, Eligibility, and Enrollment data. This does not
include Patient Identity elements.
Provides Business oversight to all software products related to Registration, Eligibility and Enrollment.
The HEC recently deployed Enrollment System Redesign (ESR) version 3.0, the HealtheVet replacement system for
the current product known as HEC Legacy. This expert system gathers information obtained from VistA, VBA, and
the HEC staff to determine and communicate verified medical benefits eligibility and enrollment (E&E) information for
all veterans and beneficiaries. For every exception where the expert system process cannot make a determination,
“cases” are created for human intervention. HEC staff utilizes ESR to manage these “cases” to completion so that
verified E&E can be determined.
The HEC, located in Atlanta, GA, receives patient-reported Means Test data from the VistA 1.0 Income Verification
Match (IVM) module. HEC compares the extracted data with earned and unearned income data retrieved from Social
Security Administration (SSA) and Internal Revenue Service (IRS). Patients with reported income in the mandatory
category, but whose actual income has been proven to be above that level, will have their eligibility for health care
changed to the discretionary category and are subject to back billing.
The HEC sends the updated demographic and insurance information to the medical facilities for upload. The IVM
module allows the HEC data to be compared with locally collected data and selectively uploaded. Local revenue staff
may then send healthcare claims to insurance companies for treatment rendered to patients who had not previously
reported health insurance coverage. Updated and verified income information from the HEC is automatically
uploaded upon receipt at each VA facility, which updates the veteran’s eligibility for health care and creates copayment charges for previous episodes of care.
Programming Language:
• J2EE
• Spring Framework
• Struts Framework
• Hibernate Framework
• JRules
Deployment Infrastructure:
• WebLogic Server
Depends On:
VistA 1.0
• FileMan
• Income Verification Match (IVM)
• MailMan
VistA 1.5
• Person Service Identity Management (PSIM)
• VA Enrollment System (VES)
External Entities
• Social Security Administration (SSA)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-12
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
•
Internal Revenue Service (IRS)
The following entities depend on Health Eligibility Center (HEC):
VistA 1.0
• Research pending
External Entities
• Social Security Administration (SSA)
• Internal Revenue Service (IRS)
VistA 1.5
• Person Services Identity Management (PSIM)
Master Patient Index (MPI)
Centralized Data Repositories
Administrative Data Repository (ADR)
For more information, reference:
• VA Software Document Library (VDL): http://www.va.gov/vdl/application.asp?appid=143
• Office of Enterprise Development (OED) Project Repository:
• HEC Redesign – Version 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=504
• HEC Redesign – Version 2 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=602
• HEC Redesign – Version 3 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=737
• HEC VistA Enhancements (HVE) Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=843
• HEC HL7 Upgrade Phase 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=359
• Enrollment System Redesign (ESR) – Version 3.0 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=884
• Enrollment System Redesign (ESR) – Version 3.1 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1174
• Enrollment System Redesign (ESR) – Version 3.2 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1275
• Enrollment System Redesign (ESR) – Version 3.3 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1286
• Enrollment System Redesign (ESR)-V4.0 IVM Workflow Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1030
• Enrollment VistA Changes (EVC) Early Release Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1009
• Enrollment VistA Changes (EVC) Release 1 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=951
• Enrollment VistA Changes (EVC) Release 2 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=982
• Enrollment Priority 8 Enhancements Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1292
• VistA Enrollment Database Standards and Procedures:
http://tspr.vista.med.va.gov/warboard/ProjectDocs/HEC_Redesign_V1/HEC%20Redesign%20Database%2
0Stds%20&%20Procs.doc#_Toc517162753
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-13
436
437
438
439
440
441
Enrollment System Redesign Project Overview:
http://tspr.vista.med.va.gov/warboard/ProjectDocs%5CEnrollment_System_Redesign_Ver_3.0%5CESR%2
0Overview%208-23-2005.pdf
Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
Health Eligibility Center (HEC) Homepage: http://vaww.va.gov/hec/
•
•
•
class Health Eligibility Center (HEC)
Name:
Package:
Version:
Author:
Health Eligibility Center (HEC)
Health Eligibility Center (HEC)
Dec 2011
OSEHRA
External Entities
VistA 1.5
VistA 1.0
Health Eligibility Center (HEC)
Master Patient Index (MPI)
442
443
444
445
446
447
448
449
450
451
452
453
454
455
Figure 2-6
2.2.5
External Entities
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Description: This diagram is a visual representation of the entities external to the Department of Veterans Affairs
(VA) Office of Information and Technology (OI&T) that receive VistA data.
Depends On:
VistA 1.0
VistA 1.5
Health Eligibility Center (HEC)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-14
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
Department of Defense (DoD) Information Sharing
• Clinical Data Repository / Health Data Repository (CHDR)
• Laboratory Data Sharing Interoperability (LDSI)
• Bidirectional Health Information Exchange (BHIE)
Master Patient Index (MPI)
The following entities depend on External Entities:
VistA 1.0
• Hospital Inquiry (HINQ)
Health Eligibility Center (HEC)
Department of Defense (DoD) Information Sharing
• Federal Health Information Exchange (FHIE)
• Clinical Data Repository / Health Data Repository (CHDR)
• Laboratory Data Sharing Interoperability (LDSI)
• Bidirectional Health Information Exchange (BHIE)
VistA 1.5
• VA Enrollment System (VES)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-15
class External Entities
Name:
Package:
Version:
Author:
External Entities
External Entities
Dec 2011
OSEHRA
Node
Department of
Defense (DoD)
Node Social
Security
Administration
(SSA)
Node Internal
Rev enue Serv ice
Node Third Party
Insurance
«flow»
«flow»
«flow»
«flow»
DoD Information Sharing
«flow»
«flow»
Master Patient Index (MPI)
Health Eligibility Center (HEC)
«flow»
Node Defense
Finance and
Accounting
Serv ice (DFAS)
VistA 1.5
«flow»
VistA 1.0
«flow»
Node Veterans
Benefits
Administration
(VBA)
«flow»
«flow»
«flow»
«flow»
Node National
Change of
Address
474
475
476
477
478
479
480
481
482
483
484
485
486
«flow»
Node Veterans
Benefits
Administration
(VBA) Master
Veteran Record
(MVR)
Corporate Databases
Node VA
Nationw ide
Health
Information
Netw ork (NHIN)
Figure 2-7
2.2.6
DoD Information Sharing
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
.
Description: The VA/DoD Health IT Sharing (HITS) Program Office reports to the Chief Officer, Health Systems
Information Management & Technology, in the VHA Office of Information (OI) and directly supports the VA mission
and efforts to promote quality healthcare for veterans and eligible service members including National Guard soldiers
and reservists. The VA/DoD Health IT Sharing Program was launched in 2000 and elevated to full Program Status in
May 2004.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-16
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
The program serves as an umbrella organization responsible for the oversight and coordination of VA/DoD health IT
projects and programs within VA. These projects fall within the VA/DoD Joint Electronic Records Interoperability
(JEHRI) strategy.
Specific objectives of the JEHRI strategy include:
• Identifying opportunities for VA/DoD collaboration and cooperation
• Supporting the seamless transition of veterans from military service through the provision of high-quality health
information technology solutions
• Facilitating and supporting the development of mutually beneficial health information technology sharing
agreements between VHA and the Military Health System (MHS)
The VA/DoD Interoperability suite of systems is comprised of:
• FHIE - One-way enterprise exchange of text data
• BHIE - Bidirectional real-time exchange of text data
• CHDR - Bidirectional real-time enterprise exchange of computable data
Programming Language:
• MUMPS
• Oracle 10
• JDK
• J2EE
Deployment Infrastructure:
• Oracle
• Windows 2000
• HP-UX
• Research pending
Depends On:
VistA 1.0
• Admission Discharge Transfer (ADT)/Registration
• Compensation Pension Records Interchange (CAPRI)/Automated Medical Information Exchange (AMIE)
• Computerized Patient Record System (CPRS)
• Kernel
• Laboratory (Laboratory Electronic Data Interchange (LEDI))
• Surgery
• VistALink
• VistAWeb
• Vitals/Measurements
VistA 1.5
• KAAJEE
• Person Service Identity Management (PSIM)
• Person Service Lookup (PSL)
Master Patient Index (MPI)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-17
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
Centralized Data Repositories
• Health Data Repository (HDR)
• HDR National (HDR II)
• HDR Clinical Data Service (CDS)
• HDR Historical (HDR Hx)
• HDR Intermediate Messaging Solution (HDR IMS)
External Entities
• Department of Defense (DoD)
The following entities depend on Department of Defense (DoD) Information Sharing:
VistA 1.0
• Computerized Patient Record System (CPRS)
• Laboratory (Laboratory Electronic Data Interchange (LEDI))
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistAWeb
External Entities
• Department of Defense (DoD)
For more information, reference:
• VA Software Document Library (VDL): N/A
• VA Office of Enterprise Development (OED) Project Repository: N/A
• VistA Monograph (2009): http://www4.va.gov/vista_monograph/
• VA/DoD Health IT Sharing Program Homepage: http://vaww1.va.gov/vadodhealthitsharing/
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-18
class DoD Information Sharing
Name:
Package:
Version:
Author:
DoD Information Sharing
DoD Information Sharing
Dec 2011
OSEHRA
VistA 1.0
Bi-Directional Health Information Exchange (BH I E)
Laboratory Data Sharing and Interoperability (LDSI)
Master Patient Index (MPI)
External Entities
Federal Health Information Exchange (FHIE)
VistA 1.5
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
Clinical Health Data Repository (CHDR)
Centralized Data Repositories
Figure 2-8
2.2.7
Corporate Databases
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Description: The figure is a visual representation of the corporate databases external to VistA 1.0. This list is
comprised of information provided in the VHA Corporate Database Monograph, through code-level research
conducted by the Analysts Office, and by a review of application-specific documentation in the VA Software
Document Library (VDL) (VDL). Included are the VHA databases that comprise the national consolidation of
information from VHA's integrated hospital information systems.
Depends Upon:
VistA 1.0
• Accounts Receivable (AR)
• Admission Discharge Transfer (ADT)/Registration
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-19
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
• Ambulatory Care Reporting
• Automated Safety Incident Surveillance and Tracking System (ASISTS)
• Capacity Management Tools
• Clinical Case Registries
• CPRS: Clinical Reminders
• CPRS: Health Summary
• Decision Support System (DSS) Extracts
• Dentistry
• Electronic Wait List
• Engineering
• Fee Basis
• Generic Code Sheet (GCS)
• Home Based Primary Care (HBPC)
• Incident Reporting
• Integrated Funds Distribution, Control Point Activity, Accounting and Procurement (IFCAP)
• Laboratory
• Master Patient Index (MPI)
• Mental Health
• National Prosthetics Patient Database (NPPD)
• Oncology
• Patient Care Encounter (PCE)
• Pharmacy: Benefits Management (PBM)
• Pharmacy: Outpatient Pharmacy
• Prosthetics
• Quality Audiology Speech Analysis & Reporting (QUASAR)
• Remote Order Entry System (ROES)
• Scheduling
• Spinal Cord Dysfunction
• Suicide Hotline
• Surgery
• Veterans Identification Card (VIC)
VistA 1.5
• Patient Advocate Tracking System (PATS)
• VA Enrollment System (VES)
The following entities depend on Corporate Databases:
VistA 1.0
• Decision Support System (DSS) Extracts
Corporate Data Warehouse (CDW)
External Entities
• Occupational Safety and Health Administration (OSHA)
• Department of Labor
VistA 1.5
• VA Enrollment System (VES)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-20
616
617
618
619
For more information, reference:
Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
class Corporate Databases
Name:
Package:
Version:
Author:
Corporate Databases
Corporate Databases
Dec 2011
OSEHRA
Clinical
Financial-Administrativ e
Infrastructure
A
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
Figure 2-9
2.2.8
Centralized Data Repositories
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Description: The Centralized Data Repositories are defined as stores of clinical and administrative information that
reside on one or more independent platforms and are used by clinicians and other personnel to facilitate longitudinal
patient-centric care. The data in the repositories will be retrieved from existing Veterans Health Information Systems
and Technology Architecture (VistA) and re-engineered package files and organized in a format that supports the
delivery of care, regardless of the patient's location or where they have been treated in the past.
Programming Language:
• Oracle
• J2EE
Deployment Infrastructure:
• Oracle 11g
• Unix
Depends On:
VistA 1.0
• Computerized Patient Record System (CPRS)
• CPRS: Adverse Reaction Tracking
• HL7 (VistA Messaging)
• Laboratory
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistA Data Extraction Framework (VDEF)
• VistAWeb
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-21
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
• Vitals/Measurements
VistA 1.5
• Person Service Identity Management (PSIM)
• Standard Data Service (SDS)
• VA Enrollment System (VES)
Master Patient Index (MPI)
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Health Eligibility Center (HEC)
The following entities depend on Centralized Data Repositories:
VistA 1.0
• HomeTelehealth
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistAWeb
VistA 1.5
• My HealtheVet
• Person Services Identity Management (PSIM)
• VA Enrollment System (VES)
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Corporate Data Warehouse (CDW)
Health Eligibility Center (HEC)
For more information, reference:
• VA Software Document Library (VDL): N/A
• VA Office of Enterprise Development (OED) Project Repository: N/A
• VistA Monograph (2009): N/A
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-22
class Centralized Data Repositories
Name:
Package:
Version:
Author:
Centralized Data Repositories
Centralized Data Repositories
Dec 2011
OSEHRA
Health Data Repository (HDR)
DoD Information Sharing
VistA 1.0
Corporate Data Warehouse (CDW)
Administrativ e Data Repository (ADR)
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
Master Patient Index (MPI)
VistA 1.5
Health Eligibility Center (HEC)
Figure 2-10
2.2.9
Health Data Repository (HDR)
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Centralized Data Repositories
Package Health Data Repository (PHDR)
Health Data Repository (HDR)
Description : The Health Data Repository (HDR) is a national, clinical data storehouse which supports integrated,
computable and/or viewable access to the patient’s longitudinal health record. The HDR will be the authoritative
source of veterans’ clinical data when complete, and currently serves as the authoritative source for data from
Department of Defense (DoD) Clinical Data Repository (CHDR) and for the Home TeleHealth Program.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-23
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
The data in the HDR is retrieved from existing Veterans Health Information Systems and Technology Architecture
(VistA) and re-engineered clinical package files and organized in a format that supports the delivery of care,
regardless of the patient's location or where they have been treated in the past.
The overarching business need for the HDR is the integration of clinical patient data from across VA, as well as from
participating external health care systems. Health care providers, including direct care providers within and outside of
the VA, business office personnel, researchers, and management staff all require integrated clinical patient data to
provide and improve health care delivery to veterans. This functionality does not currently exist in VistA, and is a
cornerstone for the next generation HealtheVet. The long-term goal of the HDR project is to deploy one national
database of all required clinical data and a required number of regional databases that support re-engineering
applications as a transactional database.
Programming Language:
• Oracle
• J2EE
Deployment Infrastructure:
• Oracle 11g
• Unix
Depends On:
VistA 1.0
• Computerized Patient Record System (CPRS)
• CPRS: Adverse Reaction Tracking
• HL7 (VistA Messaging)
• Laboratory
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistA Data Extraction Framework (VDEF)
• VistAWeb
• Vitals/Measurements
VistA 1.5
• Person Service Identity Management (PSIM)
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Master Patient Index (MPI)
The following entities depend on Health Data Repository (HDR):
VistA 1.0
• Computerized Patient Record System (CPRS)
• HomeTelehealth
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistAWeb
VistA 1.5
• My HealtheVet
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-24
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Corporate Data Warehouse (CDW)
For more information, reference:
• VA Software Document Library (VDL): N/A
• VA Office of Enterprise Development (OED) Project Repository:
• Health Data Repository Project Notebook List:
http://tspr.vista.med.va.gov/warboard/GlobalGroup.asp?group=17
• ADR/HDR Data Migration Initiative Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1093&Type=Active
• VistA Monograph (2009): http://www4.va.gov/vista_monograph/
• Corporate Database Monograph (2009): http://www4.va.gov/vista_monograph/
• Health Data Repository Homepage: http://vaww.vista.med.va.gov/hdr/index.html
• Additional online resources:
• Health Data Repository Overview: http://vaww.vista.med.va.gov/hdr/HDR_SLC_Mtg_with_HISEB.pdf
• HDR Domains at a Glance: http://vaww.vista.med.va.gov/hdr/Domains_at_a_glance.pdf
• HDR Project Overview PowerPoint:
http://vista.med.va.gov/training_lib/brown_bags/related_documents/brown_bag-hdr_overview_prototype_8-2702.ppt#256,1,Slide
• Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-25
class Health Data Repository (HDR)
Name:
Package:
Version:
Author:
Health Data Repository (HDR)
Health Data Repository (HDR)
Dec 2011
OSEHRA
HDR-Health Data Repository
Corporate Data Warehouse
(CDW)
HDR Interim Messaging
Serv ice (IMS)
HDR-Hx HDR Historical
HDR II
VistA 1.0
HDR Clinical Data Serv ices (CDS)
Master Patient Index (MPI)
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
DoD Information Sharing
Figure 2-11
2.2.9.1
HDR Clinical Data Services (CDS)
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Centralized Data Repositories::Health Data Repository (HDR)
Package HDR Clinical Data Services (CDS)
HDR Clinical Data Services (CDS) v. 1.0
HDR Clinical Data Services (CDS) v. 2.1.2
Description: HDR Clinical Data Services (CDS) is a subproject of the Health Data Repository (HDR) project. Under
the HealtheVet strategy, CDS is designated to be the authoritative data service for HealtheVet applications and
services. HealtheVet-VistA applications and services are defined as new and reengineered applications and services,
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-26
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
developed within the context of HealtheVet-VistA strategy, which will be used by the Veterans Health Administration
(VHA) to assist in the delivery of healthcare to its patients.
CDS supplies read and write services to HDR data that is nationalized (patient data collected from all applicable and
accessible sources of clinical data, regardless of site of treatment), patient-centric (directly-related to an individual
patient, not reference data), clinical (used for patient care), and viewable (needed by applications other than the
application that generated the data). There are many other enterprise initiatives defined to support data that does not
fit into the definition of nationalized, patient-centric, clinical viewable data. Non-patient clinical reference data will be
managed by the Enterprise Terminology Services (ETS) project, non-clinical data will be managed by the
Administrative Data Repository (ADR), and that clinical data that is non-nationalized and non-viewable will be
managed by the application that owns this data.
CDS also provides HealtheVet applications with data access to VistA; however, CDS is one of many ways to access
VistA clinical data and is not the exclusive, authoritative service for VistA data.
CDS v. 1.0 supports the HDR IMS application, while CDS v. 2.1.2 supports the HDR II application.
CDS is deployed at the Hines Information Technology Center (HITC) in Hines, Illinois.
Programming Language:
• J2EE
Deployment Infrastructure:
• Linux
Depends On:
VistA 1.0
• Computerized Patient Record System (CPRS)
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistAWeb
Centralized Data Repositories
• Health Data Repository (HDR)
• HDR Historical (HDR Hx)
• HDR Interim Messaging Solution (HDR IMS)
• HDR National (HDR II)
VistA 1.5
• Person Service Identity Management (PSIM)
Master Patient Index (MPI)
The following entities depend on HDR Clinical Data Service (CDS):
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Centralized Data Repositories
• Health Data Repository (HDR)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-27
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
•
HDR National (HDR II)
For more information, reference:
• VA Software Document Library (VDL): N/A
• VA Office of Enterprise Development (OED) Project Repository:
• HDR II Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=918
• Clinical Data Services Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=962&Type=Active
• VistA Monograph (2009): http://www4.va.gov/vista_monograph/
• HDR II and Clinical Data Service (CDS) Documentation Webpage:
http://vaww.vista.med.va.gov/hdr/HDR_II_Documents.html
• HDR PowerPoint Presentation: http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf
• HDR Overview: http://vaww.vista.med.va.gov/hdr/HDR_SLC_Mtg_with_HISEB.pdf
• Clinical Data Service (CDS) Vision Document:
http://vaww.vista.med.va.gov/hdr/HDR_II_Documents/CDS_Vision_Document.pdf
• Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
class HDR Clinical Data Serv ices (CDS)
Name:
Package:
Version:
Author:
HDR Clinical Data Services (CDS)
HDR Clinical Data Services (CDS)
Dec 2011
OSEHRA
HDR-Health Data Repository
HDR-Health Data Repository
HDR II
HDR Clinical Data Serv ices
(CDS)
HDR Interim
Messaging Serv ice
(IMS)
VistA 1.0
VistA 1.5
HDR-Health Data Repository
HDR-Hx HDR Historical
Master Patient Index (MPI)
836
837
838
DoD Information Sharing
Figure 2-12
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-28
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
2.2.9.2
HDR Historical (HDR-Hx)
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Centralized Data Repositories::Health Data Repository (HDR)
Package HDR Historical (HDR Hx)
HDR Historical (HDR Hx)
** Please note, this information was gathered via documentation found in the Office of Enterprise Development
(OED) Project Repository, the VistA Monograph, and the HDR Hx Homepage. As the Analysts Office did not receive
feedback from the HDR Historical points of contact, this information has not been verified.
Description: HDR Historical (HDR Hx) stores all clinical data from VistA not contained in HDR IMS and not identified
for inclusion in HDR II. It provides historical clinical data in a computable and/or viewable access form to user
interfaces such as RDI, CHDR and VistAWeb to support patient care.
HDR Hx extracts and stores legacy data from 128 VistA systems to a relational database in the Austin Information
Technology Center (AITC). The data is viewable from the HDR Hx database via Remote Data Views (RDV) in CPRS.
HDR Hx allows sites to archive and purge selected data in local databases. The historical data provided by HDR Hx
is combined with other HDR data for use across the organization to facilitate patient care, clinical decision support,
and research activities.
Programming Language:
• Research pending
Deployment Infrastructure:
• Oracle 11g
• Unix
Depends On:
VistA 1.0
• Computerized Patient Record System (CPRS)
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Master Patient Index (MPI)
The following entities depend on HDR Historical (HDR Hx):
VistA 1.0
• VistAWeb
Centralized Data Repositories
• HDR Clinical Data Services (CDS) v. 1.0
• HDR National (HDR II)
Corporate Data Warehouse (CDW)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-29
883
884
885
886
887
888
889
890
891
892
893
894
895
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
For more information, reference:
• VA Software Document Library (VDL): N/A
• VA Office of Enterprise Development (OED) Project Repository:
• HDR Historical Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=909
• VistA Monograph (2009): http://www4.va.gov/vista_monograph/
• Health Data Repository Hx Homepage: http://vaww.vista.med.va.gov/hdr/HDR_Hx_Documents.html
• Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
• Health Data Repository PowerPoint Presentation:
http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf
class HDR-Hx HDR Historical
Name:
Package:
Version:
Author:
HDR-Hx HDR Historical
HDR-Hx HDR Historical
Dec 2011
OSEHRA
HDR-Health Data
Repository
HDR Clinical Data
Serv ices (CDS)
HDR-Hx HDR Historical
Corporate Databases
VistA 1.0
Master Patient Index (MPI)
896
897
898
899
900
901
902
HDR II
DoD Information Sharing
Figure 2-13
2.2.9.3
HDR II
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-30
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
Centralized Data Repositories::Health Data Repository (HDR)
Package HDR National (HDR II) v. 2.1.2
HDR National (HDR II) v. 2.1.2
Description: The ultimate database solution, HDR II, is a relational database that replaces HDR IMS, and stores
discrete data rather than messages. It enables providers to obtain integrated data views and acquire the patientspecific clinical information needed to support treatment decisions. HDR II serves as the primary source of clinical
data for the legal medical record. It maintains data supporting core business functions and serves as a platform for
new and re-engineered HealtheVet applications.
Currently, HDR IMS and HDR II are both deployed.
HDR II is housed at the Austin Information Technology Center (AITC) in Austin, TX.
Programming Language:
• J2EE
Deployment Infrastructure:
• Research pending
Depends On:
Centralized Data Repositories
• Health Data Repository (HDR)
• HDR Clinical Data Services (CDS)
• HDR Historical (HDR Hx)
VistA 1.0
• CPRS: Adverse Reaction Tracking
• HL7 (VistA Messaging)
• Laboratory
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• Vitals/Measurements
• VistA Data Extraction Framework (VDEF)
Master Patient Index (MPI)
The following entities depend on HDR National (HDR II):
VistA 1.0
• Home Telehealth
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistAWeb
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Centralized Data Repositories
• Health Data Repository (HDR)
• HDR Clinical Data Service (CDS) 2.1.2
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-31
947
948
949
950
951
952
953
954
For more information, reference:
• VA Software Document Library (VDL): N/A
• VA Office of Enterprise Development Project Repository:
• HDR II Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=918&Type=Active
• VistA Monograph (2009): http://www4.va.gov/vista_monograph/
• Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
class HDR II
Name:
Package:
Version:
Author:
HDR II
HDR II
Dec 2011
OSEHRA
HDR-Health Data Repository
HDR Clinical Data Serv ices (CDS)
HDR II
HDR-Hx HDR
Historical
VistA 1.0
DoD Information Sharing
Master Patient Index (MPI)
955
956
957
958
959
960
961
962
963
964
965
Figure 2-14
2.2.9.4
HDR Interim Messaging Service (IMS)
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Centralized Data Repositories::Health Data Repository (HDR)
Package HDR Interim Messaging Solution (IMS)
HDR Interim Messaging Solution (HDR IMS)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-32
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
Description: HDR Interim Messaging Solution (HDR IMS) is an interim solution built to store data triggered from the
current VistA systems to a centralized database while the HDR II solution is designed and implemented. Components
of the Federal Health Information Exchange (FHIE) framework were reused as part of the interim solution. The HDR
IMS was used as the VA database for the CHDR prototype (September 2004) to demonstrate data interfacing
between DoD and VA. HDR IMS serves as the national database for storing information from Home TeleHealth. HDR
data is visible from CPRS; VistAWeb is used to support Order Checks via the Remote Data Interoperability (RDI)
subset of Pharmacy: Outpatient Pharmacy.
HDR IMS stores clinical data in a standard messaging format (HL7) from all VistA systems for a select number of
clinical domains (vitals, outpatient pharmacy, allergies). It provides patient-centric data in a computable form to user
interfaces such as Remote Data Interoperability (RDI), Clinical Health Data Repository (CHDR), Home Telehealth,
and VistAWeb to support patient care.
The production environment is established at the Austin Information Technology Center (AITC).
Programming Language:
• Java
• Oracle
Deployment Infrastructure:
• Unix
Depends On:
VistA 1.0
• HL7 (VistA Messaging)
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistA Data Extraction Framework (VDEF)
Master Patient Index (MPI)
The following entities depend on HDR Interim Messaging Solution (HDR IMS):
VistA 1.0
• Home Telehealth
• Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
• VistAWeb
Department of Defense (DoD) Information Sharing
• Clinical Data Repository/Health Data Repository (CHDR)
Centralized Data Repositories
• HDR Clinical Data Service (HDR CDS)
For more information, reference:
• VA Software Document Library (VDL): N/A
• VA Office of Enterprise Development (OED) Project Repository:
• HDR Interim Messaging Solution (IMS) Project Notebook
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=910
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-33
1010
1011
1012
1013
1014
1015
1016
1017
1018
•
•
•
•
•
VistA Monograph (2009): http://www4.va.gov/vista_monograph/
HDR Interim Messaging Solution (HDR IMS) Documentation Webpage:
http://vaww.vista.med.va.gov/hdr/HDR_IMS_Documents.html
Health Data Systems Health Data Repository Fact Sheet:
http://vaww.vista.med.va.gov/hdr/HDR_Fact_Sheet.pdf
Health Data Repository PowerPoint Presentation::
http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf
Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
class HDR Interim Messaging Serv ice (IMS)
Name:
Package:
Version:
Author:
HDR Interim Messaging Service (IMS)
HDR Interim Messaging Service (IMS)
Dec 2011
OSEHRA
HDR Clinical Data
Serv ices (CDS)
Master Patient Index (MPI)
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
HDR-Health Data
Repository
HDR Interim
Messaging
Serv ice (IMS)
DoD Information Sharing
VistA 1.0
Figure 2-15
2.2.10 Corporate Data Warehouse (CDW)
THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
NO DETAILED DOCUMENTATION WILL BE PROVIDED.
Description: The Veterans Health Administration (VHA) has created a corporate data warehouse specifically
designed to facilitate business analysis. The purpose of this corporate data warehouse is to integrate information
across many segments of the organization. This integrated environment will provide the foundation upon which
analytical tools are applied to answer business questions and pursue clinical research.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-34
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
The Corporate Data Warehouse (CDW) is a business driven information repository useful to key business
stakeholders for strategic decision making. The information in the data warehouse is integrated, consistent, detailed,
historical, cross-geographic, and cross-functional/cross-LOB (e.g., clinical, financial, administrative, research, public
health, education, policy, performance and quality, patient safety, emergency management, surveillance). The CDW
is an enterprise asset encompassing multiple subject areas and potentially enabling multiple departments/lines of
business within VHA. Since CDW is an enterprise information asset, the information in the CDW is driven by strategic
business drivers that enable betterment of process outcomes.
CDW is dependent upon the National Patient Care Database (NPCD) which is housed at the AITC.
The infrastructure, including necessary system and support personnel components, are deployed in the Austin
Information Technology Center.
Programming Language:
• SQL
Deployment Infrastructure:
• SQL Servers
• IIS Servers
Depends On:
VistA 1.0
• Decision Support System (DSS) Extracts
Centralized Data Repositories
• Health Data Repository (HDR)
• HDR Historical (HDR Hx)
Corporate Databases
• National Patient Care Database (NPCD)
The following entities depend on Corporate Data Warehouse (CDW):
• None
For more information, reference:
VA Software Document Library (VDL): N/A
VA Office of Enterprise Development (OED) Project Repository: N/A
VistA Monograph (2009): N/A
Application Profile: N/A
Figure 2-16
2.3 GT.M Subsystems
GT.M, an abbreviation for Greystone Technology M, was developed by the Greystone Technology Corp in the 1980s.
It is an implementation of ANSI standard M for various UNIX systems and OpenVMS. In addition to preserving the
traditional features of M, GT.M also offers an optimizing compiler that produces object code that does not require
internal interpreters during execution.GT.M is a high-throughput key-value database engine optimized for transaction
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-35
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
processing. (It is a type also referred to as "schema-less", "schema-free," or "NoSQL.") GT.M is also an application
development platform and a compiler for the ISO standard M language, also known as MUMPS.
The database engine, made open source in 2000, is maintained by Fidelity Information Services. GT.M is used as
the backend of their FIS Profile banking application, and it powers ING DIRECT banks in the United States, Canada,
Spain, France and Italy. It is also used as an open source backend for the Electronic Health Record system
WorldVistA and other open source EHRs such as Medsphere's OpenVista. It is listed as an open source healthcare
solution partner of Red Hat. Today it consists of approximately 2 million lines of code.GT.M consists of a language
subsystem, a database subsystem, and utility programs. The language subsystem and database subsystem are
closely integrated, but each is usable without the other. The language and database subsystems share common data
organization and typing.
On GNU/Linux on x86-64 & IA-32 (x86), and on OpenVMS on Alpha/AXP, GT.M is released as Free / Open Source
Software (FOSS) under the terms of the GNU Affero General Public License, version 3. On other platforms, it is
available under proprietary licenses.
See http://tinco.pair.com/bhaskar/gtm/doc/books/ao/OpenVMS_manual/titlepage.html for GT.M Administration and
Operations Guide.
2.3.1 GT.M Language Subsystem
Unlike the database where global variable nodes must fit within a database block, local variable strings can grow to
1MB. The GT.M run-time provides dynamic storage allocation with garbage collection. The number of local variables
and the number of nodes in local variables are limited only by storage available to the process. The default scope of
a local variable is the lifetime of a process. Local variables created within routines using the New command have
more limited scope.
GT.M routines are dynamically compiled and linked for execution in the address space of each process. With the
exception of the 32-bit implementation of GT.M for the x86 GNU/Linux platform, object modules can also be placed in
shared libraries with the standard ld command, in which case the memory used is shared. This is important because
an application such as OSEHR has over 20,000 routines whose compiled object code exceeds 200MB. A large
hospital running OSEHR can have thousands of concurrently running user processes.
With a couple of small exceptions, GT.M includes a nearly complete implementation of ISO standard M
(affectionately known as MUMPS for historical reasons). In GT.M, M code can freely call out to C code (or code in
other languages with a C compatible interface), and C code can freely call in to M code (so the top level program can
be a C main()). For example is a GT.M module in CPAN and m_python for access from Python.
Web services written in GT.M can be deployed under an Internet super server such as inetd or xinetd. Web enabled
applications can use layered software such as EWD.
2.3.2 GT.M Database Subsystem
The logical database of a GT.M process consists of one or more global variable name spaces, each consisting of
unlimited number of global variables. For each global variable name space, a global directory maps global variables
to the database files where they actually reside. An unlimited number of global variables can fit within one database
file; a global variable must fit in one database file.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-36
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
A database file consists of up to 224M (276,168,704) database blocks. A database block is a multiple of 512 bytes,
with a maximum size of 65,024 bytes. Commonly used block sizes are 4KB, 8KB and 16KB - so, with an 8KB block
size, an individual global variable can grow to 1,792GB. A global variable node (global variable, subscripts plus
value) must fit in one database block and each block has a 16 byte overhead. So, the largest node that will fit in a
database with a 4KB block size is 4,080 bytes. A key (global variable plus subscripts) can be up to 255 bytes.
The database engine is daemonless and processes accessing the database operate with normal user and group ids a process has access to a database file if and only if the ownership and permissions of that database file (plus any
layered access control such as SELinux permits access). Each process has within its address space all the logic
needed to manage the database, and processes cooperate with one another to manage database files. When a
database file is journaled, updates are written to journal files before being written to database files, and in the event
of a system crash, database files can be recovered from journal files.
In GT.M, M code can freely call out to C code (or code in other languages with a C compatible interface), and C code
can freely call in to M code (so the top level program can be a C main()). For example is a GT.M module in CPAN
and m_python for access from Python. Web services written in GT.M can be deployed under an Internet super server
such as inetd or xinetd. Web enabled applications can use layered software such as EWD.
2.3.3 GT.M Tools and Utility Subsystem
GT.M provides utility programs to administer the system. All GT.M utilities follow the OpenVMS Command Definition
conventions so that the user interface is consistent with other OpenVMS system components. All the utilities use the
standard OpenVMS HELP facility.Each utility is summarized below.
GDE
The Global Directory Editor (GDE) is a GT.M utility program that creates and maintains global directories. GDE
provides commands for operating on the global directory.
MUPIP
MUPIP (M Peripheral Interchange Program) is the GT.M utility program for general database operations, GT.M
Journaling, Multi-site Database Replication, and some non-database operations.
The MUPIP commands are:

BACKUP: Backup database files

CONVERT: Converts M routines from a sequential "%RO" format into GT.M source files.

CREATE: Create and initialize database files.

EXIT: <CTRL-Z> terminates MUPIP and returns control to the process from which MUPIP was invoked.

EXTEND: Expand the size of a database file.

EXTRACT: Export data from database files into sequential (flat) files.

FREEZE: Prevent updates to database files.

INTEG: Check the integrity of GDS databases.

INTRPT: Send an asynchronous signal to a GT.M process.

JOURNAL: Recover database files (for example, after a system crash) and extract journal records.

LOAD: Import data into databases.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-37
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207






REORG: Defragment database files to improve performance.
REPLICATE: Controls the operation of GT.M database replication from a primary instance to one or multiple
instances.
RESTORE: Restore databases from bytestream backup files.
RUNDOWN: Properly close database files when processes terminate incorrectly.
SET: Modify database and/or journal file characteristics.
STOP: Stop GT.M processes.
LKE
The M Lock Utility (LKE) is the GT.M utility program that examines and modifies the lock space where GT.M
maintains the current M LOCK state. LKE can monitor the locking mechanism and remove locks.
Database Structure Editor (DSE)
The Database Structure Editor (DSE) is the GT.M utility program to examine and alter the internal database
structures. DSE edits GT.M Database Structure (GDS) files. It provides an extensive database "patch" facility
(including block integrity checks), searches for block numbers and nodes, and provides symbolic examination and
manipulation facilities. See Chapter 10: “Database Structure Editor” for more information.
2.3.4 GT.M-LINUX Operating System
GT.M is fully supported on GNU/Linux on Itanium, x86_64 and IA-32 (x86) architectures. On GNU/Linux on the IA-32
(x86) architecture, GT.M is a 32-bit application; on all others, it is a 64-bit application. The code base for GT.M on
GNU/Linux on IA-32 (x86) includes changes needed to run on Cygwin on Microsoft Windows but this is not yet
considered a supported platform.
Linux is a computer operating system which is based on free and open source software. Although many different
varieties of Linux exist, all are Unix-like and based on the Linux kernel, an operating system kernel created in 1992
by Linus Torvalds.
Linux can be installed on a wide variety of computer hardware, ranging from mobile phones, tablet computers,
routers and video game consoles, to desktop computers, mainframes and supercomputers. Linux is a leading server
operating system, and runs the 10 fastest supercomputers in the world.
The development of Linux is one of the most prominent examples of free and open source software collaboration;
typically all the underlying source code can be used, freely modified, and redistributed, both commercially and noncommercially, by anyone under licenses such as the GNU General Public License. Typically Linux is packaged in a
format known as a Linux distribution for desktop and server use. Some popular mainstream Linux distributions
include Debian (and its derivatives such as Ubuntu), Fedora and openSUSE. Linux distributions include the Linux
kernel, supporting utilities and libraries and usually a large amount of application software to fulfill the distribution's
intended use.
The name "Linux" comes from the Linux kernel, originally written in 1991 by Linus Torvalds. The main supporting
user space system tools and libraries from the GNU Project (announced in 1983 by Richard Stallman) are the basis
for the Free Software Foundation's preferred name GNU/Linux.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-38
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
2.3.5 Other (Optional) GT.M/LINUX Components
A distribution oriented toward desktop use may include the X Window System, the GNOME and KDE Plasma
desktop environments. Other distributions may include a less resource intensive desktop such as LXDE or Xfce for
use on older or less-powerful computers. A distribution intended to run as a server may omit any graphical
environment from the standard install and instead include other software such as the Apache HTTP Server and a
SSH server like OpenSSH. Because Linux is freely redistributable, it is possible for anyone to create a distribution for
any intended use. Commonly used applications with desktop Linux systems include the Mozilla Firefox web browser,
the OpenOffice.org or LibreOffice office application suites, and the GIMP image editor.
M2Web is an open source web gateway to MUMPS for use with OSEHR. A free open source module from
M/Gateway called MGWSI has been developed to act as a gateway between GT.M, Cache, or M21 MUMPS
databases and programming tools such as PHP, ASP.NET, or Java, in order to create a web-based interface.
2.4 Caché Subsystems
Caché is a Database Management System and application development environment, much like many in the MultiValue market. The database is often referenced like a relational data source, making it popular among SQL users,
but the internal structure is similar to MultiValue. The standard environment comes with a browser-based
administration dashboard, a development “Studio,” and an assortment of tools for browser UI development, web
services, Java, .NET, XML, etc..
Caché was originally based on MUMPS. This database has a history remarkably similar to that of Pick and Prime.
Our communities have similar passions for the power and simplicity of our chosen models. The markets were
similarly fractionalized with competing products. Even today a few versions of MUMPS exist, just as there are many
flavors of MultiValue. But InterSystems has largely consolidated that market. At a time when many MultiValue people
still feel a little haunted by their heritage (think foot pedals, rap singers, and software that changes ownership every
few years) most Caché people I’ve met are proud to acknowledge their roots. It’s not that their core technology has
changed so much, though Caché is a significant improvement over its predecessors, but that InterSystems has
fostered the validation of their technology in the eyes of the business and technical world.
Today, the Caché environment is associated with industry buzzwords like Post-Relational and Multi-Dimensional—
terms also used to describe the MultiValue model. Caché is best regarded as an Object Oriented DBMS. This is not
the same as Object-Relational which, while sounding more tech-savvy, is considered to be a weaker paradigm.
The OO-based Caché has native support for data objects and related code within the environment itself. Compare
this to API connectivity to a flat relational environment from OO languages. I will explain more about this objectorientation in another article. However it’s categorized, Caché is fairly well recognized due to ongoing marketing
campaigns by InterSystems. The database is featured in many IT and business magazines, articles, and success
stories. It’s noted for performance, scalability, reliability, and tight security. In short, Caché is a proven and accepted
mainstream platform, and now for our purposes it is also a MultiValue DBMS.
See http://docs.intersystems.com/ for Caché documentation
2.4.1
Caché Development Environment
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-39
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
Caché Studio
Caché Studio is the primary development environment for Caché. The Studio lets you create class definitions, Caché
Server Pages, and routines using a full-featured editor. Studio includes sophisticated syntax checking and coloring,
graphical debugging, and a point-and-click class inspector. Caché Studio works directly with the Caché database (it
is a Caché application) and offers multideveloper support as well as source control system integration. You can
customize Studio through the use of Studio templates. For more information, see Using Caché Studio.
2.4.2 Caché Database Subsystem
Caché is designed to transcend the limitations of the relational model while providing an evolutionary upgrade path
for the thousands of existing relational database applications as well as support for the many SQL-based reporting
tools on the market. In addition to being a high-performance object database, Caché is also a full-featured relational
database. All the data within a Caché database is available as true relational tables and can be queried and modified
using standard SQL via ODBC, JDBC, or object methods. Because of the power of the underlying Caché database
engine, we believe that Caché is the fastest, most reliable, and most scalable relational database available today.
What’s more, Caché offers a range of features that go beyond the limits of relational databases, while still supporting
a standard relational view of data. These features include:
– The ability to model data as objects (each with an automatically created and synchronized native relational
representation) while eliminating both the impedance mismatch between databases and object-oriented
application environments as well as reducing the complexity of relational modeling.
– A simpler, object-based concurrency model.
– User-defined data types.
– The ability to take advantage of methods and inheritance, including polymorphism, within the database
engine.
– Object-extensions for SQL to handle object identity and relationships.
– The ability to intermix SQL and object-based access within a single application, using each for what they are
best suited.
– Control over the physical layout and clustering used to store data in order to ensure the maximum
performance for applications.
While most databases with both object and relational access provide one form of access on top of the other, the SQL
and object aspects of Caché both go directly to the data — so that users enjoy the performance benefit of either
approach.
2.4.3 Caché Tools and Utilities Subsystem
Caché includes a number of application development tools as well as database administration utilities. On a Windows
system, these are accessible from the Caché cube icon within the Windows task bar. (Right-click on the icon. If you
do not see this icon, open the Windows Start menu, find the Caché folder under Programs, and click on the Caché
entry.) The various graphical utilities are client/server applications whose clients run on Windows systems but can be
used with remote Windows, Linux, UNIX®, and OpenVMS server systems.
The Caché development tools and utilities include:
Management Portal
The Management Portal provides a Web-based interface for managing a Caché site. The Portal includes tools for
system administrators, security managers, database operators, and any others needing access to Caché. Its
administrative features allow you to set up a Caché system, view and alter its configuration parameters, adjust
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-40
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
system settings, and create and edit databases and namespaces. Its database-browsing features include the ability
to browse the contents of a Caché database, to examine data (globals) in the data engine; and to browse classes
and routines — as well as monitoring database activity and performing backup operations. Its security-related
features allow you to add, alter, and remove users, roles, resources, privileges, and to perform other security
management tasks. Its SQL-related features provide a graphical, SQL-based view of a Caché database; you can use
it to manage SQL roles and permissions, browse table and view definitions, execute ad hoc SQL queries, manage
the query cache, and import and export data. For more information, see Caché System Administration Guide.
Caché Terminal
Caché Terminal provides an interactive, command-line interface to Caché. You can use Terminal for direct
interactions with the Caché database engine. The Terminal is an important tool for testing and troubleshooting
applications. For information, see the manual Using Caché Terminal.
Caché DocBook
The Caché DocBook application provides a fully searchable, Web-based interface to the documentation for Caché or
any other installed InterSystems product. For an introduction to this application, see the “Basic Features” chapter of
Using InterSystems Documentation.
2.4.4 Caché-Windows Operating System
The NT family of Windows systems was fashioned and marketed for higher reliability business use. The first release
was NT 3.1 (1993), numbered "3.1" to match the consumer Windows version, which was followed by NT 3.5 (1994),
NT 3.51 (1995), NT 4.0 (1996), and Windows 2000, which is the last NT-based Windows release that does not
include Microsoft Product Activation. Windows NT 4.0 was the first in this line to implement the "Windows 95" user
interface (and the first to include Windows 95’s built-in 32-bit runtimes).
Microsoft then moved to combine their consumer and business operating systems with Windows XP that was
released in August 2001. It came both in home and professional versions (and later niche market versions for tablet
PCs and media centers); they also diverged release schedules for server operating systems. Windows Server 2003,
released a year and a half after Windows XP, brought Windows Server up to date with Windows XP. After a lengthy
development process, Windows Vista was released toward the end of 2006, and its server counterpart, Windows
Server 2008 was released in early 2008. On July 22, 2009, Windows 7 and Windows Server 2008 R2 were released
as RTM (release to manufacturing). Windows 7 was released on October 22, 2009.
64-bit operating systems
Windows NT included support for several different platforms before the x86-based personal computer became
dominant in the professional world. Versions of NT from 3.1 to 4.0 variously supported PowerPC, DEC Alpha and
MIPS R4000, some of which were 64-bit processors, although the operating system treated them as 32-bit
processors.
With the introduction of the Intel Itanium architecture (also known as IA-64), Microsoft released new versions of
Windows to support it. Itanium versions of Windows XP and Windows Server 2003 were released at the same time
as their mainstream x86 (32-bit) counterparts. On April 25, 2005, Microsoft released Windows XP Professional x64
Edition and Windows Server 2003 x64 Editions to support the x86-64 (or x64 in Microsoft terminology) architecture.
Microsoft dropped support for the Itanium version of Windows XP in 2005. Windows Vista was the first end-user
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-41
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
version of Windows that Microsoft released simultaneously in x86 and x64 editions. Windows Vista does not support
the Itanium architecture. The modern 64-bit Windows family comprises AMD64/Intel64 versions of Windows 7 and
Windows Server 2008, in both Itanium and x64 editions. Windows Server 2008 R2 drops the 32-bit version, although
Windows 7 does not.
Microsoft Windows CE 5.0
Windows CE (officially known as Windows Embedded Compact), is an edition of Windows that runs on minimalistic
computers, like satellite navigation systems and some mobile phones. Windows Embedded Compact is based on its
own dedicated kernel, dubbed Windows CE kernel. Microsoft licenses Windows CE to OEMs and device makers.
The OEMs and device makers can modify and create their own user interfaces and experiences, while Windows CE
provides the technical foundation to do so.
Windows CE was used in the Dreamcast along with Sega's own proprietary OS for the console. Windows CE is the
core from which Windows Mobile is derived. Microsoft's latest mobile OS, Windows Phone 7, is based on
components from both Windows CE 6.0 R3 and the upcoming Windows CE 7.0.
Windows Embedded Compact is not to be confused with Windows XP Embedded or Windows NT 4.0 Embedded,
modular editions of Windows based on Windows NT kernel.
Future of Windows
Windows 8, the successor to Windows 7, is currently in development. Microsoft has stated that Windows 8 will be
released late in 2012. Also, during the pre-Consumer Electronics Show keynote, Microsoft's CEO announced that
Windows 8 will also run on ARM CPUs. Since ARM CPUs are usually in the form of SOCs found in mobile devices,
this new announcement implies that Windows 8 will be more compatible with mobile devices such as netbooks, tablet
personal computers, and smartphones.
2.4.5 Other (Optional) Caché/Windows Components
An open source project called EsiObjects has also allowed the (ANSI- Standard) MUMPS language and database
technology to evolve into a modern object-oriented language (and persistent-object store) that can be integrated into
mainstream, state-of-the-art technologies. For the Caché MUMPS database, a similar object-oriented extension to
MUMPS called Caché ObjectScript has been developed. Both of these have allowed development of the MUMPS
database environment (by programmers) using modern object-oriented tools.
2.5 Product Roadmap
An inclusive product roadmap cannot be done for this December 2011 deliverable. See the Section 2.5.3 Plan of
Actions and Milestones for details.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-42
1377
2.5.1
2011 System Architecture (Conceptual View)
VistA “Front End”
ANSI MUMPS (M)
Graphical User
Interfaces GUIs)
Applications
APIs
M
Global
Access
RPCs
APIs
RPC
APIs
APIs
Kernel/Tools
FileMan
RPC Broker
VistALink
M Global Access
VistA “Database”
ANSI MUMPS (M)
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
InterSystems Cache (Win)
GT.M (Linux-UNIX)
M Global
Files
Figure 2-13 Conceptual View of Legacy VistA System Architecture
Figure 2-1 shows a conceptual view of the 2011 OSEHR system architecture. Legacy OSEHR is predominantly
coded in Ansi MUMPS (M) and can be run within the open source GT.M Linux/UNIX environment or within the
InterSystems Cache Windows environment. At the conceptual level, OSEHR has the following major components:
 Applications, such as Scheduling, Pharmacy (Rx), Laboratory, Radiology, ADT plus 100+ other packages
 Kernel/Tools, such as Security, Menu Management, TaskMan, MailMan, Package Manager, etc.
 FileMan, which contains set of APIs, search, inquire, edit, print, utility functions, data dictionary utilities,
transfer entries, etc.
 “Database”, which is composed of FileMan, which manages the M global namespaces and the Data
Dictionary, which defines OSEHR’s hierarchical file layout for Apps., Rx, Lab, Images, Common Data, Plus
over 100+ other files.
Typically, each OSEHR application module generates at-least-one global data file. Within these files are the clinical,
administrative, and computer infrastructure-related information that supports day-to-day operations and contain
patients' medical and healthcare utilization histories, including data on demographics, episodes of care, medicines,
practitioner information, diagnoses, procedures.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-43
1397
2.5.2
Future-State Architecture (Conceptual View)
iEHR is interoperable Electronic Healthcare Record
iEHR Tier 1
Front End Systems
iEHR Common Data implies the native use of a single logical
database, based on the CIIF Information Model and
Terminology Models.
Presentation/ Business Rules
Applications/ Business Services
ESB is Enterprise Service Bus.
CIIF is Common Information Interoperability Framework
Business
Services
Security Controls support the NIST 7497 Security
Architecture Design Process for Health Information
Exchanges (HIEs) and DoD 8500 (series) Information
Assurance controls.
Applications
BITE is Built-In-Test-Environment for performance and
payload-data-integrity testing of ad-hoc trading-partners and
plug-and-play applications; BITE uses Schematron.
Virtualization-Layer of Federated
Standards-Based Services
Schematron is a rule-based validation language.
VLER is Virtual Lifetime Electronic Record
NwHIN is Nationwide Health Information Network
VLER
Security
Controls
iEHR Tier 2
ESB Broker
Service
Registry
CIIF
Run Time
iEHR
Gateway
Common
Common
Services
Common
Services
Services
NwHIN Gateway
Secure
Standards-Based
Information Exchanges
St Elsewhere
SSA / CMS
...
SSA is Social Security Administration
CMS is Center for Medicare and Medicaid Services
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
Dynamic
Translator for
Structures,
Codes &
Versions
CIIF
Design-Time
Terminology
Services
BITE
Services
Workbench of
Model Driven
Health Tools (MDHTs)
Metadata
Services
Metadata
Services
Schema
Services
Performance
Caches
MDR
MDR is Meta Data Repository
Information
Model
Metadata and rules
Virtualization-Layer of Federated
Standards-Based Services
iEHR Tier 3
Back End Systems
iEHR Common Data (CIIF Schemas)
Federated/Virtual Data
Legacy Data
Data
Services
Data
Stores
Terminolgy
Models
SNOMED CT and Extensions,
LOINC and RxNorm
Payload = service, message.
Document or application-interface
information exchange content.
Translation
Models
Payload Models
Payload Schemas
BITE Schematron
Figure 2-12 Future-State Architectural Vision
The future-state architectural vision presented here:
• is a pragmatic, but, non-prescriptive starting point, which will be adjusted, based on open-source
community’s feedback.
• maintains interoperability with the legacy MUMPS and the DoD-VA iEHR architectural vision as well as
accommodating commercial vendors.
• Is based on standards to create virtual service layers of Application Program Interfaces (APIs) that support
plug-and-play applications (e.g., the smartphone application market model) and various data repositories,
ranging from single or client-server systems’ MUMPS FileMan to federated systems feeding a high
performance Healthcare Data Repositories.
• foster innovation at the component level and encourages Darwinian selection among competing
components based on user’s cost, performance and support preferences.
• can support
– legacy or modern hardware and software platforms, languages, applications and databases.
– scalability from minimal-cost individual-clinician-systems to enterprise-massively-parallel highperformance grids running on commodity-hardware-platforms (e.g., amazon.com, google.com models).
The key points of Figure 2-12 are:
 The joint DoD-VA iEHR Way modernization initiative’s Common Information Interoperability Framework (CIIF)
information exchange component will be determined collaboratively with the VLER VCA1 Final Operational
Capability (FOC) effort. The objective of the joint DoD-VA EHRWF modernization initiative is to establish the
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-44
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463










capability to manage and maintain a lifelong Electronic Medical Record. The EHRWF initiative defines a
Common Information Interoperability Framework (CIIF) to facilitate appropriate semantic interoperability among
DoD, VA and partner EHR repositories. The EHRWF shall use Federally validated standards, particularly
SNOMED-CT (the Systematic NOMenclature of MEDicine, Clinical Terms), combined with a Federally
standardized clinical information model. Together these two components comprise the EHRWF Common
Information Interoperability Format, or CIIF. While the CIIF is under development and in its early deployment,
there may be a *gradual* VLER VCA1 transition to use CIIF prior to VCA1 December 2012 FOC as the DoD and
VA transition to a common EHR environment.
The Nationwide Health Information Network (NwHIN) is within VLER
Applications-database decoupling
iEHR 3-tier extendible architecture
Use of Open Health Tools’ Model Driven Health Tools (MDHTs)
CIIF is key to semantic interoperability
CIIF Run-Time environment within iEHR
CIIF Design-Time environment with-respect-to iEHR Run-Time
BITE to facilitate performance & payload-data-integrity testing
NIST 7497 Security Architecture Design Process for Health Information Exchanges (HIEs)
DoD 8500 (series) Information Assurance Controls
The following problems are being addressed by the future-state architecture:
1. Innovation to revitalize OSEHR. Services within a standards-based component-architecture encourage lowercost component innovation without requiring enterprise-wide expertise and extensive testing. SDK empowers
individuals and avoids stovepipes.
2. Interoperability among DoD, VA, IHS and purchased care partners. CIIF canonical information and
terminology models can be used to map among heterogeneous system information exchanges. By adopting
common CIIF data, terminology, and communications standards; multiple organizations can share and ultimately
harmonize Electronic Medical Records.
3. Transition from legacy systems and data to an interoperable EHR architecture. Virtualization-Layers of
Federated Standards-Based Services allow new and legacy COTS, GOTS and open-source applications,
scaleable databases and infrastructure to coexist.
4. Agility to respond to rapid healthcare changes and related legislation. Services within a standards-based
component-architecture encourage faster and lower-cost changes to be made and tested within components
without requiring enterprise-wide expertise and testing.
5. High Costs of change and sustainment. Virtualization-Layers of Federated Standards-Based Services make
plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and can
be tested efficiently. Interchangeable-components can compete based, on functionality, quality, performance vs.
cost, usability and supportability. Built In Test Environment (BITE) identifies faults early, improving robustness
and reducing test costs. .
6. Patient Safety issues resulting from software changes. Component architecture localizes faults. BITE
identifies faults early, improving system robustness, patient safety.
7. Open Source Community Enablement Virtualization-Layers of Federated Standards-Based Services support
alternate configurations of applications, databases and infrastructure, which may be combinations of MUMPS,
COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-45
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
2.5.3 Plan of Actions and Milestones (POA&M)
We had 30 days to produce the first OSEHR system architecture contract deliverable. To achieve this first deliverable
we had an architecture team do a “time boxed” first pass through the 168 OSEHR packages/routines, based on the
online OSEHR documentation library. We intend to continue to verify, validate and refine the fidelity of the 2011
system architecture as we move to specifying the future-state Interoperable EHR (iEHR) architectural roadmap. We
will further expand on the following:
 key features/attributes of As-Is and To-be, which are briefly covered in Sections 2.5.1 and 2.5.2.
 What are some major differences between the 2011 and future-state architectures? Why the difference? Is
it historic? What requirements are driving the changes?
o These are briefly covered in Section 2.5.2.
 What is to be changed? What will be added? What will be deleted or replaced? From an architectural
perspective, what is the priority of changes?
o Briefly, the highest priority is to transition to a 3-tiered architecture with a well specified Software
Development Kit (SDK)
 What is the implications of these changes or additions? Would the changes become useful incrementally or
do we have to wait till a lot of changes are implemented before they useful?
o Briefly, going to a 3-tiered architecture with well specified service layers, allows innovation at the
module level, rather than globally, which is the current situation.
 What would be a good sequence of changes/addtions from an architectural perspective? Ar serial changes
and parallel activities possible?
o Once the 3-tierd architecture is established, then parallel development/procurement becomes
practical.
 How will we track changes in architecture during this project.
o Briefly, The tool can filter and show 2011 views versus “Future State” views
 How can this document be used to track changes in architecture?
o Briefly, as we go forward, we will show the 2011 views, Future State views and any transition views
in the Roadmap.
Following is the year “1” OSEHRA System Architecture (SA) and Product Definition (PD) POA&M
 17 Jun 11 – Custodial Agent contract signed
 17 Aug 11 – OSEHRA Custodial Agent established as a non-profit organization
 17 Sep 11 – Phase 1: 2011 Initial Baseline
o Based on VistA Documentation Library
o 168 Modules modeled as UML Class Elements, including
 Module descriptions
 Module functions/features included in descriptions
 Module-module install dependencies
 Module-data dependencies
o SA Report delivered as Contract Deliverable (CDRL)
o HTML web browsable SA on OSEHRA web site
o Task 5.9 2011 System Architecture Baseline CDRL
 Combined Task 5.9 SA & Task 5.11 PD Report
o Task 5.11 2011 Product Baseline (Build Definition) CDRL
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-46
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551





 Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
Sep-Dec - OSEHRA website periodically updated as Phase 2 work is done.
o Community SA and PD Discussions Forums
o Cleanup-tasks
 De-conflict duplicate namespaces and duplicate modules
 Add master list of Namespaces, based on VA internal feedbach.
 Investigate modules without documentation
 Harmonize ICRs (aka DBIAs) across SA, based on VA internal documentation
 Add missing APIs, RPCs and Component Diagrams
 Add patchs to module-diagrams and map patches-to-modules
 Map Namespaces-to-modules and visa-versa
 Incorporate Xindex mapping of modules-to-routines and modules-to-data files
 Create/Obtain GT.M and Cache build
 Map namespaces-to-files
 Map namespaces-to-routines
 Verify OSEHR SA versus VA Research Group architecture artifacts
o HTML web browsable SA on OSEHRA web site
17 Oct 11 – OSEHRA is Fully Operational
o Architecture Working Group (AWH) established
o SA and PD Community Forums established
06 Dec 11 - Phase 2: 2011 Verified Baseline
o 168 Modules modeled as UML Classes & Components, including
 Application Program Interfaces (APIs) modeled as UML Components
 Remote Procedure Calls (RPCs)
 Data Base Integration Agreements (DBIAs) modeled as UML Associations
 Verified Module functions/features included in descriptions
 Verified Module-module dependencies
 Verified Module-data dependencies
o Updated SA Report CDRL
 Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
o Updated HTML web browsable SA on OSEHRA web site
o Task 5.9 Updated & Verified 2011 SA Baseline
o Task 5.11 Updated & Verified 2011 PD Baseline & Roadmap
Dec-Mar - OSEHRA website periodically updated as Phase 3 work is done.
o Community SA and PD Discussions Forums
o HTML web browsable SA on OSEHRA web site
17 Mar 12 - Phase 3: iEHR 2012 Strawman Future-State Specifications
o iEHR 2012 Strawman Future-State SA is a brainstormed System Architecture intended to
generate discussion of its (dis) advantages and to provoke the generation of new and better
proposals.
o Strawman DoD-VA Interoperable EHR (iEHR) Specifications
 Using HL7 Service Aware Interoperability Framework (SAIF)
o Strawman Software Development Kit (SDK)
o Strawman SA Report CDRL
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-47
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572


 Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
o Strawman HTML web browsable SA on OSEHRA web site
o Task 5.9 Strawman 2012 Future-State System Architecture Baseline
o Task 5.11 Strawman 2012 Future-State Product Baseline & Roadmap
Mar-Jun - OSEHRA website periodically updated as Phase 4 work is done.
o Community SA and PD Discussions Forums
o HTML web browsable SA on OSEHRA web site
17 Jun 12 - Phase 4: 2012 Ironman Future-State SA Speifications
o Ironman Future-State SA Specification is a harmonized proposed System Architecture intended
to generate plans for its implementation and to provoke the generation of new and better design
specifications.
o Ironman DoD-VA iEHR Specifications
 Using HL7 SAIF
o Ironman SDK Specifications
o Ironman SA Report CDRL
 Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
o Ironman HTML web browsable SA on OSEHRA web site
o Task 5.9 Ironman 2012 Future-State SA Baseline
o Task 5.11 Ironman 2012 Product Baseline & Roadmap
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 2-48
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
3 System Architecture (SA)
The OSEHR System Architecture contains the Financial-Administrative, Infrastructure, HealteVet, Clinical subsections. First we document the OSEHR System Architecture (SA) process. The OSEHR System Architecture is a
living document, updated at least quarterly, being constructed incrementally based on the following source materials:
1. modules modeled as classes, based on VistA-HealtheVet Monograph
a. modules modeled as UML classes
b. module definitions
2. module dependency models, based on existing package documents
a. Component UML class dependencies
i. module-module dependencies
ii. module-data dependencies
iii. deployment-dependencies
3. SA Functional Models, showing modular functional-descriptions
a. based on HL7 EHR System Functional Model (EHR-S FM)
b. Including EHR-S FM conformance criteria to support test and certification
c. ARRA Meaningful use objectives and criteria
d. Applicable HHS mandated HITSP-constructs and other HHS mandated standards.
4. Verified and Validated Open Source Baseline SA Model, based on
code reviews and analysis by the Custodial Agent (CA) and open source community.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-49
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
3.1 Clinical
Clinical Health Data Systems (HDS) supports the mission of Veterans Health Information Technology (IT) by
providing complete, accessible, longitudinal, veteran-centric data to the end-user applications of the enterprise. This
work is accomplished through four major program areas:
1. Standards & Terminology Services
2. Repositories
3. Registries
4. Health IT Sharing
Standards & Terminology Services (STS) develops, implements, and maintains authoritative data standards, and
enables the interoperability and exchange of standardized and computable information between VA information
technology (IT) systems and with government and private health care partners.
The Repositories Program supports storage of enterprise-wide, veteran-centric clinical and administrative data via
the Health Data Repository (HDR) and Administrative Data Repository (ADR) products. Repository data supports
data needs of current and future VA IT software programs. The HDR Data Warehouse meets the data needs of the
VA research and analysis community without impacting database performance for the end-users.
The Registries Program supports the population-specific data needs of the enterprise including, but not limited to,
Oncology Tumor Registry, Traumatic Brain Injury Registry, Embedded Fragment Registry and Eye Trauma Registry.
The Healthcare Associated Infection and Influenza Surveillance System (HAIISS) monitors data in VA’s integrated IT
systems to identify potential disease, bioterrorism, or healthcare-associated infection outbreaks.
class Clinical
Name:
Package:
Version:
Author:
Clinical
Clinical
Dec 2011
OSEHRA
ADT/Registration
Adv erse Reaction
Tracking
AIT
AMT-Anticoagulation
Management Tool
AR/WS
ASCD
BCMA
Beneficiary Trav el
Blind
Rehabilitation/Visual
Impairment Serv ice
Team
CCR
CHDR
CPRS
Clinical Proc.
Data
Standardization
Home Telehealth
ICR
Authorization
Subscription
Utility
Clinical
Reminders
CPRS: Consult/
Request Tracking
CPRS: Health
Summary
CPRS: Problem
List
Care Management
Dentistry
EDIS
EPI
EWL
FIM
Group Notes
HBPC
HDR-Hx
IEMM
IRT
Intake & Output
LEDI
Laboratory
AP
Laboratory: Blood
Bank
Laboratory: Blood
Bank
Workarounds
UI
Lexicon Utility
MED
MRSA
Medicine
Mental Health
Nutrition Food
Serv ice
NHIN
Nursing
PAIT
PBM-Pharmacy:
Benefits
Management
Patient Care
Encounter
PCMM
PIMS/MAS
POC
PPP
CMOP
CS
Pharm Data Mgmt
DA
Inpatient
Medications
National Drug File
Outpatient
Pharmacy
Prosthetics
QUASAR
RAI/MDS
ROES
Radiology/
Nuclear Medicine
STS
Scheduling
Shift Handoff Tool
Social Work
SCD
Surgery
TBI
Terminology
Serv ices
VBECS
Visit Tracking
Imaging
VistAWeb
Vitals/
Measurements
Womens Health
TIU
ASI-MV
PRF
HDR-Health Data Repository
1619
1620
A
Laboratory:
National
Laboratory Tests
(NLT) Documents
and LOINC
Request Form
OncoTraX: Cancer
Registry
Figure: 3.1-1
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-50
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
3.1.1 ADT-Admission, Discharge, Transfer/Registration
The Admission, Discharge, Transfer (ADT) module provides a comprehensive range of software dedicated to the
support of administrative functions related to patient admission, discharge, transfer, and registration. The functions of
this package apply throughout a patient's inpatient and/or outpatient stay, from registration, eligibility determination
and Means Testing through discharge with on-line transmission of Patient Treatment File (PTF) data to the Austin
Information Technology Center (AITC).
The ADT software also aids in recovery of cost of care by supplying comprehensive PTF/RUG-II and Means Test
software. The ADT module functions as the focal collection point of patient information, encompassing demographic,
employment, insurance, and medical history data. Many other modules, such as Laboratory, Pharmacy, Radiology,
Nursing, and Dietetics, utilize information gathered through the various ADT options. Several features have been
designed to maximize efficiency and maintain control over user access of specified sensitive patient records. The
Patient Sensitivity function allows a level of security to be assigned to certain records within the database (i.e.,
records of employees, government officials, etc.) in order to maintain control over unauthorized user access. The
Patient Lookup function screens user access of these records. It also provides for efficient and faster retrieval of
patient records and identified potential duplicate patient entries. The ADT module allows for efficient and accurate
collection, maintenance, and output of patient data, thus enhancing a health care facility’s ability to provide quality
care to its patients. The functions within ADT currently fall into seven major categories: Application Processing
(registration), Bed Control (inpatient movements), Inpatient Care Grouping (DRG)/Long Term Care Grouping (RUG),
Data Transmission to National Database (PTF and RUG), Patient Assessment Instrument (PAI), Supervisor
Functions (system setup and maintenance), and Local/National Management Reporting.
Features
• Provides on-line patient registration and disposition of applications for medical care.
• Tracks patient movements during inpatient stays.
• Provides up-to-date on-line patient information.
• Generates numerous managerial and statistical reports.
• Performs patient data consistency checks.
• Supports the flagging and monitoring of patient records deemed to be sensitive.
• Enrolls patients in the VA Patient Enrollment System during the registration process.
• Uses industry standard International Classification of Diseases (ICD)/Current Procedural Terminology (CPT)
codes.
• Aids in cost recovery of care by supplying comprehensive PTF/RUG-II, Means Test, and pharmacy co-pay
software.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-51
1657
1658
1659
Figure: 3.1-3
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-52
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
ADT-Admission, Discharge, Transfer / Registration - (Component diagram)
Figure: 3.1-4
3.1.2 Ambulatory Care Reporting
The Ambulatory Care Reporting Project (ACRP) enhances the process of collecting and storing encounter-based
clinical, diagnostic, and administrative outpatient andinpatient data for daily transmission to the Austin Automation
Center (AAC).
The Ambulatory Care project will be working in concert with the National Patient Care Database project (NPCDB).
The two projects have common objectives.
• Capture and record selected demographic data about the patient
• Identify the date and time services were provided
• Identify what was done, why it was done, and who provided the services
• Move the information from VISTA to the NPCDB via an Event Driven Reporting mechanism for the purpose of
workload credit.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-53
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
Collecting more specific and encounter-based clinical, diagnostic, and administrative data will enable more detailed
analysis of VHA’s outpatient and inpatient healthcare activity. Tracking the amount of care provided across the types
of healthcare services offered will be key in the calculation of corporate costs. The information will also be a valuable
database for resource utilization studies, forecasting, and healthcare planning for the future.
All options in the ACRP Reports menu have been modified to return multiple reports when multiple divisions are
selected. For example, if you select division A and division B, the output will contain a report for division A, a report
for division B, and a report that reflects the combination of divisions A and B.
The following is a brief description of the options contained in the Ambulatory Care Reporting Menu.
ACRP Reports Menu
 ACRP Ad Hoc Report Menu
 Error Listing
 Transmission Reports
 Supervisor Ambulatory Care Menu
 Data Transmission Report
 Incomplete Encounter Management
 Retransmit Ambulatory Care Data by Date Range
 Retransmit Selected Error Code
 Selective Retransmission of NPCDB Rejections
The ACRP Interface Toolkit (AIT) is a set of programmer tools that provides access to outpatient encounter data.
This initial version contains Application Programmer Interfaces (APIs) and Remote Procedure Calls (RPCs) that
provide access to procedure, diagnosis, provider, and general data related to an encounter. It is hoped that in a
future version of the AIT, Delphi objects, components, and DLLs will be provided as well.
This AIT provides Class I packages, Class III software, and other local code with one highly structured interface to
the encounter data.
Scheduling V. 5.3
 Ambulatory Care Reporting Project (ACRP)
 Incomplete Encounter Management Module (IEMM), part of the Ambulatory Care Reporting Project (ACRP)
Phase II. Installation adds the IEMM menu to the Ambulatory Care Reporting menu. This new menu
contains the Incomplete Encounter Reports submenu and the Correct Incomplete Encounters option.
Please refer to SD*5.3*66 for a complete description of the Incomplete Encounter Management Module patch.
This package contains KIDS builds from three software packages. Minimally, the following three base packages must
be installed to install this package.
 PCE V. 1.0
 Registration V. 5.3
 Scheduling V. 5.3
Additionally, VA FileMan V. 21.0, Kernel V. 8.0, and Kernel Toolkit V. 7.3 should also be installed.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-54
Figure:
1720
1721
1722
3.1-5
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-55
1723
Ambulatory Care Reporting - (Component diagram)
cmp Ambulatory Care Reporting
AIT-Ambulatory Care Reporting Proj ect Interface Toolkit
Incomplete Encounter Management Module
Ambulatory Care Reporting Interface Toolkit (AIT)
Ambulatory Care Reporting Proj ect (ACRP)
Interface Toolkit (AIT)
January 1998
Remote Procedure Calls
SDOE Assigned a Diagnosis
SDOE Assigned a Procedure
SDOE Assigned a Provider
SDOE Find Diagnosis
SDOE Find First Encounter
SDOE Find First Standalone
SDOE Find Last Standalone
SDOE Find Procedure
SDOE Find Provider
SDOE Get Diagnoses
SDOE Get General Data
SDOE Get Primary Diagnosis
SDOE Get Procedures
SDOE Get Providers
SDOE Get Zero Node
SDOE List Encounters for Dates
SDOE List Encounters for PAT
SDOE List Encounters for Visit
SDOE Parse General Data
Introduction
Application Programmer Interfaces
56 - SDOE Get Diagnoses
58 - SDOE Get Providers
61 - SDOE Get Procedures
63 - SDOE Assigned a Provider
64 - SDOE Assigned a Diagnosis
65 - SDOE Assigned a Procedure
69 - SDOE Find Provider
70 - SDOE Find Diagnosis
71 - SDOE Find Procedure
72 - SDOE Find First Standalone
73 - SDOE Get Primary Diagnosis
74 - SDOE Find First Encounter
75 - SDOE Find Last Standalone
76 - SDOE Get General Data
78 - SDOE Parse General Data
79 - SDQ Open
80 - SDQ Close
81 - SDQ Patient
82 - SDQ Date Range
83 - SDQ Filter
84 - SDQ Visit
85 - SDQ Index Name
86 - SDQ EOF
87 - SDQ BOF
88 - SDQ Active Status
89 - SDQ Count
90 - SDQ First
91 - SDQ Last
92 - SDQ Next
93 - SDQ Prior
94 - SDQ Refresh
95 - SDQ Get Current Entry ID
98 - SDOE Get Zero Node
99 - SDQ Scan
100 - SDQ Scan Callback
101 - SDQ Error Check
1724
1725
1726
Figure: 3.1-6
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-56
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
3.1.3 AMT-Anticoagulation Management Tool
The tool enables the user to enter, review, and continuously update all information connected with patient
anticoagulation management. With the Anticoagulation Tracking, one can order lab tests, enter outside lab results
and graphically review lab data, enter notes, complete encounter data, complete the consults if consults are used to
initiate entry into the Anticoagulation clinic, and print a variety of patient letters. Upon exiting the program all activities
within the program are recorded on an Anticoagulation flow sheet maintained on the Computerized Patient Record
System (CPRS) Reports tab. The Anticoagulation Tracking provides clinic staff a mechanism of ensuring continuous
patient monitoring with a built-in mechanism that alerts staff when patients haven’t been monitored in a timely period.
A Lost to Follow-up list is maintained to ensure that staff knows of patients who need attention
Figure: 3.1-7
3.1.4 ASCD-Automated Service Connected Designation
Enhancements to the VistA Legacy Mumps application to automate the clinician’s decision-making process when
marking a patient encounter either Service Connected (SC) or Non-Service Connected (NSC) within the Patient Care
Encounter (PCE) and Scheduling packages.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-57
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
Figure: 3.1-8
3.1.5 Beneficiary Travel
The Beneficiary Travel module provides the ability to perform the functions involved in issuing beneficiary travel pay.
Travel reimbursement is provided to specified categories of eligible veterans. It is also provided to non-employee
attendants who are eligible for such reimbursement. These attendants will be issued travel pay under the veteran's
name.
Payment for travel by special mode (ambulance, handicapped van, etc.) may be authorized if medically necessary
and approved before travel begins, except in cases of medical emergency where delay would be hazardous to life or
health.
For certain claims, the system will compute the amount payable from factors such as account type, parameter set-up
of deductible amount per visit and per month, one-way or round-trip mileage, and applied costs.
Features
• Automatically computes the amount payable for claims with an account type of Compensation and Pension.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-58
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
•
•
•
Allows each site to define and edit site-specific beneficiary travel parameters.
Produces a variety of statistical reports for a specified date range.
Provides the ability to reprint the standard pre-formatted beneficiary travel form for cash reimbursement.
Figure: 3.1-9
3.1.6 Blind Rehabilitation
The Blind Rehab application provides enhanced tracking, and reporting, of the blind rehabilitation services provided
to veterans by:
• Visual Impairment Service Teams (VIST) Coordinators
• Blind Rehabilitation Centers (BRCs)
• Blind Rehabilitation Outpatient Specialists (BROS)
• Visual Impairment Services Outpatient Rehabilitation (VISOR) Programs
• Visual Impairment Center to Optimize Remaining Sight (VICTORS)
Currently, there is no VistA software that meets the needs of the Blind Rehabilitation Centers or BROS and the VIST
4.0 package only monitors, tracks, and reports on a limited amount of data for the VIST.
The site-based VIST 4.0 package is being replaced with the re-hosted Blind Rehabilitation (BR) Version 5.0
application supporting the HealtheVet-VistA enterprise architecture. In addition to providing the base functionality of
the BR 4.0 system, BR 5.0 provides a web-enabled GUI through which users can access enhanced capabilities
intended for VIST Coordinators, new functionality for BROS, BRC personnel and waiting times and waiting list.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-59
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
The Blind Rehabilitation 5.0 application provides entirely new functionality that encompasses and integrates all five
segments of the Blind Rehabilitation Services including waiting times and waiting list.
Figure: 3.1-10
3.1.7 Care Management
The Care Management project was initiated because VA healthcare professionals needed an application that could
display order and result information for a relevant panel of patients. The four applications (known as “perspectives”)
that comprise Care Management—Clinician Dashboard, Nurse Dashboard, Sign List, and Query Tool—provide a
complement to, rather than a replacement for, the single-patient view offered by the Computerized Patient Record
System (CPRS).
Key features:
• An intuitive graphical user interface (GUI)
• Pre-defined and custom patient lists to provide an at-a-glance view of multiple patients who have items that
require attention
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-60
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
•
•
•
•
Editable, linkable tasks to help track important follow-up items
A multi-patient, multi-item sign list to reduce administrative time
Color-coded icons to indicate the status of items that require attention
Flexible, pre-defined and custom reports to extract the most current data available for a variety of criteria.
Care Management Perspectives
• Clinician Dashboard The Clinician Dashboard provides clinicians with an easy-to-read table that lists patients
who have items that need attention. The table allows clinicians to quickly and easily view healthcare information.
For example, you can use the Clinician Dashboard to quickly determine which patients have order results that
should be reviewed or acknowledged, or documents that need to be signed.
• Nurse Dashboard The Nurse Dashboard provides nurses with an easy-to-read table that lists patients who have
items that require a nurse’s attention. For example, you can use the Nurse Dashboard to quickly determine
which patients have orders that need to be verified. The Nurse dashboard also displays patients’ vitals.
• Query Tool The Query Tool allows you to create reports based on patient data. You can use the five predefined
reports (Abnormal Results, Consult Status, Incomplete Orders, Recent Activity, and Scheduled/Due Activity) or
you can create a custom report.
• Sign List The Sign List allows you to sign multiple items for multiple patients. For example, using the Sign List
you could sign a discharge summary for John Smith and notes for Jane Smith simultaneously. The types of
items that appear on your Sign List depend on which dashboard you are using. Items that appear on the Sign
List for the Clinician Dashboard include unsigned and un-cosigned clinical documents. Items that appear on the
Sign List for the Nurse Dashboard include unverified orders and completed text orders.
The Care Management software package requires three separate installation procedures: one for installing Mspecific components on your M server, one for installing Java components on the HealtheVet Desktop/Care
Management server, and one for installing Java components on users’ workstations.
1826
1827
Figure: 3.1-11
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-61
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
3.1.8 Clinical Case Registries
The Clinical Case Registries (CCR) software application supports the maintenance of local and national registries for
clinical and resource tracking of care for patients with certain clinical conditions. Registries for Hepatitis C
(CCR:HEPC) and Human Immunodeficiency Virus (CCR:HIV) are available. This application allows access to
important demographic and clinical data on all VHA patients with these conditions, and provides many capabilities to
VA facilities that provide care and treatment to patients with these conditions, including clinical categorization of
patients and automatic transmission of data to the VA's National Case Registry. It also provides clinical and
administrative reports for local medical center use.
CCR accesses several other Veterans Health Information Systems and Technology Architecture (VistA) files that
contain information regarding other diagnoses, prescriptions, surgical procedures, laboratory tests, radiology exams,
patient demographics, hospital admissions, and clinical visits. This access allows identified clinical staff to take
advantage of the wealth of data supported through VistA.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-62
1841
1842
1843
1844
Figure: 3.1-12
Clinical Case Registries - (Component diagram)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-63
cmp Clinical Case Registries
Name:
Package:
Version:
Author:
Clinical Case Registries
Clinical Case Registries
1.0
Karen Kirkpatrick
Clinical Case Registries
«interface»
Clinical Case
Registries::
National CCR
Database
«interface»
Clinical Case
Registries::Med
Proc. (EKG)
«interface»
Clinical Case
Registries::
Automated
Management
Information
System
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
National CCR Database
Med Proc (EKG)
AMIS
Figure: 3.1-13
3.1.9 Clinical Procedures
Clinical Procedures (CP) is a new VistA package that provides features that can be used across clinical departments,
such as general medicine, cardiology, pulmonary, women’s health, neurology, and rehabilitation medicine. CP is a
conduit for passing patient results, using HL7 messaging, between the vendor and VistA. Patient test results are
displayed in the Computerized Patient Record System (CPRS). CP includes three modules, which are CP User, CP
Manager, and CP Gateway.
CP User is the primary application that clinicians use. For example, you can place an order for a procedure, such as
an EKG, through the Consults tab or Orders tab in CPRS, or Order Entry. Then you can use CP User to check in a
patient and initiate the actual procedure. If the procedure is performed on a bi-directional instrument, the patient
demographics are automatically transmitted to the instrument. When the procedure is complete, the result is
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-64
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
transmitted back to VistA Imaging and attached to a TIU note/document that is associated with the original procedure
order. If the procedure is performed on a uni-directional instrument, you use CP User to match the instrument results
to the requested procedure. The TIU note is created when the instrument results are submitted to VistA Imaging.
Standard Consults functionality is used to complete and sign the TIU note. The main purpose of CP User is to link the
results from the automated instrument to the procedure ordered through Consults in CPRS.
System managers and clinical application coordinators use CP Manager. The main purpose of this application [CP
Manager] is to add and edit automated instruments and procedures in the CP database. CP Manager is also used to
configure the site files and required system parameters.
CP Gateway manages the flow of information from the instrument interfaces to CPRS. CP Gateway polls the system
regularly for new data from instruments and processes this data into usable attachments for the VistA Imaging
system.
Hemodialysis is a new module [1.0*6] of the Clinical Procedures (CP) package that provides features specific to
hemodialysis treatment. Hemodialysis allows you to collect hemodialysis treatment information from the medical
device, and manually enter treatment data into the application. Pre-dialysis vitals, information obtained during
treatment, and post-dialysis vitals can be entered into the Hemodialysis data entry screens. A Treatment Summary is
created and used to fill out Centers for Medicare & Medicaid Services (CMS)/End Stage Renal Disease (ESRD)
forms.
The Clinical Flowsheets patch [1.0*16] of the Clinical Procedures (CP) package provides an electronic representation
of the traditional paper flowsheet maintained during each inpatient stay. Vitals, Intake/Output, Wound Documentation,
etc., are examples of data types that can be recorded via Clinical Flowsheets into the Veterans Health Information
System and Technology Architecture (VistA) system. Clinical Flowsheets provides a departure from its predecessor
applications by storing collected information as discrete data. Some date elements, such as vital signs, are available
to the Vitals Package and Computerized Patient Record System (CPRS). Various reports built on the other data
elements are available for CPRS in the form of Text Integration Utilities (TIU) Notes.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-65
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
Figure: 3.1-14
3.1.10 CHDR-Clinical/ Health Data Repository
The Department of Defense (DoD) and the Department of Veterans Affairs (VA) in partnership, designed and
implemented a Clinical Data Repository/Health Data Repository (CHDR) system that generates standards-based,
computable electronic health records that can be exchanged and shared between the two agencies healthcare
systems. The computable data can then be divided into fields and can be sorted, rather than provided as unsortable
text.
Medical records and patient health care histories are stored and maintained in a centralized repository at each
agency. Medical records entered and maintained in the DoD TRICARE system are stored in the Clinical Data
Repository (CDR), a component of the Armed Forces Health Longitudinal Technology Application (AHLTA). Similarly,
the VA Health Data Repository (HDR) provides a centralized storage for medical records entered and maintained in
the Veterans Health Information System and Technology Architecture (VistA) and Computerized Patient Record
System (CPRS). The CHDR system is the link between these two systems.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-66
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
CHDR works in the background to deliver improved information sharing between the DoD and VA of medical records
for Active Dual Consumers (ADC) patients. The interoperability provides clinical users at DoD and VA medical
facilities with bidirectional, real-time exchange of medical records that will include at a minimum, the exchange of
outpatient pharmacy and drug allergies (limited only to drug allergies) to enable drug/drug and drug/allergy order
checks. The integrated clinical data between the DoD and the VA (outpatient pharmacy and drug allergy data) can be
viewed in VistAWeb or CPRS Remote Data Views (RDV).
CHDR facilitates the sharing of a Virtual Lifetime Electronic Record (VLER) between DoD and the VA for our nations
Veterans. This enables the VA/VHA to provide a comprehensive integrated medical record that is compliant with the
Health Insurance Portability and Accountability Act (HIPAA) and other privacy regulations, and to facilitate a
seamless transition from military to Veteran status.
Figure: 3.1-15
3.1.11 CPRS-Computerized Patient Record System
The Computerized Patient Record System (CPRS) v. 1.0 is a Veterans Health Information Systems and Technology
Architecture (VISTA) software application. CPRS enables clinicians, nurses, clerks, and others to enter, review, and
continuously update all information connected with any patient.
[Highest revision in VA Software Document Library (vld) is OR*3.0*309. (2011_08_06)]
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-67
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
Developing a computerized patient record is a long-term goal of the Veterans Health Administration (VHA) as part of
its mission to provide high quality healthcare for America’s veterans. New information needs are emerging as VHA
continues to shift into a primary care, ambulatory healthcare delivery model. In the new clinical information
environment, all information relevant to treating any given patient will be readily available to healthcare providers,
clinical and management decision-makers, educators, and researchers through a secure platform on a need-to-know
basis.
With CPRS, care providers can quickly flip through electronic “pages” of the chart to add new orders, review or add
problems, write progress notes, or see results. Alerts, notifications, cautions, warnings, advanced directives, future
appointments, demographic data, medications, and orders are all available. Order entry now includes quick orders,
order sets, and order checking.
FAQ
Q. What is the relationship between OE/RR and CPRS? I sometimes hear references to OE/RR 3.0 and much of the
CPRS package just seems to be an enhanced OE/RR 2.5.
A. This distinction does get fuzzy at times. CPRS is the umbrella package for a much more comprehensive suite of
software. OE/RR 3.0 is a component of CPRS, and can’t be used outside of CPRS. Many of the packages contained
within CPRS still have independent lives, for use by their services for administrative and other purposes, and
occasionally to add and review orders (known as “backdoor” ordering). The CPRS documentation set mainly
documents the OE/RR portion of CPRS (files and routines in the OR, OEX, and XPAR namespaces).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-68
1945
1946
1947
Figure: 3.1-16
Documents available in the vdl:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-69
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
(http://www.va.gov/vdl/application.asp?appid=61)
Name Date Created
Last Updated

CPRS Clinician's Getting Started Guide List Manager Version
2005-03-01
2005-03-15

CPRS GUI 24: Set Up Notes for Non-VA Medications
2004-07-01
2004-12-30

CPRS GUI Version 27 (Patch OR*3.0*243) and Associated Patches Installation Guide
2008-08-20
2008-09-17

CPRS GUI Version 28 (Patch# OR*3*280) and Associated Patches Installation Guide 2011-03-07
201103-21

CPRS Patch OR*3.0*296 (CPRS GUI v.27.90) and Associated Patches Installation Guide
2009-08-27
2009-09-10

CPRS Query Installation/Implementation Guide 2003-04-28
2003-04-28

CPRS Query User Manual
2003-04-28
2004-12-30

CPRS Read-Only User Guide 2002-07-01
2004-12-30

CPRS Release Notes: GUI Version OR*3.0*190 (v.24)
2004-07-01
2004-12-30

CPRS Release Notes: GUI Version OR*3.0*195 (v.25)
2005-01-01
2005-01-31

CPRS Release Notes: GUI Version OR*3.0*215 (v.26)
2006-05-01
2006-05-01

CPRS Release Notes: GUI Version OR*3.0*243 (v.27)
2008-08-20
2009-02-05

CPRS Release Notes: GUI Version OR*3.0*280 (v.28)
2011-03-07
2011-03-07

CPRS Release Notes: GUI Version OR*3.0*296 (v.27.90) 2009-08-27
2009-08-27

CPRS Release Notes: GUI Version Patch OR*3.0*231
2005-04-01
2005-04-26

CPRS Release Notes: GUI Version Patch OR*3.0*235
2005-06-01
2005-06-20

CPRS Release Notes: GUI Version Patch OR*3.0*252
2007-05-02
2007-05-02

CPRS Release Notes: GUI Version Patch OR*3.0*258
2006-06-01
2006-06-08

CPRS Release Notes: GUI Version Patch OR*3.0*270
2007-01-23
2007-01-23

CPRS Release Notes: GUI Version Patch OR*3.0*277
2007-10-31
2007-10-31

CPRS Release Notes: GUI Version Patch OR*3.0*304
2008-11-20
2008-11-20

CPRS Technical Manual
2006-05-01
2011-04-20

CPRS Technical Manual: GUI Version 2006-05-01
2011-03-07

CPRS User Guide: GUI Version
2006-05-01
2011-04-20

CPRS-VBECS Interface (OR*3.0*212) Release Notes
2009-06-08
2009-06-08

CPRS-VBECS Interface Follow-Up Fixes (OR*3.0*309) Release Notes
2010-03-26
2010-03-26

Installation Guide
1999-07-01
2007-05-02

OR*3.0*294 Installation Guide 2011-03-03
2011-03-03

Remote Data Interoperability (OR*3.0*232) Release Notes 2007-04-13
2007-04-13

Setup Guide 2000-08-01
2011-04-20
3.1.12 CPRS: ART-Adverse Reaction Tracking
The objective of the Adverse Reaction Tracking (ART) package, is to collect, track, and report patient allergy and
adverse reaction data. This is accomplished via the four major functional areas of the package.
1. Data Entry options - ART has two options where a user can enter data.
a. Enter/Edit Patient Reaction Data - This option allows the clinical users (i.e., doctors, nurses, other clinicians and
clerks) to enter data.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-70
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
b. Verify Patient Reaction Data - This option allows the designated verifiers (e.g., clinical pharmacists) to verify the
correctness of data entered by the clinical users. This option does NOT perform evaluation of suspected Adverse
Drug Reactions (ADRs) as described in Section 5.a.(2).(d) of Directive 10-92-070.
2. Reporting options - These options report the patient causative agent data to the user via a print option. Also, this
data is made available to other software applications via a data extract utility.
3. Enter/Edit Site File Configurable Menu - This menu allows the various site configurable files to be modified to allow
ART to better meet the needs of each individual site.
4. Adverse Drug Reaction (ADR) options - These options support implementation of Directive 10-92-070. They allow
for the evaluation of a suspected ADR by a qualified individual (e.g., clinical pharmacist, clinical pharmacologist)
other than the attending physician, as specified in Section 5.a.(2).(d) of Directive 10-92-070. This component also
generates the reports needed by the Food and Drug Administration (FDA).
Figure: 3.1-17
3.1.13 CPRS: ASU-Authorization Subscription Utility
The Authorization/Subscription Utility (ASU) implements a User Class Hierarchy which is useful for identifying the
roles that different users fulfill within the hospital. It also provides tools for creating business rules that apply to
documents used by members of such groups. ASU provides a method for identifying who is AUTHORIZED to do
something (for example, sign and order). ASU originated in response to the long recognized demand for a means of
implementing the “Scope of Practice” model, which was first discussed during the analysis and design of OE/RR
v1.96, but the driving force behind its development was the complexity of Text Integration Utilities’ (TIU’s) document
definition needs. Current security key capabilities were unable to efficiently manage the needs of clinical
documentation (Discharge Summaries, Progress Notes, etc.).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-71
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
ASU Features & Benefits
• ASU lets you define, populate, and retrieve information about User Classes. These User Classes can be defined
hospital-wide or more narrowly for a specific service and can be used across VISTA to replace and/or
complement keys.
• ASU lets you link user classes with Document Definitions and document events. This part of ASU defines
behavior TIU documents only.
• The User Class Membership file is a relational file which allows a many-to-many relationship to be defined
between User Classes and their members (as defined in the New Person File (#200)).
• Membership in classes may be scheduled for automatic transition to other classes (e.g., the PGY1 Residents will
rotate on June 30th, and will become PGY2 Residents as of July 1st).
• The Authorization/Subscription file (#8930.1) is another relational table, linking actions or events (e.g., Signature)
with Document Definitions (e.g., Clinical Warning Note), record statuses, user classes (e.g., Provider) and user
roles (e.g., Author, Expected Signer, Expected Cosigner, etc.). In this manner, a “Knowledge Base” or table of
“Production Rules” can be developed in compliance with the site’s local by-laws (or in some cases, national
requirements) for handling of various elements of the medical record. This eliminates the need for “hard-coding”
business rules within the application, thereby enforcing policies, independent of the local facility’s preferences.
These rules are also “inherited” through both the User Class and Document Definition hierarchies.
• ASU imposes no limitation on the depth or specificity of the User Class hierarchy which a site may choose to
develop.
• Other applications within VistA may access the User Class file to determine the role of an employee.
Figure: 3.1-18
3.1.14 CPRS: Clinical Reminders
Namespace PXRM
The Clinical Reminder system helps caregivers deliver higher quality care to patients for both preventive health care
and management of chronic conditions, and helps ensure that timely clinical interventions are initiated.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-72
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
Reminders assist clinical decision-making and also improve documentation and follow-up, by allowing providers to
easily view when certain tests or evaluations were performed and to track and document when care has been
delivered. They can direct providers to perform certain tests or other evaluations that will enhance the quality of care
for specific conditions. The clinicians can then respond to the reminders by placing relevant orders or recording
clinical activities on patients’ progress notes.
Clinical Reminders may be used for both clinical and administrative purposes. However, the primary goal is to
provide relevant information to providers at the point of care, for improving care for veterans. The package benefits
clinicians by providing pertinent data for clinical decision-making, reducing duplicate documenting activities, assisting
in targeting patients with particular diagnoses and procedures or site-defined criteria, and assisting in compliance
with VHA performance measures and with Health Promotion and Disease Prevention guidelines.
2057
2058
2059
2060
Figure: 3.1-19
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-73
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
3.1.15 CPRS: Consult/ Request Tracking
Consult/Request Tracking package V. 3.0 improves the quality of patient care by:
 Interfacing with CPRS to provide an efficient mechanism for clinicians to order consults and procedure requests.
 Providing consulting services with the ability to update and track the progress of a consult/procedure request
from the point of receipt through its final resolution.
 Providing results reporting that includes doctor's notes and comments entered during the tracking process.
Figure: 3.1-20
3.1.16 CPRS: Health Summary
A Health Summary is a clinically oriented, structured report that extracts many kinds of data from VISTA and displays
it in a standard format. The individual patient is the focus of health summaries. Health summaries can also be printed
or displayed for groups of patients. The data displayed covers a wide range of health-related information such as
demographic data, allergies, current active medical problems, and laboratory results.
Health Summaries can be viewed through VistA options and through the CPRS GUI on the Reports tab.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-74
2078
2079
2080
Figure: 3.1-21
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-75
2081
CPRS: Health Summary - (Component diagram)
cmp CPRS: Health Summary
Health Summary
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
DHCP Ancillary
Reminder
Maintenance
Surgery Report
(OR/NON)
Next of Kin
Reminder Brief
NON OR
Procedures
Reminders Due
Vital Signs
Outpatient
Global Assess
Function
Spinal Cord
Dysfunction
Reminders
Summary
Selected
Progress Notes
Detailed Vitals
MAG Imaging
Vital Select
Outpatient
Select Image
Impression
Figure: 3.1-22
3.1.17 Electronic Wait List
In the outpatient setting, patients are assigned a primary care team and provider who are responsible for delivering
essential health care, coordinating all health care services, and serving as the point of access for specialty care. This
is accomplished through the Primary Care Management Module (PCMM) of the Veterans Health Information
Systems and Technology Architecture (VistA). When a patient cannot be assigned to a primary care team or position,
the PCMM software asks if the patient should be placed on the Electronic Wait List. PCMM Wait List reports assist in
the management of patients awaiting a primary care team or provider assignment.
The purpose of EWL is to provide quicker or more convenient patient care by providing care by another team or
location for the patient’s benefit. The EWL can be accessed through the PCMM GUI or by a Stand alone Roll and
Scroll application from the VistA Scheduling Appointment menu, as well as from the Scheduling Appointment
Management Menu. The EWL standalone menu is accessible to users with the SDWL MENU security key.
The goal of the EWL is to provide care to the patient as quickly as possible. To facilitate this goal, patients may be
placed on a Wait List for a different team or even at a different facility. The EWL keeps track of appointments, clinics,
and providers associated with patients on the various Electronic Wait Lists. Patient eligibility information and service
connected status is also recorded and updated. The EWL runs a background job to determine patient changes in the
veteran’s service connected percentage, service connected priority as well as changes to appointment, clinics, and
personnel that affect Wait List patients. EWL also sends messages to assigned mail groups to notify of such
changes.
The Electronic Wait List can also produce reports on demand regarding EWL related activities.
This patch is a part of the Electronic Wait List enhancements as identified through a list of requirements that the EWL
User Group has validated and prioritized. Management of the EWL disposition process and its close relation to
scheduled appointments has been addressed in this patch. The functionality introduced by this patch applies to the
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-76
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
existing EWL package in its current state. The Electronic Wait List sub-system shall be included in the Scheduling
Re-hosting project that is in testing right now and the EWL features introduced in this patch are expected to be
implemented in this Scheduling Re-hosting project as well.
The main purpose of this project is to speed up the disposition process of open EWL entries if a related appointment
is scheduled and to alert the new EWL Mail Group: SD EWL BACKGROUND UPDATE, about the need for editing an
EWL entry in response to a change in the status of its EWL type.
A user manual specific to just patch SD*5.3*327 has been created and is located at
http://www.va.gov/vdl/VistA_Lib/Clinical/Electronic_Wait_List/SD_53_P327_um.pdf.
NOTE: The general online User Manual of Electronic Wait List for Scheduling and Primary Care Management
Module (PCMM) is available at
http://www.va.gov/vdl/VistA_Lib/Clinical/Electronic_Wait_List/SD_53_P263_um.pdf.
Product Feature Summary - SD*5.3*327 will introduce the following enhancements:
• User interface to select open EWL entries by clinic, by specialty or all
• Ability to disposition a selected EWL entry and to update with data of the related appointment
• Optional selection of open EWL entries for marking with a non-removal reason
• Display of selected EWL entries with the Reopen Reason, appointment information, and the related comments if
applicable.
• The new EWL background job to include:
o Identification of ‘canceled’ appointments used previously for disposition of the related EWL entries, and
automatic change of the related EWL entry status to ‘open’.
o Identification of the Date of Death change and update of the related EWL entry status accordingly.
o Identification of ‘inactivated’ clinics, teams, and positions used in open EWL entries with follow up
notification sent to the EWL Mail Group.
o Generation of appropriate messages (listed above) sent by Mail Man to the designated EWL Mail
Group: SD EWL BACKGROUND UPDATE.
• Design of a new report with EWL entries sorted by Reopen Reason.
• Ability to prompt for a new entry to the EWL if no appointment could have been selected from Action:
Unscheduled Visit under Appointment Management.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-77
2138
2139
2140
2141
Figure: 3.1-23
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-78
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
3.1.18 CPRS: Problem List
The Problem List program is used to document and track a patient’s problems. It provides clinicians with a current
and historical view of a patient’s health care problems, and allows each identified problem to be traced through the
DHCP system in terms of treatment, test results, and outcome.
Version 2 supports primary care providers in both inpatient and Ambulatory Care settings, including physicians,
nurses, social workers, psychologists, and others. It also is designed to be used by PIMS clinic and ward clerks and
by PIMS coding clerks. Many data entry methods are possible with this program.
Features in Problem List
• Allows one problem list for a given patient.
• Tied to a coding system.
• Requires minimal data entry.
• Linked to other sections of the medical record, such as CPRS and Health Summary.
• Supports import of problem information from other clinical settings outside the immediate VAMC.
• Uses a common language of terminology, the Lexicon Utility. Each term is well-defined and understandable. A
user, site, or application may substitute a preferred synonym.
• Allows reformulation of a problem.
• Can be interfaced with a customized encounter form.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-79
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
Figure: 3.1-24
3.1.19 CPRS: TIU-Text Integration Utility
Namespace TIU
The purpose of Text Integration Utilities (TIU) is to simplify the access and use of clinical documents for both clinical
and administrative VAMC personnel, by standardizing the way clinical documents are managed. In connection with
Authorization/ Subscription Utility (ASU), a hospital can set up policies and practices for determining who is
responsible or has the privilege for performing various actions on required VHA documents.
The initial release of Version 1.0 includes Discharge Summary and Progress Notes. Consult Reports was added with
the release of Computerized Patient Record System (CPRS). TIU replaces and upgrades the previous versions of
these VISTA packages. It has also been designed to meet the needs of other clinical applications that address
document handling.
TIU lets you continue to access Progress Notes and Discharge Summaries from OE/RR menus. The CPRS
Graphical User Interface (GUI) allows point-and-click access to all Progress Notes, Discharge Summaries, and
Consults TIU documents.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-80
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
[Highest revision in VA Software Document Library (vld) is Patch TIU*1*250. (2011_08_06)]
Figure: 3.1-25
3.1.20 Dentistry
Dental Record Manager (DRM) Plus
In 1997, Document Storage Systems, Inc., in conjunction with the VA, developed a dental software package titled the
Dental Record Manager (DRM). The Dental Record Manager is a nationally purchased software product and is
installed in all VA dental clinics. Future plans for DRM included the computerization of the patient’s Diagnostic
Findings, Completed Care Treatment Plan and Periodontal Chart. The planning for these enhancements has been a
joint VA/DSS effort. DRM Plus is a combination of DRM and these major enhancements. Document
Storage Systems and Discus Dental Software worked together to develop DRM Plus. In September, 2003, the VA
purchased a national license for DRM Plus. DRM Plus was fully implemented by September 30, 2005.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-81
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
The DRM Plus program is designed to provide dental health care facilities with an intuitive, user friendly Windows
interface for end-users to create encounter information assess patient dental conditions, and develop and maintain
the Treatment Plan. The DRM Plus program is an application that uses “RPC Broker” technology that permits the
facility users to store and retrieve clinical data within the VistA System.
Implementation of DRM Plus results in more accurate insurance billing for dental visits, consults and procedures.
This application also supports the transfer from Dental Amis System (DAS) to Dental Encounter System (DES) filing
within the guidelines established by the Veterans Health Administration, Office of Dentistry.
DRM Plus introduces two new areas for recording and charting patient information – Treatment & Exam and
Periodontal Chart. The patient’s Diagnostic Findings, Treatment Plan and Completed Care can be recorded and
maintained within the Treatment & Exam screen. The patient’s periodontal conditions can be recorded and
maintained within the Periodontal Chart screen.
Figure: 3.1-26
3.1.21 EDIS-Emergency Department Integration Software
Emergency Department Integration Software (EDIS) incorporates several Web-based views that extend the current
Computerized Patient Record System (CPRS) to help healthcare professionals track and manage the flow of patient
care in the emergency-department setting. EDIS views are based on a class-three application developed by the
Upstate New York Veterans Health Care Network—or Veterans Integrated Services Network (VISN) Most views are
site configurable. EDIS enables you to:
• Add emergency-department patients to the application’s display board
• View information about patients on the display board
• Edit patient information
• Remove patients from the display board
• Create administrative reports
EDIS runs as a Web application on a centrally-located BEA WebLogic server that contains program logic and
operational emergency-department data in its Java middle tier. The presentation tier is a Flash Player application.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-82
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
The data tier encompasses local sites’ Veterans Health Information Systems and Technology Architecture (VistA)
systems and a centrally located relational database management system (RDMS) data store containing Standard
Data Services (SDS) tables.
The application uses remote procedure calls (RPCs) from local VistA implementations to populate patient- and
provider-selection lists, provide limited data synchronization between EDIS and CPRS, and determine users’ access
levels.
Figure: 3.1-27
3.1.22 FIM-Functional Independence Measurement
The Functional Independence Measures (FIM) Version 1.0 provides an integration of FIM assessments into the
Computerized Patient Record System (CPRS) and into the Functional Status and Outcomes Database (FSOD) at the
Austin Automation Center (AAC). The FIM is an 18-item, 7-level functional assessment designed to evaluate the
amount of assistance required by a person with a disability to perform basic life activities safely and effectively.
There are five types of FIM assessments: admission, goals, interim, discharge, and follow-up.
The FIM assessments are used clinically to monitor the outcomes of rehabilitative care as required by the Joint
Commission on the Accreditation of Health Care Organizations (JCAHO) and the Commission on the Accreditation of
Rehabilitative Facilities (CARF). According to VHA Directive 2000-16, medical centers are mandated to measure and
track rehabilitation outcomes on all new stroke, lower-extremity amputees, and traumatic brain injury (TBI) patients
using the FIM.
Finally, the Performance Measurement Workgroup of the Department of Veterans Affairs Central Office (VACO)
approved a Network Director Performance Measure for rehabilitation for FY03 that requires the collection of FIM
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-83
2252
2253
2254
2255
2256
2257
2258
2259
2260
data. FIM Version 1.0 should greatly ease the burden placed on rehabilitation professionals in the field who are
working to comply with the new performance measure.
FIM provides a Graphic User Interface (GUI) front-end programmed in Delphi to allow multiple clinicians to input FIM
data for a given patient. This documentation then becomes available in CPRS as a progress note with addendums
and/or a completed consults. The GUI front-end gathers demographic data as well as other required data by FSOD
from VistA, therefore, eliminating the need for the clinician search of VistA for the information and re-enter for FIM.
FIM data is then placed in a VistA FileMan file for Health Level Seven (HL7) transmission to the FSOD at ACC.
2261
2262
2263
Figure: 3.1-28
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-84
2264
2265
2266
2267
2268
FIM-Functional Independence Measurement - (Component diagram)
cmp FIM-Functional Independence Measurement
Name:
Package:
Version:
Author:
FIM-Functional Independence Measurement
FIM-Functional Independence Measurement
1.0
Karen Kirkpatrick
FIM-Functional Independent Measures
HL7
2269
2270
2271
2272
2273
2274
2275
2276
2277
«interface»
FIM-Functional
Austin Automation Center (AAC
Independent
Measures::Austin
Automation Center
Figure: 3.1-29
3.1.23 Group Notes
This program was designed to assist providers in documenting group therapy sessions and events such as
immunization clinics. It allows the easy assembly of patient groups based on Clinics, Specialties, Wards, Teams, or
Provider lists. It then allows the note author to specify parts of a note that apply to the entire group and parts that
apply to individuals. It does the same with encounter data. After the note and encounter information is complete, it
provides for a single signature for the entire group.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-85
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
Figure: 3.1-30
3.1.24 HDR-Hx - HDR-Historical
Centralized Data Repositories::Health Data Repository (HDR)
Package HDR Historical (HDR Hx)
HDR Historical (HDR Hx)
** Please note, this information was gathered via documentation found in the Office of Enterprise Development
(OED) Project Repository, the VistA Monograph, and the HDR Hx Homepage. As the Analysts Office did not receive
feedback from the HDR Historical points of contact, this information has not been verified.
Description: HDR Historical (HDR Hx) stores all clinical data from VistA not contained in HDR IMS and not identified
for inclusion in HDR II. It provides historical clinical data in a computable and/or viewable access form to user
interfaces such as RDI, CHDR and VistAWeb to support patient care.
HDR Hx extracts and stores legacy data from 128 VistA systems to a relational database in the Austin Information
Technology Center (AITC). The data is viewable from the HDR Hx database via Remote Data Views (RDV) in CPRS.
HDR Hx allows sites to archive and purge selected data in local databases. The historical data provided by HDR Hx
is combined with other HDR data for use across the organization to facilitate patient care, clinical decision support,
and research activities.
Programming Language:
Research pending
Deployment Infrastructure:
Oracle 11g
Unix
Depends On:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-86
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
VistA 1.0
Computerized Patient Record System (CPRS)
Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
Department of Defense (DoD) Information Sharing
Clinical Data Repository/Health Data Repository (CHDR)
Master Patient Index (MPI)
The following entities depend on HDR Historical (HDR Hx):
VistA 1.0
VistAWeb
Centralized Data Repositories
HDR Clinical Data Services (CDS) v. 1.0
HDR National (HDR II)
Corporate Data Warehouse (CDW)
Department of Defense (DoD) Information Sharing
Clinical Data Repository/Health Data Repository (CHDR)
For more information, reference:
VA Software Document Library (VDL): N/A
VA Office of Enterprise Development (OED) Project Repository:
HDR Historical Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=909
VistA Monograph (2009): http://www4.va.gov/vista_monograph/
Health Data Repository Hx Homepage: http://vaww.vista.med.va.gov/hdr/HDR_Hx_Documents.html
Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
Health Data Repository PowerPoint Presentation:
http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-87
class HDR-Hx HDR Historical
Name:
Package:
Version:
Author:
HDR-Hx HDR Historical
HDR-Hx HDR Historical
Dec 2011
OSEHRA
HDR-Health Data
Repository
HDR Clinical Data
Serv ices (CDS)
HDR-Hx HDR Historical
Corporate Databases
VistA 1.0
Master Patient Index (MPI)
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
HDR II
DoD Information Sharing
Figure: 3.1-31
3.1.25 HBPC-Home Based Primary Care
The Home Based Primary Care (HBPC) package formally known as Hospital Based Home Care (HBHC) is a VISTA
application developed for use by the HBPC Programs at the medical centers. The software:
• Allows the entry and storage of information on all Evaluations/Admissions,
• Scans Outpatient Encounters for all HBPC visits and stores the visit data,
• Allows the entry and storage of HBPC Discharge information,
• Provides reports covering all aspects of the data,
• Informs the staff when incomplete records for transmission are found,
• Transmits the data to Austin using MailMan.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-88
2347
2348
2349
Figure: 3.1-32
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-89
2350
HBPC-Home Based Primary Care - (Component diagram)
cmp HBPC-Home Based Primary Care
Name:
Package:
Version:
Author:
HBPC-Home Based Primary Care
HBPC-Home Based Primary Care
1.0
Karen Kirkpatrick
HBPC-Home Based Primary Care
HL7
2351
2352
2353
«interface»
HBPC-Home Based
Primary Care::Austin
Automation Center
(AAC)
Austin Automation Center (AAC)
Figure: 3.1-33
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-90
2354
Home Telehealth - (Component diagram)
cmp Home Telehealth
Name:
Package:
Version:
Author:
Home Telehealth
Home Telehealth
1.0
Karen Kirkpatrick
Home Telehealth
HL7
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
«interface»
Home Telehealth::
Austin Automation
Center (AAC)
Austin Automation Center (AAC)
Figure: 3.1-34
3.1.26 Home Telehealth
The goal of the Home Telehealth IT program is to integrate vendor supported Home Telehealth services into the
VistA medical information infrastructure. The Home Telehealth program builds on the excellent existing and evolving
VistA system. This phase of the Home Telehealth project moves us towards an integrated environment through the
following process:
• The patient screening process starts with a VistA Consult.
• The Consult is completed through the standard VistA Progress Note.
• Patient sign-up is done through a VistA Patient Information Management System (PIMS) interface.
The care coordinator selects the patient name, the supporting vendor, the consult type, the care coordinator’s name,
and then submits the request. VistA extracts all the pertinent patient data and sends a Health Level Seven (HL7)
Sign-Up message to the vendor server.
• The care coordinator then uses the vendor software to associate the home device with the patient record on the
vendor system.
• Measurement data gathered by devices in the veteran’s home are stored in the vendor server and available for
review, and are sent to the VA’s Health Data Repository (HDR) using HL7 messages sent through the VistA
Interface Engine (VIE) Infrastructure.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-91
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
•
•
The Home Telehealth data in the HDR along with VistA data from facility VistA systems is viewed using
VistAWeb, which is available through the Computerized Patient Records System (CPRS) by using the Remote
Data View (RDV) function.
Monthly, vendor servers send HL7 messages to the Sign-Up VistA facility for the Care Coordinator to review
draft progress notes summarizing patient activity from the previous month.
This functionality involves components on the vendor servers as well as several VistA packages including Consults,
PIMS for sign up, Progress Notes, TIU, VIE, Master Patient Index (MPI), HDR, Clinical Data Services (CDS), Clinical
Context Object Workgroup (CCOW) for patient context, VistAWeb, and CPRS.
Figure: 3.1-35
3.1.27 ICR-Immunology Case Registry
Immunology Case Registry (ICR) version 2.1 was removed from service by patch IMR*2.1*21 in October 2005.
ICR and the Hepatitis C Case Registry are now supported by the Clinical Case Registries (CCR) package. CCR
version 1.5 was released in February 2006.
For documentation on the latest version of CCR, please see the Clinical Case Registries page on the VA Software
Documentation Library (VDL) at http://www.va.gov/vdl/application.asp?appid=126.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-92
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
Figure: 3.1-36
3.1.28 IRT-Incomplete Records Tracking
The Incomplete Records Tracking (IRT) software is formerly a component of PIMS V. 5.3. With PIMS V. 5.3, it
includes many enhancements that should allow the users greater flexibility and efficiency when tracking incomplete
records.
The package now tracks all types of deficiencies, in addition to those already being tracked (Discharge and Interim
Summaries and OP Reports). The sites will have the ability to add the deficiencies they wish to track to make this
package more site specific.
The Physician for Deficiency will be tracked throughout the IRT process. The users will know who is responsible for
the deficiency at various stages of tracking, from entry through completion.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-93
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
Figure: 3.1-37
3.1.29 Intake and Output
The Intake and Output (I&O) application is designed to store, in the patient's electronic medical record, all patient
intake and output information associated with a hospital stay or outpatient visit. This application is not service specific
and currently is interfaced with the PIMS, Nursing, and Pharmacy applications.
Functionality:
• Users may electronically document patient intake (e.g., oral fluids, tube feedings, intravenous fluids, irrigations,
and other types of intake defined by the facility) and patient output (e.g., excreted patient material such as urine,
nasogastric secretions, emesis, drainage, liquid feces/stool, and other types of output defined by the facility).
• Intake data can be entered through either a quick or detailed route. The quick route documents the total fluid
consumed. Detailed information requests the user to enter specific type of fluid intake (e.g., orange juice, water,
soup) along with the quantity absorbed.
• The Start/Add/DC IV and Maintenance option contains nine protocols associated with intravenous therapy:
1. Start IV - Start a new IV line or heparin/saline lock/port.
2. Solution: Replace/DC/Convert/Finish Solution - DC current solution then replace a new solution to the
selected IV line or convert the IV according to the user's choice.
3. Replace Same Solution - Replace the same solution to a selected IV.
4. D/C IV Lock/Port and Site - Remove IV/lock/port from a selected IV site.
5. Care/Maintenance/Flush - Check site condition, dressing change, tube change and flush.
6. Add Additional Solutions(s) - Add additional solution(s) without discontinuing an existing one.
7. Restart DC'd IV - Restart an IV which was DC'd due to infiltration or other reasons.
8. Adjust Infusion Rate - Adjust infusion rate for a selected IV.
9. Flush - Flush all IV line(s) for a selected infusion site.
• The software supports documentation of intravenous intake via both single and multi-lumen catheters.
• The software is interfaced with the IV module of the Pharmacy software.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-94
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
The following reports are included:
o Print I/O Summary by Patient (by Shift and Day(s))
o Print I/O Summary (Midnight to Present)
o Print I/O Summary (48 Hrs)
o 24 Hours Itemized Shift Report
o Intravenous Infusion Flow Sheet
The last four reports can be printed for all patients on a ward, for patients in selected rooms on a ward, and for an
individual patient.
• Patient Intake and Output information is printed on the following Nursing application reports:
o End of Shift Report
o Vital Signs Record
•
This version of Intake and Output is not interfaced with the Health Summary or the Order Entry/Results Reporting
applications.
2450
2451
2452
Figure: 3.1-38
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-95
2453
Intake and Output - (Component diagram)
cmp Intake and Output
Pharmacy:
Inpatient Med IV
Nursing
Vitals/ Measurements
«interface»
Intake & Output
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
Figure: 3.1-39
3.1.30 Laboratory
The Laboratory module is part of the integrated VistA software, which automates the manual procedures used in the
following laboratory areas:
1. Ordering of tests and procedures on both patient and non-patient specimens
2. Collection and Accessioning of specimens into the Laboratory database
3. Processing and analysis in appropriate department or work areas
4. Review and verification of results
5. Reporting of results and/or diagnoses for clinical health care treatment
6. Analysis and reporting of quality control data used in generating results
7. Providing management statistical data as well as requirements for accreditation by
regulating bodies and agencies.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-96
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
Figure: 3.1-40
3.1.31 Laboratory: Anatomic Pathology
Anatomic Pathology (AP) is divided into four sections: Surgical Pathology, Cytology (Cytopathology), Electron
Microscopy, and Autopsy Pathology.
The processes of accessioning, data entry, coding, and editing are similar for each of these sections. The computer
program lets you select one of these processes (menus or options) and then the section. That is, if you wish to log in
a specimen for Cytology, you first select the “Log-in Menu,” and then you’ll be prompted to choose the Anatomic
Pathology section.
The search options are based on SNOMED and ICD9CM coding.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-97
2481
2482
2483
2484
2485
2486
Figure: 3.1-41
Laboratory: Anatomic Pathology - (Component diagram)
cmp Laboratory: Anatomic Pathology
Laboratory:
Anatomic Pathology
«interface»
Laboratory:
Anatomic
Pathology
2487
2488
2489
2490
DHCP - Decentralized Hospital Computer Program
Figure: 3.1-42
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-98
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
3.1.32 Laboratory: Blood Bank
The national release of patch LR*5.2*408 on July 18, 2011 finalizes the VHA transition from the VistA Version 5.2
Blood Bank package to the VistA Blood Establishment Computer Software (VBECS) system. Sites with VBECS have
already disabled the VistA v5.2 Blood Bank package when database conversion was executed. With the installation
of this patch the Enter/Edit options for VistA v5.2 Blood Bank are permanently disabled.
Patch releases for VBECS communications with VistA packages will continue as LR*5.2 and VBEC namespace
releases. All customer documentation for these VBECS associated releases are posted to the VistA Document
Library (VDL), Laboratory: VistA Blood Establishment Computer Software (VBECS).
Because Blood Bank legacy records are available as read-only, VistA v5.2 continues to be maintained by OIT as a
Food and Drug Administration cleared medical device (FDA number BK970021). Adulteration of this package at VHA
facilities is prohibited and will be monitored by the product development team.
Figure: 3.1-43
3.1.33 Laboratory: Blood Bank Workarounds
Description not readily available.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-99
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
Figure: 3.1-44
3.1.34 LEDI-Laboratory: Electronic Data Interchange
The Veteran Integrated Service Network (VISN) mission is to consolidate electronic lab test ordering and lab test
result reporting throughout all Veterans Affairs (VA) Health Care Facilities laboratories within a VISN, between
VISNs, and non-VA organizations (i.e., commercial reference laboratories, Department of Defense (DoD), and etc.)
without diminishing the quality of services in the patient medical care.
VistA Laboratory Electronic Data Interchange (LEDI) software application provided the new electronic messaging
functionality for lab test ordering and result reporting between VA Health Care facilities laboratories. This electronic
messaging functionality is based on the Health Level Seven (HL7) Version 2.3 and VistA Health Level Seven (HL7)
Version 1.6 Standard Specifications. These specifications are used as the basis for defining VistA Laboratory
Universal Interface (UI) and LEDI HL7 Interface Standard Specification Version 1.2. The
following new electronic features and functionalities were implemented by the release of the VistA LEDI software
application:
• Electronic Messaging
• Electronic Lab Test Ordering
• Electronic Lab Test Results Reporting
• Bar-code Specimen Accessioning
• Workload
VistA Laboratory Electronic Data Interchange Phase III (LEDI III)
The scope of the VistA LEDI III software enhancements involves the development of a bidirectional interface that
allows VA and DoD facilities to be reference laboratories for each other. Laboratory test orders and results are
transmitted via VA VistA systems using LEDI III for VA facilities and Laboratory Data Sharing and Interoperability
(LDSI) software via DoD Composite Health Care System (CHCS) systems for DoD facilities. The VA/DoD LEDI III
LDSI project was designed to determine a methodology that has the capacity and features necessary for sharing
secure encrypted laboratory data between the two agencies. This patch adds support for sending/receiving LEDI
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-100
2538
2539
2540
2541
2542
2543
2544
2545
orders/ results between VA and DoD facilities and implements enhancements to general LEDI functionality. The
exchange of clinical chemistry laboratory data between VA and DoD facilities is a process of data transmission
between VistA and CHCS systems using the HL-7 messaging protocol over a TCP/IP connection utilizing a secure
Virtual Private Network (VPN)/firewall.
Figure: 3.1-45
LEDI-Laboratory: Electronic Data Interchange - (Component diagram)
cmp LEDI-Laboratory: Electronic Data Interchange
LEDI - Laboratory
Electronic Data
Interchange
«interface»
LEDI - Laboratory
Electronic Data
Interchange
2546
2547
2548
2549
2550
2551
2552
2553
CHCS - Composit Health Care System
Figure: 3.1-46
3.1.35 EPI-Laboratory: Emerging Pathogens Initiative
Under the auspices of the Program Office for Infectious Diseases VAHQ the Laboratory Emerging Pathogens
Initiative (EPI) software package is to allow the Department of Veterans Affairs (DVA) to track Emerging Pathogens
on the national level without the necessity for additional local data entry. Using this objective information, plans can
be formulated on the national level for intervention strategies and resource needs. Results of aggregate data can
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-101
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
also be shared with appropriate public health authorities for planning on the national level for the non- VA and private
health care sectors.
Major functions:
The Laboratory EPI program is designed to automatically provide data on emerging pathogens to Veterans Affairs
Headquarters (VAHQ) without additional individual data entry at the site level. The data will be sent to Austin
Automation Center (AAC) for initial processing and coupling with denominator data related to workload. VAHQ data
retrieval and analysis can then be accomplished.
Objectives:
 Identify Emerging Pathogens.
 Extract specific data associated with the Emerging Pathogen.
 Transmit data to AAC.
 Create national Statistical Analysis System (SAS) data sets for Infectious Diseases Program Office access.
Figure: 3.1-47
3.1.36 Laboratory: Howdy Computerized Phlebotomy Login Process
There are no documents for this application at this point. As of October 30, 2009.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-102
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
Figure:
3.1-48
3.1.37 Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form
The purpose of the National Laboratory Test (NLT) Mapping to the Logical
Observation Identifier Names and Codes (LOINC) is to provide the mapping of CH subscripted tests result codes,
and the standardization of files used in the Laboratory Software application. The LOINC committee including the
largest clinical laboratories in the United States, and Veterans Affairs, has agreed to use LOINC to identify test
results.
NLT Mapping to the Logical Observation Identifier Names and Codes (LOINC)
has the following features:
• Provides a method to communicate across laboratories in support of Clinical Information Resource Network
(CIRN) by mapping VISTA lab tests to LOINC codes.
• Provides sets of universal names and ID codes for identifying laboratory and clinical test results.
• Allows the creation of a uniform naming convention for clinical terms.
• Allows the merging of clinical data across sites (where terminology may vary widely).
• Provides the requirement for the adoption of naming or coding conventions, and the mapping of local
terminology to these conventions.
• Maps the National Laboratory Test file (#64) to the LOINC codes.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-103
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
Figure: 3.1-49
3.1.38 POC-Laboratory: Point of Care
The VistA Laboratory Point of Care (POC) Interface utilizes existing functionality provided by Laboratory Universal
Interface (UI) and Laboratory Electronic Data Interchange (LEDI) software. The software supports the transmission,
processing and storing of POC TEST RESULTS in the VistA Laboratory package. The ability of POC interfaces to
subscribe to VistA HL7 Admissions, Discharge, Transfer (ADT) messages for patient demographics and location
information is provided as needed. Support for 5 separate POC interfaces is provided. Additional interfaces can be
added locally when naming of additional interfaces are in conformance to name spacing instructions.
POC is a type of interface that downloads and stores results for a bed side analyzer/ device or any instrument that
performs laboratory testing at the site of care (examination, treatment, diagnosis, etc.). The accession and
verification procedures are modified to accommodate POC type of data storage. POC results are not verified by the
traditional laboratory methods.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-104
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
Figure: 3.1-50
3.1.39 Laboratory: Universal Interface
The purpose of the VistA Laboratory Universal Interface (UI) Health Level (HL) v1.6 Upgrade Patch LA*5.2*66
software release is to improve the transmission of laboratory test results from clinical analyzers to the VistA system.
This release upgrades Lab UI from VistA’s Health Level Seven (HL) v1.5 to VistA’s HL v1.6, which includes the use
of version 1.6 Transmission Control Protocol/ Internet Protocol (TCP/IP) functionality. This functionality supports the
current Lab UI HL7 Interface Specifications based on the HL7 Standard V2.2.
The current UI interface using the HL v1.5 interface will continue to function after patch installation. The transition to
the HL V1.6 interface can be accomplished after patch installation on a connection by connection basis. When
possible, switching from the old interface to the new interface should be done on a per instrument basis instead of all
instruments at once. Follow the post installation instructions to convert an interface to the HL V1.6 interface.
The Generic Instrument Manager (GIM) is a locally procured commercial device that controls communications
between the Laboratory instruments and VistA. The VistA system downloads work lists through the GIM to the
various instruments, and the instruments upload results to VistA through the GIM, eliminating the need for Laboratory
developers to write a new interface for each different instrument. Due to the increased laboratory workload, higher
instrument throughput, longer and more textual lab results, and the emergence of more efficient communications
platforms have rendered HL7 v1.5 obsolete. HL7 v1.6 allows faster transmission, longer messages, and more
advanced queue handling than HL7 v1.5.
NOTE: New Generic Instrument Manager (GIM) software must be obtained from the vendor in order for this new
interface to work.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-105
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
Additionally, HL7 messaging depends on VistA’s HEALTH LEVEL SEVEN package for validation and routing
messages. Infrastructure Information Service (IIS) has recommended that all VistA applications upgrade to HL7 v1.6
as soon as feasible.
NOTE: Information Infrastructure Systems (IIS) will make no further enhancements to the VistA HL v1.5 package.
Implementation of this enhancement is expected to cause no changes to the process of reporting lab results.
Although faster, more efficient, and easier to manage, the process itself will not change. Since the release of
Laboratory Electronic Data Interchange (LEDI) II to the field, sites are familiar with the configuration and file structure
of HL7 v1.6.
2645
2646
2647
Figure: 3.1-51
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-106
2648
Laboratory: Universal Interface - (Component diagram)
cmp Laboratory: Univ ersal Interface
Laboratory: Univ ersal Interface
«interface»
Laboratory:
Univ ersal
Interface
GIM - Generic Instrument Manager
DHCP - Decentralized
Hospital Computer
Program
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
Figure: 3.1-52
3.1.40 VBECS-Laboratory: VistA Blood Establishment Computer Software
The main purpose of the VistA Blood Establishment Computer Software (VBECS) is to automate the daily processing
of blood inventory and patient transfusions in a hospital transfusion service.
VBECS is an improved Blood Bank application that facilitates ongoing compliance with Food and Drug Administration
(FDA) standards for medical devices and enhances the VA VHA’s ability to produce high-quality blood products and
services to veterans. The system follows blood bank standards, standards of national accrediting agencies, FDA
regulations, and VA policies.
VBECS supersedes VistA Blood Bank v5.2 for blood bank operations. VistA Blood Bank v5.2 blood unit records
remaining after the transfer of patient information to VBECS are available for reference only and cannot be edited.
VistA Blood Bank v5.2 validation records must be maintained for five years after the last of the blood unit records is
transferred to VBECS.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-107
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
Figure: 3.1-53
3.1.41 Lexicon Utility
Namespace LEX
The Lexicon is a standardized reference for clinical terminology across VHA that enables clinical information to be
recorded, transmitted, retrieved, and analyzed in a precise and consistent manner independent of clinic or medical
center.
The Lexicon provides a comprehensive Application Program Interface (API) that enables any application that needs
to use standardized terminology to be able to interface. At its inception in the early 1990s, the scope of the Lexicon
was limited to expressing diagnostic clinical problems in easy-to-understand terminology and associating terms to
coding systems such as International Classification of Diseases (ICD), Clinical Modification (ICD-9-CM), Diagnostic
and Statistical Manual of Mental Disorders (DSM), and the North American Nursing Diagnosis Association (NANDA).
Over the years, this scope broadened to provide a general purpose utility that serves the terminology needs of many
packages, including Problem List (standardized using SNOMED CT), Encounter Forms, Text Integration Utility (TIU),
Event Capture, Federal Health Information Exchange (FHIE), and the Laboratory Data Sharing Interoperability (LDSI)
project. A number of other VistA applications that need the versioned terminology that Lexicon can provide may be
added to this list in the near future.
In addition to providing terminology, the Lexicon provides a coding system update deployment mechanism. This
update deployment mechanism is now used to update coding systems that are represented in the Lexicon, in
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-108
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
addition to updating standard VistA reference files for the same coding systems that fall outside the Lexicon
namespace. Additionally, the same mechanism is used to update coding systems that do not form part of the
Lexicon. A large number of applications, packages, and services (VistA and external) are now dependent on the
quarterly updates provided by this deployment mechanism. The dependent packages include Integrated Billing, Fee
Basis, Automated Information Collection System (AICS), Laboratory, Dental, Prosthetics, Mental Health, Radiology,
Surgery, Registration, Patient Care Encounter (PCE), Event Capture, Quality: Audiology and Speech Analysis and
Reporting (QUASAR), Home Based Primary Care, Clinical Reminders, Text Integration Utility (TIU), Laboratory Data
Sharing Interoperability (LDSI), and standardized Problem List.
All of the functionality and services provided by the Lexicon are expected to be replaced by a broader and deeper
range of services through VA Enterprise Terminology Services (VETS) applications in the near future.
Features
• Provides a basis for a common language of terminology, so that all members of a health care team can
communicate with each other.
• Provides a concept-based terminology that is well defined, understandable, and encodable by multiple coding
schemes.
• Provides for site modification of term definitions. These modifications are captured by the software and
transmitted to the Lexicon team for ratification and possible inclusion in future updates.
• Provides the ability to deploy updates to code systems from Standards Development Organizations (SDOs) that
are required by statute, mandated by an oversight body, or required by VHA business needs. The current
systems include CPT, HCPCS, CPT modifiers, ICD-9 Diagnoses, ICD-9 Procedures, and SNOMED CT.
• Provides for user definable (user, specialty, or clinic) controlled views of vocabulary through the use of subsets
that may be based on a combination of semantic types and code sources.
• Accepts the provider term if a search of the dictionary does not find a match.
• These terms (otherwise known as unresolved narratives) are captured by the software and forwarded to the
Lexicon team for analysis and possible inclusion in future updates.
• Allows abbreviations or shortcuts to provide quick access to frequently used definitions.
• Supports CPT, HCPCS, ICD-9-CM Diagnoses, DoD DMIS-IDs, and SNOMED CT coding systems.
• Optimizes search results by placing the most frequently-used terms near the start of the list.
• Supports coding system versioning, activation history, and code text history.
• Supports assignment of a VA Unique Identifier (VU ID) to a concept.
• Supports code stratification and merging.
• Supports synonyms, lexical variants, plural forms, abbreviations, word order variants, keywords, and excluded
words.
• Supports inter-coding system mappings.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-109
2725
2726
2727
2728
Figure: 3.1-54
Lexicon Utility - (Component diagram)
cmp Lexicon Utility
Lexicon Utility
«interface»
Lexicon Utility
2729
2730
2731
2732
G.LEXICON@
ISC-SLC.VA.GOV
Figure: 3.1-55
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-110
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
3.1.42 Medicine
The Medicine package is a VA FileMan/ MUMPS-based computer program to serve the needs of the Department of
Veterans Affairs Medicine Service medical community. Medicine test results are organized to help physicians to
manage patient data with greater ease and furnish reports and patient data on a timely basis. It is an important part
of the Decentralized Hospital Computer Program (DHCP), making maximum use of the hospital data base.
Functional Description
The Medicine package is designed for entry, edit, and display of data from a large number of medical tests or
procedures. Printed reports are available for all procedures.
The modules currently included are Cardiology, Pulmonary, Gastrointestinal (GI), Hematology, Rheumatology,
Pacemaker, and Generalized Procedure. Each module has a menu designed for entering, editing, and printing
reports for various procedures/tests associated with that sub-specialty.
The Medicine package has access to the DHCP Imaging System which allows digital images of procedures to be
attached to patient records when run at a workstation. The Imaging system stores, retrieves, transmits, and displays
digital images of conditions and procedures. It allows the physician to have access to a complete view of patient data
which in turn can be electronically shared with consulting physicians. The Imaging system accesses DHCP data such
as laboratory results, pharmacy prescriptions and other clinical information, and displays them along with images of
medical procedures which have been performed. Information such as prior images or previous diagnostic reports can
be integrated and presented as a single record. The Imaging options are only usable on a workstation.
A Summary of Patient Procedures is provided on each menu. The option is documented in a separate section of the
manual. This option allows a user to select a medical patient and obtain a listing of all procedures performed. The
user can determine whether the data should be sorted by date or procedure. If sorted by procedure, the user has the
option of choosing all procedures or a particular type of procedure. The user may select a particular procedure to
view in detail.
Problem Oriented Consult is another option that is common throughout the Medicine package. It is also documented
in a separate section.
Sub-specialty Management menus allow local control over various files such as Medications and Instruments.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-111
2766
2767
2768
2769
Figure: 3.1-56
Medicine - (Component diagram)
cmp Medicine
Medicine
«interface»
Medicine
cMore
Medgraphics
OE/RR
Olympus
Marquette
DHCP Imaging System
DelMar
Sensormedics
VISTA
2770
2771
2772
2773
Figure: 3.1-57
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-112
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
3.1.43 Mental Health
The VistA Mental Health Assistant (MHA) is the graphical user interface (GUI) for the VistA Mental Health Package
(MHP). MHA was developed to create an effective and efficient tool for mental health clinicians and their patients to
use for the administration and scoring of assessment instruments and interviews. Additionally, results are displayed
in report and graphical formats. MHA and MHP support mental health assessments (e.g., psychological testing,
structured interviews, and staff rating scales) that are not available elsewhere in the Computerized Patient Record
System (CPRS)/Veterans Information System and Technology Architecture (VistA). MHA has enjoyed widespread
usage among mental health clinicians over the past several years, and the current revisions of MHA and MHP initiate
steps toward re-engineering VistA Mental Health functionality.
The original revision of MHA created a closer integration with CPRS, by placing the MHA GUI on the CPRS Tools
Menu. Additionally, functionality was created to allow a site to place an individual instrument on the Tools menu,
allowing widespread access to that specific instrument without having to issue the menu for the MHP to all clinicians.
Additional functionality that strengthens the tie to the patient‘s medical record is the creation of a progress note in
CPRS when an instrument is completed through MHA.
Furthermore, MHA maintains and strengthens its ties to the Clinical Reminders program, which allows for the
presentation of specific instruments through reminder dialogs to all clinicians who resolve reminders.
To better meet the needs of clinicians and patients in different programs, particularly non-traditional settings, MHA
can now run in a stand-alone mode to administer instruments offline for later uploading to VistA.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-113
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
Figure: 3.1-58
Mental Health Installation Guide Release Notes V. 5.01, Dec 1994, p.3.
Package Namespaces
The YI, YS, and YT namespaces are assigned to Mental Health V. 5.01. All Mental
Health V. 5.01 routines, options, bulletins, mail groups, and security keys use these
namespaces. NOTE: YI and YT namespaces are used for testing and interview related
software. All other software functionality has been placed in the YS namespace.
Required Packages
Before installing Mental Health V. 5.01, the following DHCP packages must be installed with the package versions. It
is acceptable to install the version indicated, or any newer version. Package Required Version (or later)
FileManager V. 20
Kernel V. 7.1
MAS V. 5.2
OE/RR V. 2.5
Progress Notes V. 2.5
MH ASI-MV Installation and User Guide (Patch YS*5.01*78)
VistA Mental Health ASI-MV Patch YS*5.01*78, Nov 2004, p.14.
Package Namespaces
VistA Mental Health software namespace is YS.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-114
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
Required VistA Software Applications:
RPC Broker 1.1
Kernel 8.0
VA FileMan 22.0
Mailman 7.1
Toolkit 7.3
Computer Patient Record System (CPRS) 1.0.24.26
Mental Health V. 5.01 YS*5.01*67 MUST be installed prior to installing VistA Mental Health ASI-MV Patch
YS*5.01*78.
MHA3 Installation Guide (Patch YS*5.01*85), Dec 2007, p. 14.
Package Namespaces
MH Assistant Version 3 Patch YS*5.01*85 namespace is YS and YT.
MHA3 Software Application Requirements
Kernel v8.0
VA FileMan 22.0
Mailman 8.0
RPC Broker 1.1
Toolkit 7.3
CPRS 26
Mental Health V. 5.01 YS*5.01*76 MUST be installed prior to installing MHA3 Patch YS*5.01*85.
Mental Health - (Component diagram)
cmp Mental Health
Mental Health
«interface»
Mental Health::
Mental Health
NPCD
Mental Health National Database (MH-NDB)
DLL interface to Clinical Reminders functions in CPRS. This DLL is deployed to C:\Program
Files\vista\Common Files
All GAF scores entered through the Mental Health Assistant GAF form are dynamically sent to
the National Patient Care Database (NPCD) at the Austin Automation Center (AAC).
All Mental Health Assessment data entered through the Mental Health Assistant Instrument
Administrator form are dynamically sent from local VistA servers to the NMHDS Oracle
databases at the VA Pittsburgh Healthcare System (Highland Dr.).
The non-menu option, YS BROKER1 [YS BROKER1] contains the context necessary to
interface MHA Version 3, software application to the VistA database.
VistA MH ASI-MV interface software is updated to accompaniment the existing Addiction
Severity Index (ASI) component of the VistA Mental Health V. 5.01 software application.
2843
2844
2845
2846
2847
2848
2849
2850
MH- NDB
NMHDS
COTS ASI-MV
Figure: 3.1-59
3.1.44 MH: Addiction Severity Index
The ADDICTION SEVERITY INDEX MULTIMEDIA VERSION (ASI-MV) is the primary instrument used in Veterans
Health Administration (VHA) to evaluate individual patients’ response to substance dependence treatment and to
evaluate the overall effectiveness of substance dependence treatment programs. Currently the ASI interview is
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-115
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
administered through the VistA roll-and-scroll functionality. Patients’ ASI interviews are generally recorded on paper
and entered later by the clinician or clerk. The ASI interview is a labor-intensive measure. It requires 45-60 minutes to
administer an ASI interview and an additional 20 minutes following the interview to enter the data into the VistA
Mental Health (MH) database using the roll-and-scroll method.
The principal objective of the VistA MH ASI-MV Patch YS*5.01*78 software is to allow patients to respond to an ASI
interview conducted by virtual (computer-animated) counselors. The VistA MH ASI-MV software application is a
significant time-saver for clinicians, because clinicians need not be present during the interview, and are freed to use
this time for other tasks.
VistA Mental Health Addiction Severity Index Multimedia Version (ASI-MV) Interface Software
VistA MH ASI-MV interface software is updated to accompaniment the existing Addiction Severity Index (ASI)
component of the VistA Mental Health V. 5.01 software application. The VistA MH ASI-MV interface introduces the
functionality required to run the Commercial off the Shelf (COTS) Addiction Severity Index Multimedia Version (ASIMV) software. The interface allows clinicians and patients to enter demographics and self-administered ASI-MV
interviews via a PC workstation using video and audio technology. The VistA MH ASI-MV interface works mostly in
the background. The demographic and interview data is temporarily stored on a PC workstation when an interview is
completed and saved to the VistA MH database automatically when the software is executed again.
Commercial Off The Shelf (COTS) ASI-MV Software
The COTS ASI-MV software is an effective, efficient, and scientifically researched tool used in substance abuse
treatment centers, employee assistance programs, and other healthcare settings. The software utilizes a mousedriven personal computer (PC) for administering an ASI-MV interview and gathering clinical data directly from a
client/patient/employee. The COTS ASI-MV software generates VistA -compatible data records that can be uploaded
to the VistA database.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-116
class MH: Addiction Sev erity Index
Name:
Package:
Version:
Author:
MH: Addiction Severity Index
MH: Addiction Severity Index
Dec 2011
OSEHRA
Mental Health
ASI-MV GUI
PCMM-Primary Care
Management Module
MH v5.01
ASI-MV
Kernel
v8.0
Kernel
Toolkit
v7.3
Pharmacy: Data
Management
CPRS v
1.0.24.26
RPC-Broker v1.1
RPC-Remote
Procedure Call
Broker
Kernel Toolkit
CPRS: Clinical
Reminders
CPRS: TIU-Text
Integration Utility
Namespace
YS
Patch YS*5.01*67 MUST be installed prior to installing VistA
Mental Health ASI-MV Patch YS*5.01*78.
NOTE: YI and YT namespaces are used for testing and
interview related software. All other software functionality has
been placed in the YS namespace.
Documents available in the vdl: (http://www.va.gov/vdl/application.asp?appid=78)
Name Date Created Last Updated

MH ASI-MV Installation and User Guide (Patch YS*5.01*78) 2004-11-01 2004-11-09
2876
2877
2878
2879
2880
2881
Figure: 3.1-60
ASI-MV - (Component diagram)
cmp ASI-MV
ASI-MV
«interface»
ASI-MV::ASI-MV
COTS ASI-MV
2882
2883
2884
2885
Figure: 3.1-61
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-117
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
3.1.45 MRSA-Methicillin Resistant Staph Aurerus
Manual data collection for the MRSA (Methicillin-Resistant Staphylococcus Aureus) Prevention Initiative is time
consuming. The MRSA Program Tools (MRSA-PT) application provides a method to extract data related to MRSA
nares screening, clinical cultures, and patient movements within the selected facility. MRSA-PT contains reports that
will extract and consolidate required data for entry into the Inpatient Evaluation Center (IPEC). Reports can also be
generated to display real-time patient specific information, and can be used to identify patients that have a selected
multi-drug resistant organism (MDRO) and to identify patients who did or did not receive a MRSA nares screen upon
admission to the unit.
Figure: 3.1-62
3.1.46 MED-Mobile Electronic Documentation
[Version TIU Patches 1.0 and MED GUI 2.3]
Mobile Electronic Documentation (MED) is an application that allows the creation of remote documentation and then
import of that documentation into a note in Computerized Patient Record System (CPRS). It allows you to view
Health Summary and MED Created Notes for patients in Home Based Primary Care (HBPC) Clinics.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-118
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
Figure: 3.1-63
3.1.47 NHIN-Nationwide Health Information Network Adapter
The purpose of the Department of Veterans Affairs (VA) Nationwide Health Information Network (NHIN) Gateway
Adapter Version 2.0 is to implement the actions necessary to exchange electronic health records (EHRs) generated
from the VA and received from authorized NHIN Health Information Exchanges (HIEs). The VA NHIN Gateway
Adapter uses a service-oriented architecture (SOA) to share patient health data and to communicate between
systems.
The VA NHIN Adapter interfaces with the VA NHIN CONNECT Gateway, which is an implemented instance of the
Federal CONNECT Gateway software. The Federal NHIN CONNECT Gateway is the product deliverable of the
Federal Health Architecture (FHA), under the Department of Health and Human Services (HSS). This product is the
result of the collaboration and shared development cost of a group of more than twenty government agencies known
as the Federal Consortium. The VA has been exchanging medical information with the Department of Defense (DoD)
for several years. By using the VA CONNECT Gateway together with the VA NHIN Adapter, the VA will now be able
to share patient health data with other federal partners, as well as private providers, such as Kaiser Permanente.
The VA NHIN Gateway Adapter is a HealtheVet-VistA application that acts as a gateway between the VA and other
Health Information Exchanges (HIEs) to share patient clinical records. The VA NHIN Gateway Adapter is deployed as
a single, national instance at AITC (Austin Information Technology Center). Payloads are standards-based CDA
(Clinical Document Architecture) XML documents. VistA data is retrieved through the use of VistALink-mediated RPC
calls; HIE data retrieved by the NHIN Adapter is displayed by VistAWeb. The NHIN Adapter provides a read-only
service: it does not create a clinical repository with the data it mediates.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-119
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
Figure: 3.1-64
3.1.48 Nursing
Nursing is a component of the Department of Veterans Affairs VistA program. It is comprised of modules
Administration, Clinical, Education, Performance Improvement, and Research.
Administration:
1) Personnel management information (demographic and professional data of nursing staff),
2) Resource management/analysis tracking for reports on budgeting DRGs, overtime usage,
patient care hours, supply equipment projections, and staffing hours, and
3) Mandatory reports (i.e., AMIS 1106, AMIS 1106a, Annual Report).
Clinical:
1) Patient classification,
2) Patient assessment,
3) Nursing care plans which are system focused and contain both nursing problems and medical diagnoses,
4) Patient care assignments,
5) Clinical protocols/guidelines for care,
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-120
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
6) Patient education material,
7) Discharge planning, and
8) Other patient related medical record data.
Education:
1) Education reports (i.e., mandatory inservice attendance, continuing education attendance,
authorized absence/funding analysis), and
2) Student affiliation information (i.e., scheduling of student clinical labs, affiliation agreements).
Performance Improvement:
1) QA problem tracking system,
2) Infection control trends,
3) Patient incident analysis,
4) Employee accident analysis,
5) Continuous care monitors (clinical data), and
6) Administrative monitors (e.g., safety equipment).
Research:
1) Resource listing of VA nurse researchers, and
2) Additional functionalities as defined by the Nursing Focus Group.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-121
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
Figure: 3.1-65
3.1.49 NFS-Nutrition and Food Service
The VistA Nutrition and Food Service Systems software integrates the automation of many Clinical Dietetics and
Food Management functions. The Clinical Dietetics activities of nutrition screening, nutrition assessment, diet order
entry, tubefeeding and supplemental feeding orders, patient food preferences, specific diet pattern calculations,
nutrient analysis of meals, consult reporting, encounter tracking, and quality care monitoring are all available in this
program. Complete automation of food production activities, service and distribution, inventory and cost
management, recipe expansion, menu and recipe nutrient analysis, meal and diet pattern development and
implementation, diet card and tray ticket printing, quality service tracking, and annual management reports are also
available. Detailed functionality and process activity for Nutrition and Food Service software are divided into two
major areas of use: (1) options that the Manager/ADPAC needs to build files, set parameters, review data, and
generate reports; and (2) options the general user needs for normal day-to-day automated Nutrition functions.
Features:
• Allows the building of a site-specific listing of patient food preferences that can be incorporated in meal
production calculations and the printed diet card and tray tickets programs.
• Manages patients' requests or dietary requirements for specific food items or utensils, allowing the selection of
standing orders for any patient, for any meal or quantity.
• Controls all aspects of ingredient usage.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-122
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
•
•
•
•
•
•
•
•
•
Develops a list of site-specific recipes that includes portion size, preparation area and time, equipment and
serving utensils, recipe category, ingredients, and directions for preparation. Recipes can be quickly analyzed for
their nutrient value.
Creates multiple meals and menu cycles. Meals can be used in different patterns by creating menu cycles or by
creating special holiday dates within a cycle. It allows for the nutrient analysis of meals or daily/weekly menus.
Controls quantities produced in the Food Management program. Specific patient diet orders are reorganized into
production diets and diet patterns that reflect the foods to be served. This information is used along with data
from the meal file to generate production reports, diet cards and/or tray tickets. A forecasting tool also exists in
this section that allows the manager to anticipate, by percentage of total census, the type and quantity of various
production diets that will be needed by any selected service point.
Allows the entry of information required by the Annual Report that is not automatically retrieved from the
program.
Prints a patient-specific record of all diet order entry information.
Controls the order entry activity.
Manages food items and their nutrients using the latest USDA data, food items from Bowes and Church, and
additional data from research.
Handles N&FS consults and allows the reassignment of active consults from one staff member to another.
Manages the supplemental feeding food items and menus. A supplemental feeding menu automatically goes
into effect at the time of diet order entry and changes automatically with new orders.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-123
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
Figure: 3.1-66
3.1.50 Oncology
OncoTraX: Cancer Registry is an integrated collection of computer programs and routines, which work together in
assisting the Cancer Registrars to create and maintain a cancer patient database. The software creates case listings
and registry reports for Cancer Boards (Cancer Conferences), special studies, and the Annual Report recommended
by the American College of Surgeons (ACoS).
The software allows the Cancer Registrars to:
1. Perform case finding.
2. Identify potential cases to include in your registry, enter the pertinent data directly into the computer system, and
maintain patient follow-up information on an annual basis.
3. Enter abstracts.
4. Download and transmit data electronically to the VA Central Cancer Registry, state central registries, the National
Cancer Database for the ACoS Call for Data.
5. Produce several reports by using an option in the Utility menu.
Note: Several reports within the software provide basic information; however, for more specific reports, you need to
know basic FileMan functions. Any and all data collected within an abstract can be pulled back into reports.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-124
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
6. Print out by year the number of cases by site, including sex, race, and stages.
7. Generate follow-up reports as required by the ACoS
Note: OncoTraX is in complete compliance with all ACoS required data elements, and is updated as changes occur.
OncoTraX is used by cancer registrars and meets all requirements set forth by the American College of Surgeons for
approved cancer programs.
Note: OncoTraX makes extensive use of Help screens, but it does not replace the use of your reference manuals.
Features:
• The software supports multi-divisional sites.
• The program automatically finds cases by searching the database from Anatomical Pathology (Surgery,
Cytology, Electron Microscopy, and Autopsy), Radiology, and Patient Treatment File (PTF). Cases can be
entered into the Suspense File by date of diagnosis, and chart request pull lists can be printed.
• Demographics are drawn directly from Patient Information Management System (PIMS) patient file and stored
permanently. Cancer identification data is obtained from the local database (e.g., laboratory and radiology test
results).
• The program accessions and abstracts with extensive on-line help and stages the extent of disease
automatically.
• It produces a wide range of follow-up lists and registry lists needed for accreditation and allows entry of contacts
directly into Oncology Contact File.
• Professional letters covering diverse situations and customization of letters are available.
• Predefined annual reports can be generated and the user can create specialized reports using VA FileMan.
• Reports to the Associate Chief of Staff (ACOS) can be generated using special routines that extract data onto
floppy disk. The same functionality is available for state reporting.
• The database can be customized to suit the individual hospital.
• The full set of TNM codes is included from the appropriate edition of the AJCC Manual on Staging of Cancer.
• The program allows on-line completion of Patient Care Evaluations (PCEs) during the abstracting function if the
case being abstracted fulfills the selection criteria for the PCE.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-125
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
Figure: 3.1-67
3.1.51 PAIT-Patient Appointment Information Transmission
The Patient Appointment Information Transmission (PAIT) was developed and released in patch SD*5.3*290 to
provide patient appointment wait time statistics to the national database in Austin, TX. An initial seeding routine
scanned patient appointments created from September 1, 2002 to the date that Patch SD*5.3*290 was installed. The
One-Time Option Queue from the TaskMan Management menu was used to start SD-PAIT TASKED
TRANSMISSION on a scheduled date per site—each of the 128 sites at the time was assigned its own start date.
Patch SD*5.3*290 was released on November 26, 2003. Only Pending appointments were selected for the seeding
process. Subsequent bimonthly PAITs update the National Database. Appointment data is wrapped in HL7 batch
messages and transmitted to the Austin Information Technology Center (AITC). This additional data supplements the
existing Clinic Appointment Wait Time extracts 1 and 2. Transmissions should be scheduled on the 1st and 15th day
of each month. The bi-monthly task will collect and format data for HL7 batch transmission.
PAIT enhances the process of collecting and storing appointment data for bi-monthly transmission to the AITC:
• Capturing selected data about the patient’s appointment eligibility including Combat Veteran and Military History
• Identifying the date and time services were desired, scheduled and provided
• Tracking and updating appointments through checkout, cancellation, rebooking, etc.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-126
3079
3080
3081
3082
3083
3084
Figure: 3.1-68
PAIT-Patient Appointment Information Transmission - (Component diagram)
cmp PAIT-Patient Appointment Information Transmission
Patient Appointment
Information
Transmission
Veterans Health Administration Support
Service Center at the Austin Information
Technology Center (AITC)
3085
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-127
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
Figure: 3.1-69
3.1.52 PADP-Patient Assessment Documentation Package
There are no documents for this application at this point. [October 30, 2009]
Figure: 3.1-70
3.1.53 PCE-Patient Care Encounter
Patient Care Encounter (PCE) captures clinical data resulting from ambulatory care patient encounters. The captured
clinical data documents “encounters” and related encounter information, such as problems treated at encounter,
procedures done, immunizations, patient education, and skin tests.
PCE provides a data repository for long-term clinical data. A goal of PCE is to support many data capture methods
for integrating clinical data from many environments. Pilot efforts have included population of the PCE clinical
repository via scanner technologies and workstations. The key users of this clinical data are clinicians, management,
and Quality Management personnel.
Features
• Acts as VA’s long-term clinical repository, documenting encounters from local and non-VA facilities.
• Provides a primary and secondary clinical visit management utility based on appointments and related services.
• Interfaces with the Health Summary package to provide components based on data captured and stored in the
PCE clinical repository.
• Supports capture of outpatient encounter data. Data collection methods include:
o Interface between scanner/workstation and clinical repository.
o On-line data capture using List Manager user interface.
o Historical load utilities for lab and outpatient pharmacy.
o Future methods will include automatic protocol event driver.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-128
3112
3113
3114
3115
Figure: 3.1-71
PCE-Patient Care Encounter - (Component diagram)
cmp PCE-Patient Care Encounter
PCE-Patient Care
Encounter
«interface»
PCE-Patient Care
Encounter::PX
3116
3117
3118
PANDAS
TeleForm
Figure: 3.1-72
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-129
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3.1.54 Visit Tracking
Visit Tracking is documented as a part of PCE, "PCE V. 1.0 & Visit Tracking V. 2.0 Technical Manual "
Introduction
The Visit Tracking software is designed to link patient-related information in a filestructure that will allow meaningful
reporting and historically accuratecategorization of patient events and episodes of care.
Background
This version of Visit Tracking is a hybrid of a Visit Tracking module developed byand operating at Indian Health
Service (IHS) facilities as part of their Patient Care Component (PCC) and Visit Tracking V. 1.0 developed by the
Dallas InformationSystems Center (ISC) for the Joint Venture Sharing (JVS) sites and operating atAlbuquerque, NM.
The primary data file (VISIT file #9000010) developed by IHS is used with some additional fields and modifications
for VA needs. The supportingsoftware was developed with the intent to operate without modification in either facility.
Relationshipto other packages
Visit Tracking is not a stand-alone application. Other packages will normally callPCE, which will handle the calls to
Visit Tracking.
Functions provided
The Visit Tracking system provides three primary functions:
• Creating and/or matching a visit record using input criteria and user interaction(optionally)
• Providing a list of visits matching input criteria
• Maintaining the VISIT file (#9000010) and its records
Visit Tracking is a utility that can be used by a variety of VISTA modules, with potential benefits for clinical,
administrative, and fiscal applications. Visit Trackingwill allow VISTA packages to link an event to a patient visit entry,
thereby linkingthat event to any number of events occurring throughout the hospital during thepatient’s outpatient
and/or inpatient episode.
Benefits
• The VISIT file (#9000010) will be a key file in the implementation of the clinicalrepository.
• The VISIT file provides a home for documenting when and where other facilityevents have occurred.
• Medical Care Cost Recovery (MCCR) can obtain billing information related to aclinic visit, a step towards
itemized billing.
• Visit Tracking provides an environment for relating clinical information to theservice visit for workload tracking or
query by service views, as well as by theaggregate clinic visit view.
• Users have the potential to control the Visit level of granularity while reviewingpatient information (e.g., only view
visits from the primary clinic visit level: anaggregate view or only ancillary visits).
• The date and time stamp on clinic and ancillary visits could be useful forretrospective work flow analysis. It may
be exploitable as a Clinical EventSummary file useful to researchers doing longitudinal patient studies.
• A breakdown of clinical care provided by primary and secondary providers couldhelp document the clinical
experience of trainees (including residents, interns, and other clinicians) who require this information for
privileging andcredentialing purposes.
• Visit tracking has the capability to generate patient activity reports that arebased on accurate historical
information.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-130
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
•
•
•
The category of patient receiving care can be identified based on a specificepisode of care.
Medical data can be stored for historical purposes without the requirements ofspecific fields, except for the
patient and date.
Visit tracking has the ability to associate ancillary services provided to a patient with a DSS ID, admission, and
non-patient encounter (phone contact, pharmacy mail-out, etc.)
Figure: 3.1-73
3.1.55 Patient Record Flags
Patient record flags are used to alert VHA medical staff and employees of patients whose behavior and
characteristics may pose a threat either to their safety, the safety of other patients, or compromise the delivery of
quality health care. These flag assignments are displayed during the patient look-up process.
The use of patient record flags must be strictly controlled and implemented following the instruction provided in VA
Directive 2003-048 (see Appendix).
The Patient Record Flags (PRF) software provides users with the ability to create, assign, inactivate, edit, produce
reports, and view patient record flag alerts. Patient record flags are divided into Category I (national) and Category II
(local) flags.
Category I flags are nationally approved and distributed by VHA nationally released software for implementation by
all facilities. The Category I flag is shared across all known treating facilities for the patient utilizing VistA HL7
messaging.
Category II flags are locally established by individual VISNs or facilities. They are not shared between facilities.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-131
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
Figure: 3.1-74
3.1.56 AR/WS-Pharmacy: Automatic Replenishment/ Ward Stock
Automatic Replenishment (AR)/Ward Stock (WS) is a method of drug distribution and inventory management within a
hospital. Drug products can be automatically inventoried and delivered (AR) to an area of use (AOU) or requested on
demand (WS). An area of use is the place where commonly stocked items are stored. The area is potentially
composed of wards, clinics, and specialties. The Automatic Replenishment process usually consists of the following
functions: 1) select the AOUs and types of items within each AOU to be inventoried, 2) visit each AOU and take
inventory, 3) determine the quantity to be dispensed for each item, and 4) dispense the item. The Automatic
Replenishment module is designed to allow each VAMC to adapt the system to its own needs.
Version 2.3 of the AR/WS package contains several new features. Several new options have been added. On the
Supervisor’s Menu there is now a Duplicate Entry Report option that prints a report of duplicate entries. The report
will show all inventory, return, and on-demand data for each drug selected. The Single AOU Inventory Print option
has been added to the Production menu. This option will print an inventory sheet for a single AOU that is included in
the inventory date/time. In addition, a new Crash Cart Menu has been added, and all reports have been modified to
allow selection of AOUs by Inventory Group and changed to form feed only at the end of a report.
Features:
The AR/WS package:
• Provides inventory management capabilities for clinical care locations and drug crash carts.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-132
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
•
•
•
•
•
•
•
•
•
Allows easy drug item inactivation for inventory locations.
Provides tools to develop medication storage areas with lists of drugs to be maintained in that area. Drugs are
classified by inventory type and assigned storage location and stock level.
Groups medication storage areas together by inventory group name. Grouping may be by location, date (time or
frequency of inventory), or inventory type.
Provides tools to conduct inventory: prints inventory sheets and/or pick lists to determine stock to be replenished
in medication storage areas and, by a selected method, replaces needed inventory items.
Maintains backorder totals if a physical inventory is conducted and entered into AR/WS software.
Provides inventory management reporting capabilities for clinical care locations and drug crash carts.
Provides ability to select by inventory group on all reports.
Supplies a report to fill on-demand requests for out-of-stock items or items not part of the standard inventory.
Provides various printouts as well as several management statistical reports for the creation and maintenance of
the system.
Figure: 3.1-75
3.1.57 BCMA-Pharmacy: Bar Code Medication Administration
The Bar Code Medication Administration (BCMA) V. 3.0 software includes routines, files, enhancements,
maintenance fixes, and Phase Release changes for BCMA V. 2.0.
BCMA V. 3.0 software is designed to improve the accuracy of the medication administration process. By automating
this process, Department of Veterans Affairs Medical Centers (VAMCs) can expect enhanced patient safety and
patient care.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-133
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
The electronic information that BCMA V. 3.0 provides clinicians improves their ability to administer medications safely
and effectively to patients on wards during their medication passes. It also helps to improve the daily communication
that occurs between Nursing and Pharmacy staffs.
Features:
The BCMA software provides the following features:
• Medication Tabs on a patient’s Virtual Due List (VDL) are designed for separating and viewing the different types
of active Unit Dose, IV Push, IV Piggyback, and large-volume IV medication orders. Each Tab provides an “alert”
light, which turns green only when the patient has active medication orders for that Tab.
• Patient safety tools include a Missed Medications Report, an alert when due medications are not administered, a
notification when a patient is transferred, and an alert light to indicate that a medication order exists for the
Schedule Type and Start/Stop Date and Time selected on the VDL. Other tools include a listing of Allergies and
Adverse Drug Reactions (ADRs) that are documented for a patient in the Allergy/Adverse Reaction Tracking
(ART) package.
• A Computerized Patient Record System (CPRS) Med Order Button (or “Hot Button”) on the BCMA Tool Bar
streamlines the workflow in ICU-type environments. This button links nurses directly to CPRS for electronically
ordering, documenting, reviewing and signing verbal and telephone STAT and NOW (One-Time) medication
orders already administered to patients.
• BCMA increases the amount and type of information available to nurses at the point of care, improves
communications between Nursing and Pharmacy staff, records Missing Doses for patients, sends an electronic
Missing Dose Request to the Pharmacy, and supports Health Level Seven (HL7) messaging.
• Management and accountability tools identify PRN entries that require effectiveness comments and pain scores,
list medications that were not scanned as administered during an administration time window, list early/late
administration variances, and allow nurses to set site-specific parameters and defaults on their systems.
• Compiles reports by Patient or by Ward for Nursing, Pharmacy, and Information Resources Management (IRM).
Reports available for printing include: a Medication Administration History, Medication Log, Missed Medications,
Missing Dose Request, PRN Effectiveness Log, Medication Due List, Medication History, Medication Variance
Report, Cumulative Vitals/Measurement Report, and Administration Times Report.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-134
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
Figure: 3.1-76
3.1.58 PBM-Pharmacy: Benefits Management
Pharmacy Benefits Management (PBM) V. 4.0 is a new enhanced version of the software and replaces PBM V. 3.0.
In a series of three enhancements, new extracts and reports were created, existing extracts were modified, and some
options were modified to increase the functionality of this software package. For more detail, refer to the Pharmacy
Benefits Management V. 4.0 Release Notes document.
The software extracts medication dispensing data elements from the Outpatient Pharmacy, Inpatient Medications
Intravenous (IV) and Unit Dose (UD), Automatic Replenishment/Ward Stock (AR/WS), Controlled Substances (CS)
modules, Procurement information from Drug Accountability, Integrated Funds Control, Accounting and Procurement
(IFCAP), and a limited amount of Laboratory data on a monthly basis.
The extracted data is electronically exported via MailMan to the PBM section in Hines, Illinois. MailMan messages
are downloaded to text files onto the PBM network. These electronic messages are then passed through a translation
process, which pulls text files into a database format and is checked for quality assurance and converts all local drug
names to a common drug name and all local dispensing units to a common dispensing unit if possible. After
translation, the information is added to the PBM national database.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-135
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
Through an option placed on the pharmacy supervisor menu, the software makes data extraction reports available at
local Veterans Affairs Medical Centers (VAMCs) and allows local management to use this data to project local drug
usage and identify potential drug accountability problem areas. The PBM section is able to provide information on
Local Facility, Veterans Integrated Service Network (VISN), and National product use on monthly, quarterly, and
annual intervals. Pharmacy personnel at VAMCs and VISNs shall use this application to collect and report on
pharmacy and patient statistics through user-executed options. Users of the database include the PBM, VAMCs,
VISNs, and the research community.
PBM V. 4.0 extracts additional data elements and modifies current extracts to take advantage of enhancements
made to the other Pharmacy modules since the release of previous versions (D&PPM V. 2.0) and PBM V. 3.0.
3290
3291
3292
Figure: 3.1-77
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-136
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3.1.59 Pharmacy: Consolidated Mail Outpatient Pharmacy
The Consolidated Mail Outpatient Pharmacy (CMOP) software package establishes an interface for the electronic
transfer of information between Veterans Affairs Medical Centers (VAMCs) and the Consolidated Mail Outpatient
Pharmacy host system for an integrated and highly automated outpatient prescription dispensing system.
Figure: 3.1-78
3.1.60 Pharmacy: Controlled Substances
The Controlled Substances (CS) software package is one segment of the Veterans Health Information Systems and
Technology Architecture (VISTA) installed at VA medical centers. The Controlled Substances module provides
functionality to monitor and track the receipt, inventory, and dispensing of all controlled substances. This module
provides the pharmacy with the capability to define a controlled substance location and a list of controlled substances
to maintain a perpetual inventory.
This software provides the capability for pharmacy personnel to receive a Controlled Substances order, automatically
update the quantity on hand, and view a receipt history. Nursing personnel are provided with the ability to request
orders for Controlled Substances via on-demand requests. Pharmacy may dispense controlled substances via the
software automating all necessary documents (VA FORMS 10-2321 and 10-2638) to complete an order request. The
software provides functionality to record AMIS and Cost data, address returns to stock, destructions, order
cancellations, transfers between locations, and log outpatient prescriptions.
Monthly (or more frequent) inspections can be conducted by management, with discrepancies in stock levels
automatically identified.
Controlled Substances (CS) Version 3.0 will provide many new enhancements for both pharmacy and nursing users.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-137
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
A list of the new additions and modifications to existing options includes:
• Batch Order Entry process
• Electronic Signature
• HL7 Interface to Narcotic Dispensing Equipment
• Electronic Error & Enhancement Requests (E3Rs)
• Green Sheets now print on plain paper
• Other Enhancements
Figure: 3.1-79
Pharmacy: Controlled Substances - (Component diagram)
cmp Pharmacy: Controlled Substances
Pharmacy:
Controlled
Substances
«interface»
Pharmacy:
Controlled
Substances
3330
3331
NDES - Narcotic Dispensing Equipment
Systems
Figure: 3.1-80
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-138
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3.1.61 Pharmacy: Data Management
Pharmacy Data Management (PDM) provides tools for managing Pharmacy data. It includes tools for creating
Pharmacy Orderable Items and maintaining files necessary for the Computerized Patient Record System (CPRS).
PDM consolidates tools for managing the various Pharmacy software products. It provides Pharmacy Supervisors, in
one location, the capability to enter and edit data from the local DRUG file (#50) for all Pharmacy related packages.
PDM now allows users to enter medication instruction components (e.g., dosage, noun, verb, expansion) in a
language other than English. However, at this time, the Patient Medication Information Sheets only allow patient data
to be in English or Spanish.
Figure: 3.1-81
3.1.62 Pharmacy: Drug Accountability
The Drug Accountability/Inventory Interface program (referred to as DA) V. 3.0 works toward a perpetual inventory for
each Veterans Affairs facility’s pharmacy. This is achieved by tracking drugs through pharmacy locations based on
the connection between the DRUG (#50) file and ITEM MASTER file (#441) or between the prime vendor’s invoice
file and the DRUG file (#50).
The DA V. 3.0 software package provides functionality to maintain a perpetual inventory of drugs. Interfacing with the
Generic Inventory Package (GIP) and the prime vendors’ invoice data increments drug balances in pharmacy
locations and master vaults. Pharmacy’s dispensing software packages pass dispensing data to DA V. 3.0 which
decrements the drug balances in pharmacy locations.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-139
3354
3355
3356
3357
Figure: 3.1-82
Pharmacy: Drug Accountability - (Component diagram)
cmp Pharmacy: Drug Accountability
Pharmacy: Drug Accountability
«interface»
Pharmacy: Drug
Accountability
DHCP - Decentralized Hospital Computer Program
procomm plus v2.01
3358
3359
3360
3361
3362
3363
Figure: 3.1-83
3.1.63 Pharmacy: Inpatient Medications
The Inpatient Medications package provides a method of management, dispensing, and administration of inpatient
drugs within the hospital. Inpatient Medications combines clinical and patient information that allows each medical
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-140
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
center to enter orders for patients, dispense medications by means of Pick Lists, print labels, create Medication
Administration Records (MARs), and create Management Reports. Inpatient Medications also interacts with the
Computerized Patient Record System (CPRS) and the Bar Code Medication Administration (BCMA) packages to
provide more comprehensive patient care.
Features:
Integrated software allows these features, via the List Manager interface, for both IV and Unit Dose. This provides the
user the capability to:
• Browse through a list of orders and take action(s) against those items.
• Print 7-day, 14-day, and 24-hour MARs, labels, and profiles from within the options.
• Select a detailed allergy report, document new allergies or adverse drug reactions.
• Update the Patient’s Record from within List Manager.
• Provides Drug/Drug Interaction, Drug/Class Interaction, Duplicate Drug, and Duplicate Class Order checks.
• Allows easier drug selection using Orderable Item.
• Provides on-line order maintenance (for example: edit, renewal, cancellation) and marks orders that need
attention.
• Provides on-line order entry with an integrity check for each order type.
• Generates labels containing order and patient information upon the entry/maintenance of an order.
• Provides on-line or printed patient profiles that include a history of medication orders for the current or last
medical center visit.
• Displays patient order information and histories of all actions taken on active orders.
• Provides an Action Profile of patient medication orders for use by physicians to cancel or continue medications.
• Provides a Stop Order Notice report to notify users of orders near expiration.
• Cancels/holds medication orders for patients transferred between wards and/or services.
• Provides dispensing cost reports by patient, ward, service, drug, and providers.
• Provides reports and forms by patient, ward, and selected groups of wards.
• Allows electronic entry and inpatient processing of medication orders for an outpatient receiving treatment via a
clinic or ancillary service.
Pharmacy: Inpatient Medications - Intravenous (IV)
Inpatient Medications’ Intravenous (IV) module provides pharmacists and their staffs with IV labels, manufacturing
worksheets, ward lists for order updates, and management reports. It permits the Pharmacy staff to track the
manufacture of IV formulas with greater control than manual procedures allow.
Through order entry and ward list updating, the staff can easily establish and maintain an accurate and timely data
set of IV orders. A carefully designed set of checks and balances has been incorporated to ensure that the patient is
supplied IV solutions quickly and accurately.
Features:
IV module:
 Generates Manufacturing Lists to facilitate maximum efficiency in the preparation and delivery of IV products.
 Generates IV labels containing all necessary patient, drug, and schedule information. Labels provide a barcoded identifier which when used in conjunction with Bar Code Med Administration greatly enhances patient
safety.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-141
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423



Generates management reports designed to track drug costs and workload by ward, provider, IV room, and
patient.
Provides on-line generation of production reports such as renewal lists, active order lists, and formulary drug
reports.
Discontinues/holds orders for patients transferred between wards and/or services.
Pharmacy: Inpatient Medications - Unit Dose (UD)
The Unit Dose (UD) module of Inpatient Medications provides a standard computerized system for dispensing and
managing inpatient medications. Timely, accurate, accessible, and up-to-date patient medication information is
available from any terminal within the facility. Computer-generated working forms allow personnel to dedicate more
time to patient care.
Features:
Unit Dose module:
 Allows immediate entry of pre-defined sets of unit dose orders.
 Provides computerized pick lists, which include pre-calculated doses for pharmacists.
 Provides an interface to automated dispensing equipment.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-142
3424
3425
3426
3427
3428
3429
3430
3431
Figure: 3.1-84
Documents available in the vdl: (http://www.va.gov/vdl/application.asp?appid=88)
Name Date Created
Last Updated

API Manual - Pharmacy Reengineering (PRE) 2010-02-10
2010-02-10

Installation Guide- MOCHA v1.0 Combined Build (PSS*1*117, PSO*7*251, PSJ*5*181, OR*3*272, PSO*7*375,
PSS*1*163) REVISED
2011-08-12
2011-08-12

Nurse's User Manual 2011-07-12
2011-07-12
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-143
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475











































Nurse's User Manual Change Pages - PSJ*5*1132010-06-23
2010-06-23
Nurse's User Manual Change Pages - PSJ*5*1202007-06-08
2007-06-08
Nurse's User Manual Change Pages - PSJ*5*1342008-08-26
2008-08-26
Nurse's User Manual Change Pages - PSJ*5*1452007-08-06
2007-08-06
Nurse's User Manual Change Pages - PSJ*5*160/175
2007-10-25
2007-10-31
Nurse's User Manual Change Pages - PSJ*5*1812011-04-20
2011-04-20
Nurse's User Manual Change Pages - PSJ*5*1962009-03-23
2009-03-23
Nurse's User Manual Change Pages - PSJ*5*2152009-10-28
2009-10-28
Nurse's User Manual Change Pages - PSJ*5*2222010-02-05
2010-02-05
Nurse's User Manual Change Pages - PSJ*5*2432011-07-12
2011-07-12
Pharmacist's User Manual
2011-07-12
2011-07-12
Pharmacist's User Manual Change Pages - PSJ*5*113 2010-06-23
2010-06-23
Pharmacist's User Manual Change Pages - PSJ*5*120 2007-06-08
2007-06-08
Pharmacist's User Manual Change Pages - PSJ*5*134 2008-08-26
2008-08-26
Pharmacist's User Manual Change Pages - PSJ*5*145 2007-08-06
2007-08-06
Pharmacist's User Manual Change Pages - PSJ*5*160/175
2007-10-25
2007-10-31
Pharmacist's User Manual Change Pages - PSJ*5*181 2011-04-20
2011-04-20
Pharmacist's User Manual Change Pages - PSJ*5*196 2009-03-23
2009-03-23
Pharmacist's User Manual Change Pages - PSJ*5*214 2010-02-24
2010-02-24
Pharmacist's User Manual Change Pages - PSJ*5*215 2009-10-28
2009-10-28
Pharmacist's User Manual Change Pages - PSJ*5*222 2010-02-05
2010-02-05
Pharmacist's User Manual Change Pages - PSJ*5*232 2010-10-13
2010-10-13
Pharmacist's User Manual Change Pages - PSJ*5*243 2011-07-12
2011-07-12
Pharmacy Ordering Enhancements (POE) Phase 2 Installation Guide
2001-09-01
2001-09-24
Release Notes (CPRS V27 Project)
2008-08-26
2008-08-26
Release Notes (IMO Project) 2006-04-01
2006-04-30
Release Notes (IMO-Phase I II and IMR-Phase II)
2005-03-01
2005-03-31
Release Notes (IMO/IMR-Phase II)
2005-01-01
2005-01-31
Release Notes (IMR-Increment I)
2010-06-23
2010-06-23
Release Notes (IMR-Phase I) 2004-09-01
2004-10-06
Release Notes (Medication Order Check Healthcare Application (MOCHA) v1.0)
2011-04-20
201104-20
Release Notes (Patients on Specific Drug(s) Multidivisional Enhancements) 2010-02-23
2010-02-23
Release Notes (PBM Demographics Enhancements)
2009-07-21
2009-07-21
Release Notes (POE) 2001-09-01
2001-09-24
Release Notes (PSJ*5*160/175)
2007-10-25
2007-12-06
Release Notes (RDI Project) 2005-12-01
2005-12-22
Supervisor User Manual
2011-04-20
2011-04-20
Supervisor User Manual Change Pages - PSJ*5*120
2007-06-08
2007-06-08
Supervisor User Manual Change Pages - PSJ*5*181
2011-04-20
2011-04-20
Supervisor User Manual Change Pages - PSJ*5*214
2010-02-24
2010-02-24
Technical Manual / Security Guide
2011-04-20
2011-04-20
Technical Manual / Security Guide Change Pages - PSJ*5*113
2010-06-23
2010-06-23
Technical Manual / Security Guide Change Pages - PSJ*5*134
2008-08-26
2008-08-26
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-144
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518






Technical Manual / Security Guide Change Pages - PSJ*5*178
Technical Manual / Security Guide Change Pages - PSJ*5*181
Technical Manual / Security Guide Change Pages - PSJ*5*214
Technical Manual / Security Guide Change Pages - PSJ*5*222
Technical Manual / Security Guide Change Pages - PSJ*5*226
Version 5.0 Release Notes
1997-12-01
1998-12-31
2007-02-13
2011-04-20
2010-02-23
2010-02-05
2011-03-14
2007-02-13
2011-04-20
2010-02-23
2010-02-05
2011-03-14
3.1.64 Pharmacy: National Drug File
The National Drug File (NDF) V. 4.0 software module provides standardization of the local drug files in all
Department of Veterans Affairs Medical Centers (VAMCs). Standardization includes the adoption of new drug
nomenclature and drug classification, and links the local drug file entries to data in the National Drug files.
For drugs approved by the Food and Drug Administration (FDA), VAMCs have access to information concerning
dosage form, strength and unit; package size and type; manufacturer’s trade name; and National Drug Code (NDC).
The NDF software lays the foundation for sharing prescription information among VAMCs.
With this version of NDF, a new design of the NATIONAL DRUG file (#50.6) will lay the foundation for timely data
releases by Pharmacy Benefits Management (PBM) personnel to field facilities using the NDF Management System.
As new drug products are released, this information can be quickly sent to facilities. Pharmacy end users will be able
to match (classify) a greater percentage of their local drug files for new products. Update/delivery of data will be
controlled by PBM personnel. Frequent updating of NDF will be possible with minimal time for installation and
downtime.
In addition to the redesign of NATIONAL DRUG file (#50.6), Version 4.0 will provide the following enhancements:
• Addition of new fields to NDF, such as National Formulary and restriction indicators.
• Lay foundation for interfaces to other Commercial Off The Shelf (COTS) software to update NDF fields for
new/revised drug information.
• Update current NDF with new/revised product information.
• Creation of an Application Programmer’s Interface (API) to accommodate all existing VISTA software Database
Integration Agreements (DBIAs) with NDF.
• A clean-up of associated files, such as DRUG MANUFACTURER (#55.95), DRUG UNITS (#50.607), etc.
• Incorporation of approved enhancement requests by Pharmacy/ Information Resources Management (IRM) end
users.
Features:
National Drug File:
• Standardizes drug file information.
• Standardizes drug classifications.
• Adopts standard nomenclature.
• Provides up-to-date prescription and over-the-counter information.
• Provides available sources for drugs manufactured and approved by the FDA.
• Provides a base for implementation of drug inventory control and management throughout VA (i.e., Consolidated
Mail Outpatient Pharmacy and Pharmacy Benefits Management).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-145
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
•
•
•
•
•
•
•
Allows file access by NDC, manufacturer’s trade name, ingredient, dosage form, dosage strength, route of
administration, and VA drug classification.
Allows management of drug information, including reports on drugs by classification, ingredient, NDC, trade
name, and/or active/inactive status.
Matches additions to medical center drug files with the national drug database.
Provides an ingredient file that is an integral component of the Allergy Tracking and Outpatient Pharmacy (drugdrug interactions) modules.
Provides an enhanced formulary report listing local, VISN, and National Formulary information.
Includes the Patient Medication Information Sheets that feature the following:
o An explanation of how and why to take a medication and the possible side effects.
o Information supplied by commercial sources.
o Information that is copyrighted and periodically updated.
Utilizes data provided and standardized by First DataBank for point of sale electronic billing using Electronic
Claims Management Engine (ECME).
3533
3534
3535
Figure: 3.1-85
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-146
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3.1.65 Pharmacy: Outpatient Pharmacy
The Outpatient Pharmacy (OP) software provides a way to manage the medication regimen of veterans seen in the
outpatient clinics and to monitor and manage the workload and costs in the Outpatient Pharmacy. The Pharmacy
Ordering Enhancements (POE) project (patch PSO*7*46 for Outpatient Pharmacy) improves the flow of orders
between Inpatient and Outpatient Pharmacy as well as between Computerized Patient Record System (CPRS) and
backdoor pharmacy.
The primary benefits to the veteran are the assurance that he or she is receiving the proper medication and the
convenience of obtaining refills easily. The clinicians and pharmacists responsible for patient care benefit from a
complete, accurate, and current medication profile available at any time to permit professional evaluation of treatment
plans. Utilization, cost, and workload reports provide management cost controlling tools while maintaining the highest
level of patient care.
The Outpatient Pharmacy V. 7.0 package:
• Provides a method for managing the medications given to veterans who have visited a clinic or who have
received prescriptions upon discharge from the hospital.
• Automatically generates prescription labels, and prints refill request forms.
• Medication histories are kept online to permit checks for potential interactions.
• Profiles can be generated to assist the clinician in managing the patient's medication regimen.
• Management reports aid the pharmacy in controlling inventory and costs.
A number of site parameters allow the individual Department of Veterans Affairs Medical Center (VAMC) to
customize the package to meet local needs.
Features:
Outpatient Pharmacy package:
• Checks new prescriptions against existing prescriptions (for the same medication, therapeutic class, reported
allergies, reactions, or drug interactions).
• Allows pharmacists to verify data entered by technicians prior to the printing of labels.
• Allows for the renewal of prescriptions that have no remaining refills. Prints labels for new,
• Auto-cancels individual prescriptions for a patient after admission for inpatient treatment.
• Creates medication profiles for patient charts to meet the Joint Commission on Accreditation of Healthcare
Organizations (JCAHO) requirements for a current medication list. Profiles are suitable for counseling patients.
• Allows the Action Profile to be used as a quick renew/cancel request form by clinic providers, which allows for
rapid entry of request by Pharmacy staff.
• Provides the Screen Profile for review at several points in the order/entry process.
• Provides basic Drug Use Evaluation (DUE) template generator.
• Provides necessary laboratory checks and reports to meet national requirements for Clozapine dispensing.
• Provides finishing of orders entered through CPRS.
• Provides information for billing any applicable medication co-payment when the prescription is released.
• Allows the user to select a different action without leaving an option.
• Uses List Manager features to allow:
o Pharmacist or technician to browse through a list of actions.
o Pharmacist or technician to take action against those items.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-147
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590




o User to select an action that displays an action or informational profile.
Works with Integrated Billing (IB) and Electronic Claims Management Engine (ECME) to enable and manage
point of sale billing supporting the Healthcare Insurance Portability and Accountability Act (HIPAA) Electronic
Claims and Code set congressional mandate.
Allows prescription labels and Prescription Medication Information (PMI) sheets to be printed in another
language if the system has the other language fields populated in Pharmacy Data Management and the
individual patient is identified with the other language preference flag.
Allows the ability to print a microchip-embedded label for a prescription. This label can then be read by
ScripTalk®, thus improving patient safety for visually impaired veterans.
Provides display of Herbal, over the counter (OTC), and Non-VA medications documented through CPRS. The
data will be used for screening of Drug-Herbal and Drug-Drug Interactions with prescribed medications in VistA.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-148
3591
3592
3593
3594
3595
3596
3597
Figure: 3.1-86
Documents available in the vdl:
(http://www.va.gov/vdl/application.asp?appid=90)
Name Date Created Last Updated

API Manual - Pharmacy Reengineering (PRE)
www.oserha.org
2011-04-28
2011-04-28
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-149
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641






































Implementation Guide - Medication Reconciliation Tools 2008-06-11
2008-07-02
Installation Guide - Automation Interface 2004-10-01
2004-10-15
Installation Guide - Medication Reconciliation—Medication Worksheet (Tool #2)
2011-04-28
201104-28
Installation Guide - Pharmacy Ordering Enhancements (POE) Phase 2
2001-09-01
2001-09-01
Installation Guide - ScripTalk Talking Prescription Labels 2003-11-01
2003-10-29
Installation Guide- MOCHA v1.0 Combined Build (PSS*1*117, PSO*7*251, PSJ*5*181, OR*3*272, PSO*7*375,
PSS*1*163) REVISED
2011-08-12
2011-08-12
Installation Guide-FDA Medication Guides Project (PSS*1*158, PSN*4*263 and PSO*7*343) 2011-04-20
2011-04-20
Release Notes (PBM Demographics Enhancements)
2009-07-21
2009-07-21
Release Notes - Outpatient Pharmacy Version 7.0
1997-12-01
1997-12-15
Release Notes - Automation Interface 2004-10-01
2004-10-15
Release Notes - Bad Address Enhancements (PSO*7*233)
2006-10-06
2006-10-06
Release Notes - Clinical Indicator Data Capture 2005-08-01
2005-08-31
Release Notes - Combat Veteran Phase II
2004-05-01
2004-05-07
Release Notes - CPRS V27 Project
2008-08-26
2008-08-26
Release Notes - ePharmacy II (PSO*7*281)
2008-04-16
2008-04-16
Release Notes - ePharmacy Phase 4 COB (PSO*7*290) 2011-02-04
2011-02-04
Release Notes - ePharmacy Phase 4 Iteration II (PSO*7*289)
2009-07-16
2009-07-16
Release Notes - FDA Regulatory Changes for Clozapine 2006-10-06
2006-10-06
Release Notes - FY07 Q1 (PSO*7*258, PSO*7*250)
2006-12-21
2006-12-21
Release Notes - FY07 Q2 (PSO*7*200, PSS*1*122)
2007-04-16
2007-04-16
Release Notes - FY07 Q3 (PSO*7*268) 2007-07-19
2007-07-19
Release Notes - FY07 Q4 (PSO*7*264) 2007-10-24
2007-10-24
Release Notes - Herbal/OTC/Non-VA Meds Documentation
2004-05-01
2004-05-03
Release Notes - HIPAA NCPDP Connection for EDI Pharmacy
2006-04-01
2006-03-30
Release Notes - Laser Printed Prescription Labels Phase II
2005-03-01
2005-03-31
Release Notes - Laser Printed Rx Labels with PMI Sheets Phase I 2003-04-01
2003-04-30
Release Notes - Outpatient Medication Copay (PSO*7*71) 2001-11-01
2001-11-26
Release Notes - PFSS (PSO*7*201)
2006-10-19
2006-10-19
Release Notes - Pharmacy Ordering Enhancements (POE)
2001-09-01
2001-09-24
Release Notes - PLQE FY09 Q2 (PSO*7*320) 2009-08-07
2009-08-07
Release Notes - Remote Data Interoperability (RDI) Project
2005-12-01
2005-12-22
Release Notes - Tricare (dormant) Release (PSO*7*287) 2008-09-18
2008-09-18
Release Notes - Tricare Active Duty Release (PSO*7*358) 2010-12-17
2010-12-17
Release Notes - Tricare Release (PSO*7*303) 2008-12-04
2008-12-04
Release Notes and Installation Guide - AudioCARE Renewal (PSO*7*328) 2010-07-21
2011-01-10
Release Notes and Installation Guide - Pharmacy Ordering Enhancements (POE) Phase 1
2000-10-01
2000-10-01
Release Notes- Medication Order Check Healthcare Application (MOCHA) v1.0
2011-04-20
201104-20
Release Notes-FDA Medication Guides Project (PSS*1*158, PSN*4*263 and PSO*7*343)
2011-04-20
2011-04-20
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-150
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685












































Technical Manual/Security Guide - Outpatient Pharmacy V.7.0
2011-04-20
2011-04-20
Technical Manual/Security Guide Change Pages (PSO*7*225)
2008-08-25
2008-08-25
Technical Manual/Security Guide Change Pages (PSO*7*251)
2011-04-20
2011-04-20
Technical Manual/Security Guide Change Pages (PSO*7*279)
2008-07-09
2008-07-09
Technical Manual/Security Guide Change Pages (PSO*7*288)
2008-06-23
2008-06-23
Technical Manual/Security Guide Change Pages (PSO*7*289)
2009-07-16
2009-07-16
Technical Manual/Security Guide Change Pages (PSO*7*294)
2008-06-11
2008-06-11
Technical Manual/Security Guide Change Pages (PSO*7*305)
2009-06-03
2009-06-03
Technical Manual/Security Guide Change Pages (PSO*7*316, PSO*7*343) 2011-04-20
2011-04-20
Technical Manual/Security Guide Change Pages (PSO*7*320)
2009-08-07
2009-08-07
Technical Manual/Security Guide Change Pages (PSO*7*326)
2009-11-23
2009-11-23
Technical Manual/Security Guide Change Pages (PSO*7*348)
2010-07-15
2010-07-15
Technical Manual/Security Guide Change Pages (PSO*7*358)
2010-12-17
2010-12-17
User Manual - Manager - Outpatient Pharmacy V.7.0
2011-04-20
2011-04-20
User Manual - Manager Change Pages (PSO*7*289)
2009-07-16
2009-07-16
User Manual - Manager Change Pages (PSO*7*225)
2008-08-25
2008-08-25
User Manual - Manager Change Pages (PSO*7*251)
2011-04-20
2011-04-20
User Manual - Manager Change Pages (PSO*7*281)
2008-04-16
2008-04-16
User Manual - Manager Change Pages (PSO*7*288)
2008-06-23
2008-06-23
User Manual - Manager Change Pages (PSO*7*290)
2011-02-04
2011-02-04
User Manual - Manager Change Pages (PSO*7*294)
2008-06-11
2008-06-11
User Manual - Manager Change Pages (PSO*7*303)
2008-12-04
2008-12-04
User Manual - Manager Change Pages (PSO*7*305)
2009-06-03
2009-06-03
User Manual - Manager Change Pages (PSO*7*324)
2010-02-17
2010-02-17
User Manual - Manager Change Pages (PSO*7*326)
2009-11-23
2009-11-23
User Manual - Manager Change Pages (PSO*7*338)
2010-04-05
2010-04-05
User Manual - Manager Change Pages (PSO*7*348)
2010-07-15
2010-07-15
User Manual - Pharmacist - Outpatient Pharmacy V.7.0 2011-04-21
2011-04-21
User Manual - Pharmacist Change Pages (PSO*7*225) 2008-08-25
2008-08-25
User Manual - Pharmacist Change Pages (PSO*7*251) 2011-04-20
2011-04-20
User Manual - Pharmacist Change Pages (PSO*7*289) 2009-07-16
2009-07-16
User Manual - Pharmacist Change Pages (PSO*7*289) 2009-07-16
2009-07-16
User Manual - Pharmacist Change Pages (PSO*7*290) 2011-02-04
2011-02-04
User Manual - Pharmacist Change Pages (PSO*7*294) 2008-06-11
2008-06-11
User Manual - Pharmacist Change Pages (PSO*7*303) 2008-12-04
2008-12-04
User Manual - Pharmacist Change Pages (PSO*7*305) 2009-06-03
2009-06-03
User Manual - Pharmacist Change Pages (PSO*7*324) 2010-02-17
2010-02-17
User Manual - Pharmacist Change Pages (PSO*7*326) 2009-11-23
2009-11-23
User Manual - Pharmacist Change Pages (PSO*7*338) 2010-04-05
2010-04-05
User Manual - Pharmacist Change Pages (PSO*7*343) 2011-04-20
2011-04-20
User Manual - Supplemental - Outpatient Pharmacy V.7.0 2010-04-05
2010-04-05
User Manual - Supplemental Change Pages (PSO*7*305) 2009-06-03
2009-06-03
User Manual - Supplemental Change Pages (PSO*7*338) 2010-04-05
2010-04-05
User Manual - Technician - Outpatient Pharmacy V.7.0. 2011-04-20
2011-04-20
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-151
3686
3687
3688
3689
3690
3691
3692
3693
3694






User Manual - Technician Change Pages (PSO*7*225)
User Manual - Technician Change Pages (PSO*7*251)
User Manual - Technician Change Pages (PSO*7*289)
User Manual - Technician Change Pages (PSO*7*303)
User Manual - Technician Change Pages (PSO*7*305)
User Manual - Technician Change Pages (PSO*7*326)
2008-08-25
2011-04-20
2009-07-16
2008-12-04
2009-06-03
2009-11-23
2008-08-25
2011-04-20
2009-07-16
2008-12-04
2009-06-03
2009-11-23
Pharmacy: Outpatient Pharmacy - (Component diagram)
cmp Pharmacy: Outpatient Pharmacy
Outpatient Pharmacy
«interface»
PSO
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
M Audiofax (Telephone
Refill Requests)
Figure: 3.1-87
3.1.66 PPP-Pharmacy: Pharmacy Prescription Practices
DATE: March 2009
SUBJECT: Retiring of PPP Application
The Pharmacy Prescription Practices (PPP) V. 1.0 application has been retired per PSI-07-114 as it does not provide
the most recent and up-to-date data on prescriptions from other sites. PPP*1*43 has retired PPP, and PSO*7*300
updated routines that referenced PPP.
All options within the PPP V. 1.0 application have been marked Out Of Order with the message OPTION RETIRED
BY PATCH PPP*1*43 AS PER PSI-07-114.
Due to the retirement of PPP, all PPP documentation has been removed from the VistA Documentation Library
(VDL).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-152
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
Figure: 3.1-88
3.1.67 PCMM-Primary Care Management Module
The Primary Care Management Module was developed to assist VA facilities in implementing primary care. It will
support both primary care teams and non-primary care teams. PCMM’s functionality is divided into eight areas.
1. Setup & Define Team
2. Assign Staff to Positions in Teams
3. Assign Patient to Team
4. Assign Patient to Practitioner via Team Position and Enroll in a Clinic
5. Reports/Outputs/Mail Messages
6. Tools to Ease Startup Process of Primary Care
7. Other Changes to Scheduling Package
8. Application Program Interface (API) calls
In the outpatient setting, patients are assigned a primary care team and provider who are responsible for delivering
essential health care, coordinating all health care services, and serving as the point of access for specialty care.
Associate Primary Care Providers (APs) provide primary care to patients under the supervision of the Primary Care
Provider (PCP). PCMM supports both primary care and non-primary care teams. The software allows one to create,
set up, and define teams; create and assign positions to the team; assign staff to the positions; assign patients to the
team; and assign patients to providers’ positions.
In PCMM, primary care providers have an assigned “number of patients allowed” which is compared with the
“number of patients actual” to determine if more patients may be assigned to the provider. PCMM functionality assists
in maintaining accurate, active patient listings for primary care teams and panels. By unassigning patients who have
not seen their primary care providers in a specified amount of time, new patients may be assigned. Unassigned
patients are readily reassigned to their previous primary care team and provider if they return for care. When a
patient cannot be assigned to a primary care team or position, the PCMM software asks if the patient should be
placed on the Electronic Wait List. PCMM Wait List reports assist in the management of patients awaiting a primary
care team or provider assignment.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-153
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
The amount of time the APs and PCPs spend providing direct primary care is also entered and measures the
capacity of each institution (and VHA as a whole) to provide outpatient primary care. PCMM also screens staff
assignments to PCP and AP positions to assure the data on providers is correct.
The primary care patient, provider, and team information captured in PCMM is sent to the Austin Information
Technology Center (AITC) and the National Patient Care Database. Some PCMM information is available in the
Kathy L. Frisbee (KLF) Reports. Additionally, the Office of Performance and Quality Measures utilizes PCMM data for
national reporting and performance measures.
Features
• Uses a graphical user interface (GUI) for creating teams and provider positions as well as assigning staff to the
provider positions.
• Ability to assign/unassign patients to primary care and non-primary care teams and providers both in GUI and
VistA roll-and-scroll.
• Automates patient unassignment from primary care teams and providers if the patient has not seen their primary
care provider for a specified time or when a patient’s date of death is entered.
• Screens assignments to PCP and AP positions based on provider type and person class.
• Produces patient-oriented, practitioner-oriented, and team-oriented reports.
• Transmits data for primary care teams, providers, and patients to Austin in Health Level Seven (HL7) message
format and provides the ability to receive/process transmission errors.
• Ability to control transmission of MailMan messages to team positions.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-154
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
Figure: 3.1-89
3.1.68 Prosthetics
Purchasing - Stock Issues (SI)
Prosthetics Sensory Aids Service (PSAS)
National Prosthetics Patient Database (NPPD) Tools
Home Oxygen Module
Electronic Orders/ Suspense (SU)
Prosthetics Inventory Package (PIP)
Delayed Order Report (DOR)
Prosthetics Billing Information
A common Prosthetic purchasing action is the Issue from Stock (IS) option. You can access this option from the
Stock Issues (SI) Menu. The prompts you see when creating an Issue From Stock are recorded on the patient’s 102319 record like other purchasing transactions.
Prosthetics Basics User Manual is for new Prosthetics users of the Prosthetics Sensory Aids Service (PSAS) system
including Purchasing Agents and any other new end user on the system.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-155
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
The National Prosthetics Patient Database (NPPD) Tools Menu, a VISTA based program, is used to routinely view,
analyze, and validate the medical center PSAS (Prosthetic Sensory Aids Service) patient transaction data that is
eventually transmitted to the NPPD. The menu resides in VISTA at the medical center level.
The Administrative Home Oxygen Module is exclusively an administrative system. It provides for the recording of
patient information for reporting and invoice billing which can be used as a check against bills received from the
contractor for each patient. The module facilitates the coordination of services when contractors change at the end of
a contract cycle. It also provides correspondence support to remind patients when they need to renew their Home
Oxygen prescriptions.
The Administrative Home Oxygen module is mainly used to manage billing from the vendor, providing several
benefits, including saving money by suspending erroneous charges and time by eliminating a manual review of the
records. The module also provides information about the current prescription of the patient, and flags patients with
special problems quickly.
Correspondence may be required by local VAMC Home Oxygen program policy. With this release, letters may be
sent to patients when prescriptions are due to expire or when service is discontinued.
The purpose of the Electronic Order feature is to provide a method for any request for service or request for items in
Prosthetics to be ordered electronically. Requests are made either manually through the Prosthetics system or sent
electronically from CPRS (Computerized Patient Record System) via Consult Tracking.
Through the Suspense (SU) option, Prosthetic employees are able to post notes to consults, cancel and complete
the consult. Reports are available to display open, pending, and completed consults.
The Prosthetics inventory software (also known as the Prosthetics Inventory Package or “PIP”) tracks quantities of
prosthetic items located in the Prosthetics Sensory and AIDS Service (PSAS) inventory of each facility.
The PIP system using bar coding provides the means to do the following:
• Manages the inventory data using barcode scanner equipment
• Provides for faster data entry with scanning information of labels
• More accurate data entry with scanning of HCPCS Codes
• Sends a mail message when stock is low
• Automatically calculates stock quantities when stock is ordered or issued.
•
•
•
•
•
•
•
•
•
The Delayed Order Report (DOR) User Manual corresponds to Patch RMPR*3*59. This patch provides
Prosthetics GUI (graphical user interface) windows for the Delayed Order Report (DOR) feature.
Note: Using this feature requires basic MS Windows skills.
The Prosthetics users will be able to do the following with this patch:
Search for and display manual suspense entries/electronic consult (CPRS order) data by one or all sites.
Display data using one or multiple statuses (Open, Pending, Cancelled or Closed).
Use a starting date for Closed and Cancelled records to display data.
Sort and rearrange the view; display data in a custom view.
Print the display.
Convert the display into a Microsoft Excel file (for more sorting capabilities).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-156
3826
3827
3828
Prosthetics Billing Information (Patch RMPR*3*96) provides Prosthetics GUI (graphical user interface) windows for
the View Prosthetics Billing Information feature.
3829
3830
3831
Prosthetics - (Component diagram)
Figure: 3.1-90
cmp Prosthetics
Prosthetics
«interface»
Prosthetics
NPPD
3832
3833
3834
3835
3836
3837
3838
3839
Figure: 3.1-91
3.1.69 QUASAR-Quality: Audiology And Speech Analysis And Reporting
Quality: Audiology and Speech Analysis and Reporting (QUASAR) is a VISTA software package written for the
Audiology and Speech Pathology Service. QUASAR is used to enter, edit, and retrieve data for each episode of care.
– QUASAR provides transmission of visit data to the Patient Care Encounter (PCE) program in order to
incorporate QUASAR Visit Data in ACRP Workload Reporting, as well as to the Decision Support System (DSS).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-157
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
–
–
–
QUASAR produces a variety of reports useful to local managers, medical center management, and central
planners.
QUASAR contains a VA FileMan function that permits users to generate customized reports using data from
QUASAR's A&SP Clinic Visit file (#509850.6) or A&SP Patient file (#509850.2).
QUASAR produces an automated Cost Distribution RCS 10-0141 Report (CDR) and has an option for
generating and processing audiology compensation and pension examinations through an agreement with the
Automated Medical Information Exchange (AMIE) package.
Figure: 3.1-92
3.1.70 Radiology/ Nuclear Medicine
The VistA Radiology / Nuclear Medicine package is a comprehensive software package, designed to assist with the
functions related to processing patients for imaging examinations. The Radiology / Nuclear Medicine package
automates the entire range of diagnostic functions performed in imaging departments, including request entries by
clinical staff, registration of patients for exams, processing of exams, recording of reports/results, verification of
reports on-line, displaying/printing results for clinical staff, automatic tracking of requests/exams/reports, and
generation of management statistics/reports, both recurring and ad hoc. The Radiology / Nuclear Medicine package
automates many tedious tasks previously performed manually, providing faster, more efficient and accurate data
entry and more timely results reporting.
The package is interfaced with VistA Record Tracking software for the purpose of tracking radiology and nuclear
medicine records and creating pull lists for those records needed for scheduled clinic appointments. The VistA
Radiology / Nuclear Medicine package is fully integrated with VA FileMan and provides certain patient demographic
information supplied by the Patient Information Management System (PIMS), formerly the Medical Administration
Service (MAS) package. It also interacts with other VistA packages to allow personnel to see patient medication
histories, contrast media reactions, and laboratory test results which may influence the nature of an examination.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-158
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
Request entry has been incorporated in two ways: functionality within this package and an interface with the CPRS
package, allowing on-line requesting of exams and viewing of reports. Information regarding each examination is
stored by the system and may be compiled to produce a variety of reports necessary in carrying out daily business
and for use by management in analyzing the workload. Information required to generate a variety of workload reports
and resource allocation reports is also collected.
The VistA Radiology / Nuclear Medicine package supports the HL7 protocol. This allows the exchange of information
concerning exam registration, cancellation, completion, and results (specifically reports and impressions) between
the VistA system and clients within or outside of VistA.
Figure: 3.1-93
Radiology/ Nuclear Medicine
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-159
cmp Radiology/ Nuclear Medicine
Radiology/Nuclear Medicine
«interface»
Radiology/Nuclear Medicine
PowerScribe for Radiology
IBM MedSpeak
TalkStation
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
Figure: 3.1-94
3.1.71 RAI/MDS-Resident Assessment Instrument/ Minimum Data Set
The RAI/MDS implementation is a national project for the VA. One of the many purposes of this project is to provide
computerized storage, access, and analysis of the MDS 2.0 long-term care data on patients in nursing homes across
Veterans Affairs medical centers (VAMCs). The MDS system is intended to create a standard, nationwide system for
connecting VAMCs with nursing home facilities to the Austin Automation Center (AAC) for the purpose of electronic
interchange of data, reports, and other information. The MDS transmission system provides the following functions:
 Receipt of MDS records from the AAC by VAMCs.
 Authentication and validation of MDS records received from VAMC facilities.
 Feedback to VAMCs indicating acknowledgment of the transmission of the data and specifying the status of
record validation.
 Storage of MDS records in the database repository at the AAC.
 Will replace PAI and provide RUG III codes to the ARC (Allocation Resource Center).
At each VAMC, the user will use the RAI/MDS program to electronically send MDS data records to the AAC over the
VA intranet. Once minimal file checks are completed, a message is sent back to the VAMC indicating whether the file
(referred to as batch submission) has been received successfully or rejected.
The user remains on-line to ensure the submission has been accepted. If the submission passes the initial validation
check, then each record is checked for errors or exceptions to the data specifications and a Final Validation Report is
generated.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-160
3902
3903
3904
3905
3906
Figure: 3.1-95
RAI/MDS-Resident Assessment Instrument/ Minimum Data Set - (Component diagram)
cmp RAI/MDS-Resident Assessment Instru...
RAI/MDS
«interface»
RAI/MDS
VA Intranet
3907
3908
3909
3910
3911
3912
Figure: 3.1-96
3.1.72 ROES-Remote Order Entry System
The Remote Order Entry System (ROES) gives authorized end users at VHA facilities the ability to order products
and services from the VA Denver Distribution Center (DDC).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-161
3913
3914
3915
3916
Figure: 3.1-97
ROES-Remote Order Entry System - (Component diagram)
cmp ROES-Remote Order Entry System
ROES
«interface»
ROES
Browser
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
Figure: 3.1-98
3.1.73 Scheduling
The Scheduling module automates all aspects of the outpatient appointment process, including the ability to check
in/check out patients, clinic set-up and maintenance, enrollment/scheduling/discharge of patients to and from various
clinics, and the generation of managerial reports, statistical reports, patient letters, and workload reporting. It provides
for multiple-appointment booking, which enables the user to schedule, at one time, numerous appointments on a
consecutive day/week basis. This pattern of scheduling supports requirements for clinics such as dialysis treatment
and physical therapy.
The system may display numerous messages when an appointment is scheduled depending on the availability of the
slot requested. These include notification that the appointment is an overbook, the patient already has an
appointment scheduled for that date and time, or the appointment cannot be made due to previous inactivation of the
designated clinic. In addition, certain classification questions are prompted during the check out process (if
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-162
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
applicable) to determine if treatment rendered was connected to special circumstances (such as Agent Orange,
Ionizing Radiation, Persian Gulf, etc.). If an appointment cannot be scheduled because of limitations, the user is
prompted to add the appointment information to a Wait List for future scheduling.
Patient Appointment Information gathers appointment data to be loaded into the National Database in Austin for
statistical reporting. Patient appointments are scanned from September 1, 2002 to the present, and appointment data
meeting specified criteria are transmitted to the Austin Information Technology Center (AITC). Subsequent
transmissions will update the National Database. This additional data supplements the existing Clinic Appointment
Wait Time extracts.
The functions within Scheduling currently fall into four major categories: Appointment Scheduling, Local Reporting
(outputs), National Data Collection, and Module Set-Up and Maintenance.
Features
 Creates fixed or variable length clinic patterns.
 Provides on-line clinic availability and system identification of conditions such as first available appointment.
 Interacts with the Record Tracking module allowing chart request at the time of appointment scheduling.
 Generates cancellation, no-show, and pre-appointment letters.
 Provides on-line transmission of pertinent visit information to the national database at the AITC.
 Patient Appointment Information functionality collects and formats data for Health Level Seven (HL7) batch
transmission. It also utilizes new hardware technologies for transmitting data via the VA’s Intranet.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-163
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
Figure: 3.1-99
3.1.74 Shift Handoff Tool
The Shift Handoff Tool is a utility that assists hospital staff going off shift to create a report for the incoming shift. This
report contains demographic and medical information about each patient being handed off. At a minimum it shows
medications and allergies, but can be customized to show other medical information that is relevant to the patient’s
condition. Also referred to as the Physician Handoff Tool.
There has been a great deal of variability in Physician to Physician communication. This is recorded in the medical
literature.
The design and development of the Physician Handoff Tool seeks to address the variability in Physician to Physician
communication at Patient Handoff.
Data elements such as Demographics, Code Status, Allergies, Medications, Problem List, Admitting Diagnosis,
Laboratory and Consults orders are some of the data elements communicated in a standardized way by this tool.
By providing a tool to do this, it is hoped that errors in care will be prevented because the information will be
communicated in a clear, readable, standardized format.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-164
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
A handoff report can be printed and carried with the physician during rounds. Notes can be written on the paper copy
and re-entered into the Shift Handoff Tool for the providers on the next shift.
Figure: 3.1-100
3.1.75 Social Work
Version 3.0 of the Social Work Information Management System is a case management system designed to facilitate
the SOcial Work Service functions within the VA Medical Centers. This package contains DHCP computer programs
which are used to track case loads and generate reports without unnecessary paper work. It can be used to
anticipate a patient's domestic or social needs before being discharged, potentially minimizing the patient's hospital
stay. AMIS data to Austin can now be transmitted electronically via VA MailMan system.
The Social Work software package is comprised of four modules. the modules and their functions are:
1. Case Management System. This is the primary menu for the case management. This is a sub-menu under the
Social Work Information Management System (SWIMS) menu. The Case Management System menu contains some
options that non-Social Work Chiefs/ Supervisors will not be able to access, such as High Risk, Automatic Reporting
System, RCH Registry, and Social Work Personnel Information.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-165
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
2. Clinical Assessment Module. This is the menu for the clinical summary information. It contains data base
assessment profiles of patients, the ability to enter/ delete surrogate supervisors, and discharge planning and closing
note information.
3. Community Resource Module. This menu allows you to enter/ edit and print community resource social work
agency information.
4. Maintenance System. Most options under this menu are used for entering and maintaining various data elements
for social work system definitions (i.e., site parameters). Other options are used to purge or re-initialize certain data
elements, activate/ deactivate cost distribution centers, and enter/ edit new and old social workers and residential
care homes.
Figure: 3.1-101
Social Work - (Component diagram)
cmp Social Work
Social Work
«interface»
Social Work
VA Intranet
4009
4010
4011
Figure: 3.1-102
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-166
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
3.1.76 Spinal Cord Dysfunction
The Spinal Cord Dysfunction (SCD) package, a component of VistA, is a software product that permits the
identification and tracking of patients with a spinal cord dysfunction due to trauma or disease and the medical
resources utilized during their treatment. The programs and files support the of a local and national registry for
patients with a spinal cord dysfunction. The package also provides clinical, administrative, and ad hoc reports for
medical center use.
The SCD package accesses several other VistA files, which contain information concerning diagnosis, prescriptions,
lab tests, radiology exams, hospital admissions, and clinic, visits. This allows your clinical staff to take advantage of
the wealth of clinical data supported through VistA.
The SCD package accomplishes the following:
Uploads patient data to the National SCD Registry. The National Registry is used to provide VA-wide review of
patient demographics, clinical aspects of disease, and resource utilization involved in providing care to patients.
Provides a variety of management reports for local use, including aggregate statistical reports by care type, patients
lost to follow-up, frequency of visits, and volume of lab tests and prescriptions per patient.
The ad hoc reporting capability provides the users with the ability to design their own custom reports.
Several functional measures/scales are provided with the package (CHART, FAM, DIENER, DUSOI) in addition to
the FIM and the Self Report of Function. For multiple sclerosis patients, two measures/scales are available (the
KURTZKE and the EDSS). Each of these scales/measures allows patient progress to be tracked over time.
Functional Description
 Allows efficient entry of data into the local registry and outcome modules.
 Provides a watch list of those patients currently not being seen at the medical center.
 Tracks the utilization of resources used during treatment.
 Extracts data on outpatient visits, inpatient activity, drugs, radiology, and lab tests specified by the SCD Expert
Panel (EP) and the SCD Advisory Board.
 Transports local data to the National SCD database at Austin, Texas.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-167
4045
4046
4047
4048
Figure: 3.1-103
Spinal Cord Dysfunction - (Component diagram)
cmp Spinal Cord Dysfunction
Spinal Cord Dysfunction
«interface»
Spinal Cord
Dysfunction
National Registry
HL7
4049
4050
4051
4052
4053
4054
Figure: 3.1-104
3.1.77 STS-Standards & Terminology Services
Standards & Terminology Services (STS) is responsible for organizing, formalizing, and maintaining the terminology
of the Veterans Health Administration (VHA). Currently, terminology is used in the Department of Veterans Affairs
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-168
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
(VA) Electronic Medical Record (EMR) system known as Veterans Health Information System and Technology
Architecture (VistA). There are many implementations of VistA throughout the world. Each implementation has its
own set of reference files that support clinical care of veterans. This reference information is non-uniform and can
create a lot of confusion when comparing a patient’s medical record from one site to another. STS is making these
files uniform throughout the enterprise, and is facilitating semantic and computational interoperability.
The processes of standardizing the terminology lead to the creation of the VHA Terminology (VHAT). VHAT
encompasses reference information for many clinical domains including Vital Signs, Allergy, Text Integration
Utility (TIU) document titles, Immunizations, and Medication Routes of administration. STS maintains VHAT
through ongoing evaluation of feedback from domain experts. STS also sends regular updates to each VistA
system.
Standards & Terminology Services (STS) is the authoritative source for clinical and administrative data standards for
the Veterans Health Administration.
Standards & Terminology Services (STS) VA Enterprise Terminology Service Version 10 User Interface (UI) includes
workflows that have systematic instructions for authoring and deploying terminology content. The manual is for users
of the VA Enterprise Terminology Services (VETS) who perform the following tasks:
– Author Content
– Review and update functions performed by Domain Reviewers
– Deployment functions performed by Testing Coordinators and other authorized Deployers
VETS is a suite of products that deliver standardized terminology content for use across the VA enterprise; including
VistA and Clinical Data Repository/ Health Data Repository (CHDR).
– The database used to house the terminology content served by VETS is the VA Terminology Server (VTS).
– VETS includes three types of terminology content, all are viewable in the Terminology Browser:
– VHA Terminology (VHAT): a standardized terminology created and maintained for VA applications.
It contains concepts that are unique to the VA as well as concepts that have been derived from
authoritative sources such as Systematized Nomenclature of Medicine, Clinical Terms (SNOMED
CT) or International Classification of Diseases, Clinical Modification (ICD-9-CM).
– Standard Code Systems (SCS): data retrieved from Standard Development Organizations that are
authoritative sources.
– Map Sets: links between terminologies to support VA business needs. Map Sets may be created
internally, adopted from a standard, or from another entity.
• Terminology Deployment Services (TDS) is the tool used by STS to manage and deploy VETS content.
• Terminology Editor (TED) is the tool used to add and edit Map Sets and Map Entries.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-169
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
Figure: 3.1-105
3.1.78 Data Standardization
Standard reference terminology is critical to the Department of Veterans Affairs’ (VA) plan to share computable and
interoperable health information across VA and with non-VA partners. Standardized terminology will enable all sites
in the VA health system to speak the same language, and will ensure that data not only crosses from system to
system, but retains the same meaning. The data will also be computable within the Department of Defense (DoD),
should the patient seek treatment at one of their facilities. When data is computable and interoperable, it is not only
viewable from other sites, but functions seamlessly in automated processes such as drug-drug and drug-allergy order
checks and other clinical decision support.
Efforts are underway to include other health care partners, including participation in the National Health Information
Network. Access to complete and accurate health information for a veteran at any site supports patient safety, and
enables informed clinical decision-making, personalized patient care, and improved population health.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-170
class Data Standardization
Name:
Package:
Version:
Author:
Data Standardization
Data Standardization
Dec 2011
OSEHRA
PDM v1.0
Pharm Data Mgmt
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
Data Standardization
Rad/Nuc Med
v5.0
Radiology/ Nuclear Medicine
Clinical
Reminders v2.0
Clinical Reminders
Figure:
3.1-106
3.1.79 Terminology Services
The foundation of STS’s terminology services is the Terminology Model. The model conceptually defines each
standard term in a clear and unique way by describing the properties, attributes, designations, and relationships for
each standard concept. Modeling the terminology in this way and maintaining the model over time adds clarity and
richness to the standards, and is a distinct advantage over merely providing lists of approved terms.
Standards & Terminology Services is also responsible for the deployment of standard terms across the enterprise.
The deployment service establishes and maintains consistent standard reference files across all VistA databases.
The standardization process remains responsive to the needs of end users and patients through the New Term
Rapid Turnaround (NTRT) process, which allows new terms to be requested from the field. After clinical terminology
requests are approved by domain-specific teams of subject matter experts, new terms are deployed to all VistA
databases. Similarly, the NTRT process is used to inactivate terms which are not longer part of the standard. This
prevents end users from continuing to select inactivated terms, while maintaining the historical accuracy of the
patient record.
Administrative data is standardized via deployment of standard reference tables. This includes data sets such as
demographics, zip codes, area codes, religions, and eligibility status. Standards & Terminology Services also utilizes
standards from external Standards Development Organizations (SDOs), such as Systematized Nomenclature of
Medicine – Clinical Terminology (SNOMED CT®), International Classification of Diseases – 9th edition – Clinical
Modification (ICD-9-CM), Current Procedural Terminology (CPT), and other code sets. These are kept up-to-date by
the Lexicon described in more detail below. STS also provides terminology mediation for cross agency
interoperability efforts, such as the Clinical/Health Data Repository (CHDR) and Laboratory Data Sharing Initiative
(LDSI) projects with DoD.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-171
class Terminology Serv ices
Name:
Package:
Version:
Author:
Terminology Services
Terminology Services
Dec 2011
OSEHRA
ICD-9-CM
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
Terminology Serv ices
CPT
Figure: 3.1-107
3.1.80 Surgery
The Surgery package is designed to be used by Surgeons, Surgical Residents, Anesthetists, Operating Room
Nurses and other surgical staff. The Surgery package is part of the patient information system that stores data on the
Department of Veterans Affairs (VA) patients who have, or are about to undergo, surgical procedures. This package
integrates booking, clinical, and patient data to provide a variety of administrative and clinical reports.
Features:
Surgery package:
• Allows a surgeon to generate requests for surgical procedures.
• Allows operating room scheduling managers to assign operating rooms and time slots and generates operating
room schedules.
• Allows for the rescheduling or cancellation of operative procedures.
• Facilitates entry of information specific to an individual surgical case (e.g., staff, times, diagnoses, complications,
anesthesia).
• Provides for on-line entry of data inside the operating room during the actual operative procedure.
• Generates patient records and nurse reports.
• Produces management reports (e.g., Annual Report of Surgical Procedures, Attending Surgeons Report, Nurse
Staffing Report, and Anesthesia Management).
• Produces quarterly and annual reports for VA Central Office.
• Provides secured access to lists of cancellations and the Morbidity and Mortality Report.
• Extracts data necessary to monitor risk management issues.
• Provides additional checks for Transfusion Error Risk Management.
• Includes a generic Health Level Seven (HL7) interface for use with commercial Automated Anesthesia
Information Systems.
• Includes an interface to the Patient Care Encounters (PCE) software that allows ambulatory procedure workload
information to be transmitted to the National Patient Care Database (NPCD) at Austin.
• Allows for on-line electronic signature of the Nurse Intraoperative Report and the Anesthesia Report.
Surgery: Risk Assessment
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-172
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
The Risk Assessment module of the Surgery software provides medical facilities a mechanism to track information
relating to both surgical risk and operative mortality. This information, once downloaded to the VA national database,
supports a program of total quality improvement in Surgery in VHA.
The National Surgical Quality Improvement Program (NSQIP) was established to develop distributions of observedto-expected (O/E) mortality and morbidity ratios (risk-adjusted outcomes) across facilities for all operations, for eight
major sub-specialties, and for cardiac surgery. At each of VA’s medical facilities performing surgery, a Surgical
Clinical Nurse Reviewer, under the direction of the Chief of Surgery, collects risk and outcome data. All patients
undergoing major surgery requiring general, spinal, or epidural anesthesia are assessed. Completed non-cardiac
assessments are electronically transmitted to the Hines, IL Center for Cooperative Studies in Health Services
(CCSHS), while cardiac assessments are transmitted to the Denver Cardiac Coordinating Center for data analysis.
At these centers, models are continually developed and enhanced for the major surgical subspecialties and
procedure-specific cardiac surgeries. Managerial reports are prepared at the coordinating centers to provide Chiefs
of Surgery with their own risk-adjusted data compared to the VA national averages.
Features:
Risk Assessment module:
• Provides for entry of non-cardiac assessment information including pre-operative information, laboratory test
results, operation information, and intraoperative and post-operative occurrences.
• Provides for entry of cardiac assessment information, including clinical information, cardiac catheterization and
angiographic data, operative risk summary data, cardiac procedures requiring cardio-pulmonary bypass, and
intraoperative and post-operative occurrences.
• Creates a Surgery Risk Assessment report on each patient assessed.
• Transmits completed Surgery Risk Assessments to Hines CCSHS and Denver Cardiac Coordinating Center.
• Lists Surgery Risk Assessments by categories, including complete, incomplete, and transmitted assessments,
as well as lists of major surgical cases and all surgical cases.
• Generates a monthly Surgical Case Workload Report.
• Prints follow-up letters to patients 30 days after a procedure.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-173
4194
4195
4196
Figure: 3.1-108
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-174
4197
Surgery - (Component diagram)
cmp Surgery
Surgery
«interface»
SR
4198
4199
4200
4201
4202
4203
4204
4205
4206
Automated Anesthesia System
via HL7
Figure: 3.1-109
3.1.81 TBI-Traumatic Brain Injury
There are no documents for this application at this point. (As of: 30 October 2009)
Figure: 3.1-110
3.1.82 Virtual Patient Record
There are no documents for this application at this point. (As of: 30 October 2009)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-175
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
Figure: 3.1-111
3.1.83 VistA Imaging System
The VistA Imaging System is an extension to the VistA hospital information system that captures clinical images,
scanned documents, motion images, and other non-textual data files and makes them part of the patient's electronic
medical record. Electrocardiogram (EKG) waveforms can be displayed as part of the electronic medical record.
Image and text data are provided in an integrated manner that facilitates the clinician's task of correlating the data
and making patient care decisions in a timely, accurate way.
The system is designed to provide the treating physician with a complete view of patient data and, at the same time,
allow consulting physicians to have access to the image and text data. It serves as a tool to aid communication and
consultation among physicians -- whether in the same department, in different medical services, or at different sites.
The VistA Imaging System is unique in that management of the medical images is handled by the hospital
information system, allowing very close integration of multimedia data with traditional patient chart information.
Clinical users can capture images during procedures or images can be added at a later time, for example during the
creation of a report or progress note. Automatic image acquisition can be performed by DICOM gateways. Images
can be acquired from commercial radiology Picture Archiving and Communications Systems (PACS) or directly from
radiology devices. The transfer of patient demographic and order information to the commercial PACS or radiology
device plays a key role in the ability to add these images to the patient’s online medical record.
VistA Imaging workstations located throughout the hospital capture and display a wide variety of medical images
including:
• Cardiology
• Endoscopy (GI, pulmonary, cystoscopy, arthroscopy, bronchoscopy, etc)
• Ultrasound (vascular, echo cardiology)
• Microscopic (Surgical Pathology, Cytology, Autopsy, Hematology)
• Surgery
• Ophthalmology
• Dental
• Dermatology
• Radiology images
• Nursing
• Podiatry
• Scanned advanced directives, consent forms, and other documents
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-176
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
VistA Imaging VistARad diagnostic workstations are generally located in the Radiology Reading room and are used
for softcopy reading of Radiology images. These workstations provide functions for the Radiologist to retrieve and
display full-resolution images, associated Radiology reports, and update the Radiology exam status.
VistA Imaging is made up of the following components:
• Core Infrastructure
• Document and Ancillary Imaging
• Film less Radiology
• Telemedicine
Features:
• Provides capture, display, manipulation, and management functions for a wide variety of medical images such
as radiographs, sonograms, EKG tracings, gastroenterology studies, pulmonary bronchoscope exams, podiatry,
dermatology, and ophthalmology images. VistA Imaging can store and display any sort of multimedia data,
including digital images, motion video clips, graphics, scanned documents, and audio files.
• Is integrated with CPRS, allowing users to view images automatically for a selected patient. When a user views
a radiology report or progress note in CPRS, the associated images are easily available.
• Provides a standard interface between VistA and commercial PACS systems.
• Automatically acquires complete studies from DICOM-compliant modalities (CT, MRI, digital x-ray, ultrasound,
etc), associates the studies with the correct patient and report, and stores the studies in VistA Imaging for
inclusion in the electronic patient record.
• Provides image file storage, management, and retrieval from magnetic and optical disk servers and supports
data capture, storage, and retrieval over a local or wide area network (WAN).
• Provides access to electronic medical records from remote VA medical facilities over the VA intranet.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-177
4269
4270
4271
4272
Figure: 3.1-112
VistA Imaging System - (Component diagram)
cmp VistA Imaging System
Vista Imaging
Medical Imaging Resource Center
(MIRC)
VistaRad
Medical Visualization/3D
Reconstruction Software
Voice Dictation Software
4273
4274
4275
Figure: 3.1-113
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-178
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
3.1.84 VistAWeb
VistAWeb is an intranet web application used to review remote patient information found in VistA, BHIE (DoD), the
Health Data Repository (HDR) databases, and the Nationwide Health Information Network (NHIN).
To a large extent, VistAWeb mirrors the reports behavior of the Computerized Patient Record System (CPRS) and
Remote Data View (RDV). However, by permitting a more robust and timely retrieval of remote-site patient data,
VistAWeb is also an enhancement to CPRS/RDV.
There are three ways to access VistAWeb. VistAWeb can be made available by adding it to the CPRS Tools Menu,
and it can be selected as the default method of retrieving data from the Remote Data Available button in CPRS.
These two methods are referred to as CPRS-spawned versions of VistAWeb. They are compliant with the Health
Level 7 (HL7) Clinical Context Object Workgroup (CCOW) standards and therefore maintain context with the patient
selected in CPRS. As a third option, VistAWeb can be accessed in a standalone mode by entering the uniform
resource locator (URL) link (https://vistaweb.med.va.gov/) in the Internet Explorer address bar.
Note: Some links found in this user manual go to sites or pages found on the VA intranet. These sites or pages are
not accessible from outside the VA network.
The standalone version of VistAWeb is connected to neither CPRS nor the clinical context management application.
Standalone VistAWeb serves an important function for users who have been granted special access to multiple sites,
such as for National Programs, Veterans Administration (VA) researchers, and others. VistAWeb was also made
available more broadly, though temporarily, to assist clinical staff with the retrieval of patient information from the
sites affected by damage caused by hurricane Katrina.
To fully appreciate the data that VistAWeb presents to the user, it is important to know something about the HDR as
one of the sources of that data.
Figure: 3.1-114
VistAWeb - (Component diagram)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-179
4305
4306
cmp VistAWeb
VistaWeb
Bi-directional Health Information Exchange (BHIE)
National Health Information Network (NHIN)
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
Figure: 3.1-115
3.1.85 VIST-Visual Impairment Service Team
With this program VIS Teams are able to easily manage and track activities and services provided to blinded
veterans in their service area. This program integrates several fields of patient data to produce a variety of reports.
The VIST patient record printout can be used in place of VA Form (10-1371) and is a more versatile document than
the card. Semi- annual AMIS reports can be run and veterans can be added or deleted from the rolls quickly.
Features:
• Enhances the efficiency of the Visual Impairment Service Team programs.
• Provides a way to easily track and manage activities and services provided to blinded veterans.
• Provides a wide variety of reports based on patient data. Blinded veterans can be quickly added or deleted from
the rolls.
The new Blind Rehabilitation V.5.0 (see Figure 3.1-10) will integrate all four segments of Blind Rehabilitation Service,
which includes:
• VA Headquarters and Visual Impairment Service Teams (VIST);
• Blind Rehabilitation Outpatient Specialists (BROS); and,
• Blind Rehabilitation Centers (BRC).
3.1.86 Vitals/ Measurements
The Vitals/ Measurements application is designed to store in the patient's electronic medical record all vital signs and
various measurements associated with a patient's hospital stay or outpatient clinic visit. Data entered can be
accessed by several VistA (Veterans Health Information Systems and Technology Architecture) applications (e.g.,
CPRS, Health Summary) that interface with the Vitals/ Measurements application.
The Vitals application is composed of two modules: Vitals and Vitals Manager. Each module is accessed separately
through GUI executable icons on the user’s desktop. The Vitals module is used to enter patient data, and is assigned
to clinical staff. The Vitals Manager module is used to manage the Vitals templates and abnormal values ranges, and
is assigned to the Clinical Application Coordinator, package coordinator, and Information Resource Management
Service (IRMS) staff.
A Dynamic Link Library (DLL) file is also provided to allow other applications to use the Vitals/Measurements GUI.
See Appendix C for more information on the DLL.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-180
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
GMV MANAGER is the only security key in this application. This key controls access to the Vitals Manager module.
This key also allows a user to view/create/edit all other user’s templates in the Vitals Manager module; without this
key the user can only view, create, or edit their own user templates. This key should be assigned to the package
coordinator.
Functionality
• Provides a GUI (Graphical User Interface) to make collecting and viewing of data easier. Additional information
on GUI software is contained at the end of this chapter.
• Supports documentation of a patient's vital signs (e.g., temperature, pulse, and respiration), and tracks a
patient's height, weight, central venous pressure (CVP), circumference/girth and oxygen saturation via oximetry
with supplemental oxygen information. Also supports documentation of detailed or positional blood pressures for
a patient (for example, bilateral blood pressures taken in a sitting position).
• Displays latest information on all of the patient's vitals/measurements in both metric equivalents and U.S.
customary units (when appropriate) along with the date/time the information was obtained, and the name of the
user who entered the information.
• Allows facilities to establish hospital-wide high and low values for most vital signs and measurements. Identifies
abnormal values, those values outside the high and low range, on vitals/measurements reports.
• Allows users to record a reason for the omission of a patient's vitals/measurements (such as Patient on Pass).
• Associates qualifiers (alpha characters appended to the measurement's numeric value) to provide a more
detailed description of the patient's vitals/ measurements.
• Contains online help windows to assist users. Online help is accessed through the Help menu at the top of the
screen, or by pressing the F1 key on the keyboard.
• Displays graphic reports on workstation monitors, and provides a variety of printable reports. Reports can be
printed for an individual patient or for multiple patients.
• Provides APIs that pass patient vitals/measurements information within a specific date range to the other VistA
applications.
• Provides compliance with the Clinical Context Object Workgroup (CCOW) standard. The CCOW standard
provides a way for applications to know which other applications are currently running, and which patients are
selected in those applications.
• Supports an interface to vital signs monitor connected to the workstation.
Features:
 Contains a Graphical User Interface (GUI) to make editing and viewing of data easier.
 Supports documentation of a patient's vital signs (e.g., temperature, pulse, and respiration).
 Tracks a patient's height, weight, central venous pressure (CVP), circumference/girth, and oxygen saturation via
oximetry with supplemental oxygen information.
 Supports documentation of detailed or positional blood pressures for a patient (i.e., bilateral blood pressures
taken in a sitting, standing, and lying position).
 Associates qualifiers (alpha characters appended to the measurement's numeric value) to provide a more
detailed description of the patient's vitals/measurements.
 Prints patient's cumulative measurements on the Vital Signs Record and the Cumulative Vitals Report.
 Displays latest information on all of the patient's vitals/measurements in both metric equivalents and U.S.
customary units along with the date/time the information was obtained.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-181
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401








Prints expanded vitals graphic report, which includes the patient's intake and output when present in the patient's
database (refer to the Intake and Output application).
Allows facilities to establish hospital-wide high and low values for each vital sign or measurement.
Identifies abnormal patient values on vitals/measurements reports (those values outside the high and low range).
Prints the following patient measurements in a linear graphic format when using a Kyocera F-800A or HP
compatible (programmable) printer:
o Temperature and pulse.
o Blood pressure.
o Weight.
o Pulse oximetry and respiration.
o Pain.
If reports are printed on a dot matrix printer, plotted data values are not connected by a line.
Supports the archiving and purging of patient measurements, which are no longer required on the production
account, through FileMan.
Passes patient vitals/measurements information (numeric values only) within a specific date range to the Health
Summary application.
Records a reason for the omission of a patient's vitals/measurements.
4402
4403
4404
Figure: 3.1-117
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-182
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
3.1.87 Womens Health
The Women’s Health (WH) software provides tracking functionality for procedures of particular interest to women
patients (e.g., screening mammogram). The software provides a full range of breast and gynecologic cancer
screening and tracking functions. The intended users of the software are primarily WH coordinators and case
managers. Providers may use selected patient management and report options.
This software is based on the Indian Health Service (IHS) Resource and Patient Management System (RPMS)
Women’s Health software V. 2.0, and modified from suggestions provided by the VISTA Women’s Health Technical
Advisory Group (TAG).
Main Features
The Women’s Health software is composed of three main modules: Patient Management, Management Reports, and
Manager’s Functions.
Patient Management is the portion of the software used to manage individual patient care, that is, their procedures,
due dates and correspondence. Under the Patient Management menu it is possible to maintain patient data such as
the date of the next PAP smear, colposcopy or mammogram, the patient's pregnancy and her EDC (due date), as
well as the patient's current PAP regimen. It is also possible to track the patient's individual procedures: the date
performed, the provider and clinic, the results or diagnosis, etc. Notifications (letters and phone calls) may also be
tracked. A file of form letters has been included in the software, and these letters may be edited and personalized for
a clinic's particular needs. Reminder letters can be queued months in advance of a future appointment, then printed
and mailed out shortly before the tentative appointment.
Management Reports is the portion of the software used to print epidemiological reports such as the number of
women who received a mammogram for the selected time period, or the number of patients having abnormal PAP
results during a selected time period. Under the Management Reports menu it is possible to produce lists of patients
who are past their due dates for follow-up procedures. It is also possible to store program statistics by date for later
comparison of program trends and progress.
Manager’s Functions is that portion of the software that provides the ADPAC with a set of utilities for configuring the
software to the specific needs of the site. It also provides utilities for other program needs, such as customizing
tables, making special edits to patient data (e.g., pregnancy log, PAP regimen log), printing notification letters,
running error reports, and documenting laboratory results. By using the File Maintenance options under the
Manager’s Functions menu, it is possible to maintain site specific parameters such as the text of form letters, the
types of notifications and their synonyms, how and when letters get printed, and several defaults relating to dates.
Patients, Procedures, and Notifications
There are primarily three distinct data sets within the WH application and they can be categorized as patient,
procedure, and notification related.
Patients refer to the women in the program register. Data stored for each patient includes demographic data, the
patient's case manager, the current or next cervical and breast treatment need and its due date, the patient's PAP
regimen along with the date it began, and other data. This type of data is referred to as the patient's case data.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-183
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
Procedures refer to any of the diagnostic and therapeutic tests, exams, or other interventions tracked by the
software. The table of procedure types includes PAP smear, colposcopy, mammogram, LEEP, cone biopsy, ECC,
and others. The results or diagnosis associated with the gynecologic procedures are chosen from a table of
Bethesda-consistent terminology. Mammogram results use the American College of Radiology (ACR) terminology.
Notifications refer to any type of communication or correspondence with the patient, such as first, second and third
letters, certified letters, phone calls, messages left, etc. Notifications, which take the form of letters, fall into two
categories: results letters and reminder letters. Result letters inform the patient of the findings of a recent procedure
and are queued to print immediately. Reminder letters inform the patient of the need to schedule her next
appointment and are queued to print at some time several weeks or months in the future.
Selected reports that look at the due dates of patients' treatment needs (using both the procedure and notification
data sets) provide a comprehensive mechanism for guarding against losing patients to follow-up.
The Basic Patient Management Loop
The function of the Women’s Health software is best understood in terms of the Basic Patient Management Loop.
The loop is a sequence of events that occur over and over again during a patient's health care cycle.
This software uses the concept of procedures and notifications being open and closed. Procedures and notifications
will become delinquent if they are not closed by the ‘Complete by (Date)’ field found in the notification and procedure
screens. If a procedure or notification is not closed by its due date, this will be an indicator that the patient may be
‘lost’ to follow-up. Generally, a procedure is closed when the results or diagnosis for that procedure are entered. A
notification is closed either at the time it is printed (as in the case of a results letter) or when the patient returns for
her next appointment (as in the case of a reminder letter).
Summary
In summary, Women’s Health is largely a patient management tool for tracking the breast and gynecologic treatment
needs of women, the procedures they receive, and the communications between healthcare staff and women
regarding their treatment and follow-up. The software also provides some program-wide epidemiological reports
which are of use to clinicians and program administrators.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-184
4479
4480
4481
4482
Figure: 3.1-118
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-185
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
3.2 Financial-Administrative
Financial and Administrative Systems manage portfolios for the core legacy systems, aids in the
planning, development, and implementation of enterprise-wide projects, and provides billing and patient
records management solutions to our internal customers and end users, which results in a positive
experience for our most prized customer, the Veteran.
The MFS portfolio focuses on:
 Patient Financial Services Systems
 Fee Basis Claims Processing
 Decision Support Systems
 Core Financial Logistics Systems
 Health Revenue Center
 HIPAA
 Future Integration with Commercial Applications
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-186
class Financial-Administrativ e Install-Dependencies and DBIA-Associations
Name:
Package:
Version:
Author:
Financial-Administrative Install-Dependencies and DBIA-Associations
Financial-Administrative
Dec 2011
DBIA-Routine
DBIA# 120-A
OSEHRA
Record
Tracking
ADT/Registration
ADT/Registration V.5.3
V1.5, DBIA 1093-A,...
DSS
GCS V.2.0
Library
GCS
CPT
DBIA - File & Routine
CPT V.5.0
DRG
DBIA# 4052
GCS V.2.0
GCS
V.2.0,
DBIA#
3466-A,AR
3466-B
Fee Basis
IFCAP V.5.0
IFCAP
V.5.0,
DBIA#
285-B-H,
IFCAP
V.4.0,
DBIA43,...
IFCAP
PFOP
IB
V.2.0,
DBIA#s
228,
396,...
DBIA# 3989
ECS V.2.0
Ev ent
Capture
DBIA - File Equipment/
Turn-In Request
EAS
DBIA
IFCAP
V.4.0,
DBIA# 353
DBIA - Routine
AEMS/MERS
IB 2486
DBIA#
DBIA# 3342
Wounded Inj ured
and Ill Warriors
HINQ
HINQ V.4.0
PAID
PIMS/MAS
AMIE
v2.7
CAPRI
OS
IB V.2.0
AMIE
PAID V.4
ASISTS
DBIA#IB
4547
V.2.0
IB
V.2.0,
DBIA#s
257,
DBIA#943
324
IVM V.2.0
IVM
HEC
PR
ECME
Visit Tracking V.2.0
DBIA#3986, 3987
QMIM
Auto Info
Collection
Sys
4498
4499
4500
4501
ROI
VSS
Visit Tracking
Police and
Security
FFP
IR
Clinical Monitoring
System
ICD-9-CM
VIC/PICS
Figure: 3.2-1
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-187
4502
`Financial-Administrative - (Package diagram)
4503
4504
4505
4506
Figure: 3.2-2
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-188
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
3.2.1 AR-Accounts Receivable
This Accounts Receivable (AR) software has resulted from a separation of Accounts Receivable functions from the
Integrated Funds Distribution, Control Point Activity, Accounting and Procurement (IFCAP) package. It allows Fiscal
Service to manage the debt collection process at a VA facility.
The Accounts Receivable package automates the Fiscal functions related to the management of Accounts
Receivable, and is integrated with the Integrated Billing (IB) package process of preparing patient Bills on the UB-92.
The Accounts Receivable package is also integrated with the National Roll-Up database.
The system must be running the following software to successfully operate AR Version 4.5. Versions running must be
those stated or later:
• KERNEL Version 7.1
• VA FileMan Version 20
• MAS Version 5.3 (PIMS)
• IFCAP Version 5.0
• IB Version 2.0
• Generic Code Sheet 2.0
Currently, the Integrated Billing (IB) package interfaces with AR [package] routines, files and utilities. AR also
interfaces with the IB package.
With this version of AR, it is necessary to be running IFCAP for generation of documents to FMS and site parameter
information.
4529
4530
4531
4532
Figure: 3.2-3
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-189
4533
4534
AR-Accounts Receivable - (Component diagram)
cmp AR-Accounts Receiv able
AR-Accounts Receiv able
4535
4536
4537
4538
«interface»
RCNR*
National Roll-Up
Database
«interface»
PRCANRU
National Roll-Up
Database
Figure: 3.2-4
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-190
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
3.2.2 ASISTS-Automated Safety Incident Surveillance Tracking System
The ASISTS software package stores data on accidents causing injuries and illnesses reported via the Report of
Incident. The employee may choose to apply for compensation using the Federal Employee's Notice of Traumatic
Injury and Claim for Continuation of Pay/Compensation (CA-1) when the incident is an injury and the Notice of
Occupational Disease and Claim for Compensation (CA-2) for an illness.
Statistical reporting is performed on incidents occurring nationwide by extracting pertinent Report of Incident data
from facilities and transmitting it to the ASISTS National Database (NDB). Reports are periodically generated from
the NDB to identify systematic trends and to support prevention programs concerning front line health care worker
exposure to bloodborne pathogens.
The ASISTS package provides the capability to electronically transmit CA-1 and CA-2 data to the Department of
Labor (DOL). Federal Law requires that these forms be submitted within 14 days after the employee submits a claim
for an accident or illness. The data is collected at each facility and is then transmitted to DOL via the Austin
Automation Center (AAC). The transmission of each completed form is under the control of workers’ compensation
personnel at each facility.
ASISTS has three major goals.
•
Better tracking of employee injuries and illnesses ASISTS computerizes the Report of Incident as well as the
OWCP CA-1 and CA-2 forms. These reports help improve the ability to trend and analyze accidental injuries and
illnesses, thus helping to prevent future incidents from occurring.
• Reduce exposures to bloodborne pathogens from needlesticks, sharps, or body fluids ASISTS instantly notifies
Occupational Health and other medical personnel when the employee reports an incident involving a bloodborne
pathogen exposure, so that proper tests and treatment can be initiated. The data concerning exposure to bloodborne
pathogens will be collected in a national database to identify national trends, training needs, and best practices for
the benefit of all employees at every VA medical center.
•
Reduce worker compensation costs ASISTS facilitates a case management approach to preventing future
incidents and provides better management of workers' compensation claims. Through automation, the incident
reporting process will be more accurate and be processed in a more timely fashion.
Features:
•
Electronic signature is used extensively throughout this program. All three forms (VA Form 2162, CA-1, and
CA-2) require appropriate signatures including that of the employee for the CA-1 and CA-2, which is used when
electronically transferring the date to the Department of Labor.
•
Bulletins alert employee health and infection control of any exposures to blood borne pathogens. The
employee's supervisor, the safety officer, Human Resources Management, and union representatives are notified of
every incident. Electronic signatures trigger bulletins from the employee to the supervisor and union representatives
and from the supervisor to the safety officer, alerting the recipient of action that should be taken.
•
Every medical center employee has access to a menu structured specifically to the level of his/her involvement
in the process: employee health, supervisor, safety officer, union representative, workers’ compensation personnel,
and employee.
•
The graphical user interface (GUI) for ASISTS facilitates the input and processing of accident reports and
claims and improves the reporting functionality, including a revised OSHA and Needlestick log and graphical
representation of the incident reports.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-191
4583
4584
4585
•
Future versions will include a comprehensive employee health module for tracking and following numerous
health issues.
4586
4587
4588
Figure: 3.2-5
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-192
4589
4590
ASISTS-Auto Safety Incident Surveillance Tracking System - (Component diagram)
cmp ASISTS-Auto Safety Incident Surv eillance Tracking System
ASISTS-Automated Safety Incident
Surv eillance Tracking System
«interface»
OOPS
Dept of Labor (DOL) via Austin Automation Center (AAC)
ASSISTS National Database
Other Mail Groups
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
Figure: 3.2-6
3.2.3 AICS-Automated Information Collection System
The encounter form is a paper form designed specifically for outpatient visits. It is used both to display relevant
patient data for use during the visit, such as demographics, allergies, and problems; and to collect data about the
visit, such as procedures and tests performed. Its primary focus is clinical and to collect data for the Ambulatory Care
Reporting Project. It also has other purposes such as collecting data necessary for billing.
The AICS package contains all the software necessary to design, edit, and assign encounter forms to clinics; print
forms for appointments with patient data; and print with or without patient data for patients without an appointment.
The software enables collection of outpatient clinical and administrative data; and provides a more organized, less
obtrusive method of data collection to the clinician and supporting clerical staff.
AICS is a hybrid system designed to use commercial software for the scanning and image processing of forms.
Features:
• Provides a form design utility that allows creation of attractive and easy to use forms for each clinic.
• Allows forms to be designed to print with patient data displayed, such as patient demographics, insurance
information, allergies, clinical reminders that are due and active problems.
• Allows for the creation of forms to collect data such as procedures, diagnoses, problems, providers, progress
notes, vital signs, and Patient Care Encounter (PCE)-related data such as exams, health factors, patient
education, skin tests, and immunizations.
• Provides a print manager that allows all clinic-specific forms to print with the encounter form for an appointment.
The print manager also provides a setup system that, once accomplished, no longer requires daily user
intervention.
• Provides an import/export utility that makes it easier for sites to exchange forms they have already created.
• Provides forms tracking to ensure that each form printed is processed or accounted for.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-193
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
•
Manual data entry options are available to allow data to be key entered by a clerk and passed to PCE to be
stored.
Figure: 3.2-7
3.2.4 AMIE-Automated Medical Information Exchange
The Automated Medical Information Exchange (AMIE) module facilitates the electronic interchange of veteran
information between Veteran Benefits Administration (VBA) Regional Offices (ROs) and VA medical facilities. The
comprehensive module provides an accurate audit trail to track most requests for information. The module is
composed of two components: Facility administrative options and VBA Regional Office options. Each area has
individual items to maintain daily, and its own reports to print. RO staff access VA medical facility computers through
VA national telecommunications network, and exercise their options on each local medical facility’s system as
necessary.
Features
•
Provides access to local databases for identification of a veteran’s admission, discharge,
outpatient treatment, patient care, and other information that may require adjudicative actions.
•
Reduces overpayments previously caused by lost, misrouted, or improperly processed admission notifications.
•
Provides on-line status determinations of pending compensation and pension examinations (requesting,
scheduling, tracking, and updating results).
•
Provides RO on-line access to the local databases for the confirmation of the propriety of payments based on
hospitalization.
•
Improves timeliness of the RO benefits adjustment processing.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-194
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
•
Allows medical centers to electronically access sections of the Physicians Guide for Disability Evaluation
Examinations.
•
Provides tracking of insufficiently completed compensation and pension examinations.
Figure: 3.2-8
3.2.5 Clinical Monitoring System
The heart of the Clinical Monitoring System package is in building monitors using conditions and groups for patient
auto enrollment.
The main function of this software is to capture data for patients meeting specified conditions. All monitors within the
framework of this software are ultimately based upon patient related data. In order to capture data, you create
monitors that run nightly. These nightly runs "auto enroll" (or capture) the patients defined by the monitors.
This system looks at what happened yesterday in VistA. It can capture such items as ward, treating specialty, SSN,
age, etc. For a more extensive list of items, use the Data Element File Inquire option within the Outputs Menu of the
Monitoring System Manager Menu. Data elements available for capture vary depending on the conditions you select
when building monitors.
Conditions are provided with the Clinical Monitoring System package. Examples of conditions include ON WARD,
READMISSION, MAS MOVEMENT TYPE, PREVIOUS DISCHARGE, etc. You may use the Condition File Inquire
option to obtain information on selected/all conditions. The information provided will describe the condition; tell you
what questions will be asked when using a condition; tell you when you must define a group for the condition, and list
the other data that is available for capture.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-195
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
Each condition chosen for a monitor brings up a set of questions pertaining to it. For example, if you choose the AGE
condition, you will be asked age ranges. Some conditions require a group be defined such as a group of wards, drug
classes, MAS movement types, etc. Patients captured by the monitors are called "fall outs". With each condition
used, there is a list of other data that can be captured when a patient becomes a “fall out” that might include items
such as ward, admission date, attending, etc.
The monitors can be queued to run nightly, or manually run, one or more at a time. Each monitor has an "ON/OFF"
switch, an "UNDER CONSTRUCTION" or "FINISHED" status, and START and STOP dates so that running it can be
tightly controlled.
Features:
• Provides the user with the ability to design a monitor that will auto enroll cases that meet the user's defined
criteria/conditions from VistA.
• Allows the user to set time frames for computing percentages and tracking findings between time frames.
• Has the ability to alert users when important thresholds or dates are met.
• Provides a mechanism to add site-developed conditions and data elements and routines such as site-designed
worksheets to the software. MUMPS programming is a required part of site-specific enhancement.
• Provides mechanisms for controlling the disk space and CPU time resources used by the Clinical Monitoring
System.
• Allows the user to manually enter cases.
Figure: 3.2-9
3.2.6 CAPRI-Compensation and Pension Records Interchange
Compensation and Pension Record Interchange (CAPRI) is an information technology initiative to improve service to
disabled veterans by promoting efficient communications between the Veterans Health Administration (VHA) and
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-196
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
Veterans Benefits Administration (VBA). Online access to medical data enhances the timeliness of the benefits
determination. The CAPRI software acts as a bridge between the VBA and VHA information systems. It offers VBA
Rating Veteran Service Representatives and Decision Review Officers help in building the rating decision
documentation through online access to medical data. It offers VHA Compensation & Pension (C&P) staff an easy,
standardized way of reporting C&P Examination results.
Using CAPRI, VBA employees will have a standardized, user-friendly method to rapidly access veterans' electronic
medical records throughout the VA. Initially developed specifically for VBA, the utility of CAPRI has been expanded to
other user groups that include VHA, Office of the Medical Inspector, OI, Research, Veteran Service Officers, and
others. One of the primary features of CAPRI is the Compensation and Pension Worksheet Module (CPWM) which is
used by VHA C&P providers and staff. CPWM provides clinical users access to exam templates and tools that are
used to document C&P examinations.
Features
• Demographics
o Load new patients into VistA system.
o View patient demographics.
o Report patient address changes to VHA.
• C&P Examination Functionality
o Add/Edit C&P exam request.
o Create an insufficient exam request.
o Individual and cumulative pending exam tracking.
o Request VAF 7131 information.
o VA Regional Office reports.
o AMIS 290 report.
o Automatic Mailman bulletins to AMIE mail groups.
o All standard AMIE worksheets are available in template form.
o Automatic sending of completed exam requests.
o Ability to save template work in progress and finish later.
o Ability for site to review exams before releasing it to VBA.
o Multiple templates can be merged into a single exam.
• Patient Records Navigation
o View health summaries.
o View appointment lists.
o View progress notes.
o View discharge summaries.
o View consult requests and results.
o View cumulative vitals.
o View active medications.
o View lab reports.
o View imaging.
o View procedures.
o View FHIE/DoD data, if available.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-197
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
Figure: 3.2-10
3.2.7 CPT-Current Procedural Terminology
Current Procedural Terminology (CPT) codes are used for reporting medical services and procedures performed by
clinicians. The purpose of the code is to provide a uniform language that will accurately describe medical, surgical,
and diagnostic services, thereby providing an effective means for reliable nationwide communication among
physicians, patients, and third parties.
This system of terminology is the most widely accepted nomenclature for the reporting of clinical procedures and
services under government and private health insurance programs.
The CPT software includes all CPT codes document outpatient services for reimbursement and workload purposes
as determined by the American Medical Association and the Healthcare Common Procedure Coding System
(HCPCS) from the Centers for Medicare and Medicaid Services (CMS). These codes may also be used to report
inpatient services in certain instances.
Features
• Provides annual updates for CPT and HCPCS codes.
• Provides several reports to display new, revised, or inactivated codes.
• Supplies detailed descriptions of CPT and HCPCS codes.
International Classification of Diseases, Clinical Modification (ICD-9-CM)
The International Classification of Diseases, Clinical Modification (ICD-9-CM) is a clinically-modified statistical
classification system that arranges diseases and injuries into groups according to established criteria. It is based on
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-198
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
the ICD-9, which was designed for the classification of morbidity and mortality information for statistical purposes,
and published by the World Health Organization (WHO). These codes provide an effective means of communication
between physicians, patients, and third parties.
Lexicon service provides the software to update the ICD files. ICD–9-CM consists of the following components:
• A tabular list containing a numerical list of disease code numbers.
• An alphabetical index to the disease entries.
• A classification system for surgical, diagnostic, and therapeutic procedures as defined by WHO.
• Use of ICD-9-CM codes is approved by Centers for Medicare and Medicaid Services (CMS).
Updates to these codes are released in the Federal Register by CMS in May/June of each year. These code updates
include changes to the codes and code narratives. An electronic version of the updates is released by CMS in
September, which must go into effect on October 1st of each year. CMS has a benchmark of 30 days beyond the
effective date of October 1st for implementing these updates.
Figure: 3.2-11
3.2.8 DSS-Decision Support System Extracts
Decision Support System Extracts (DSS) V3.0 provides a means of exporting data from selected Veterans Health
Information Systems and Technology Architecture (VistA) modules to a Decision Support System (DSS) resident in
the VA Austin Information Technology Center (AITC).
This transfer is accomplished through a set of extract routines, intermediate files, audit reports, a transmission
routine, and a purge routine. Data from VistA packages is stored by the extract routines in the intermediate files,
where it is temporarily available for local use and auditing. The data is then transmitted to the AITC, where it is
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-199
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
formatted and uploaded into commercial software. After the data has been successfully uploaded into the commercial
software, it is purged from the intermediate files.
The DSS Extracts V3.0 software includes the following functionalities:
o DSS Extract field additions and modifications
o DSS Menu additions, modifications and deletions
o New DSS reports and report modifications
o Implementation of the new and/or deleted extracts
Figure: 3.2-12
3.2.9 DRG-Diagnostic Related Group Grouper
The DRG Grouper is a "black box" utility with standalone functionality and can be called by other VISTA applications.
The DRG Grouper package contains two options:
• DRG Grouper - Used to compute and display the Diagnosis Related Group (DRG) for a patient based on that
patient's diagnoses and any operations/procedures performed.
• ICD Code Inquiry - Allows the user to display information for a selected diagnosis or operation/ procedure code.
This version of the DRG Grouper is based on the current Medicare Grouper requirements as defined by the Health
Care Financing Administration (HCFA) contained in the annual update from 3M Health Information Systems. The
same DRG Grouper is used by the Austin Automation Center (AAC).
DRG Components
The DRGs are defined as a manageable, clinically coherent set of patient classes that relate a hospital case mix to
the resource demands and associated costs experienced by the hospital. There are 511 DRGs associated with the
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-200
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
DRG Grouper. Each represents a class of patients deemed medically comparable and requiring similar amounts of
resources for care.
The DRGs may be calculated for both registered VA patients and non-VA patients. Except for Transfer DRGs, the
system does not store the DRG compiled for each patient. DRGs are recalculated each time the DRG Grouper option
is utilized. If data entered is insufficient for the DRG Grouper to function, the DRG will not be computed and will be
displayed as "UNGROUPABLE". A message such as "Grouper needs to know if patient died during this episode!" will
appear to inform you what missing data is required.
Classifying DRGs
The actual process of classifying the patients into one of the 511 DRGs is done by the DRG Grouper using the
following information:
• Age
• Sex
• Diagnosis codes
• Operation/procedure codes
• Discharge status
The patient's age and any secondary diagnoses the patient had are used to determine whether the patient's stay had
significant and contributing complications and/or co-morbidities. The DRG Grouper accepts one primary diagnosis
and unlimited secondary diagnoses and operations/ procedures.
Features
• Provides annual updates that conform to the latest release of the commercial grouper.
• Functions within or apart from other modules.
• Supplies detailed descriptions of DRGs, diagnostic codes, and operation/procedure codes.
• Accepts one primary diagnosis and multiple secondary diagnostic codes and operation/procedure codes.
• Displays weighted work unit values as well as national and local high and low trim point values for each DRG
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-201
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
Figure: 3.2-13
3.2.10 ECME-Electronic Claims Management Engine
The Electronic Claims Management Engine (ECME) generates electronic claims in National Council for Prescription
Drug Programs (NCPDP) V. 5.1 format, based on the Outpatient Pharmacy V. 7.0 workflow. ECME:
 Allows pharmacy claims processing staff to submit, resubmit, and reverse electronic claims;
 Provides reports for end users and management on claims status, transaction history, and system configuration
standings;
 Allows Automated Data Processing Application Coordinator (ADPAC) and Information Resources Management
Service (IRMS) staff to configure ECME to pharmacy site specifications.
ECME claims processing begins when events within Outpatient Pharmacy V. 7.0 meet specific criteria, based on
Integrated Billing (IB) V. 2.0 determination, that indicate the system should generate an electronic claim. To build a
claim through ECME, several conditions must be met. First, the patient must be registered and have pharmacy
prescription insurance coverage. Second, the patient must be a non-service connected patient or, if service
connected, the prescription must not be for the service connected condition. The patient must not have an
environmental indicators condition. Finally, the drug must be billable.
Logic embedded within ECME manages the creation of the electronic claim, which requires integration with IB V. 2.0,
Pharmacy Data Management, and National Drug File (NDF) V. 4.0. ECME also generates claims during
Consolidated Mail Outpatient Pharmacy (CMOP) V. 2.0 processing for prescriptions that meet billing requirements
and which are suspended for CMOP fills.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-202
4865
4866
4867
4868
4869
The Veterans Health Administration (VHA) developed ECME software in order to comply with the Health Insurance
Portability and Accountability Act (HIPAA) of 1996 and updated it to comply to the HIPAA rule of 2009, which requires
health care providers to electronically transmit outpatient pharmacy prescription claims to payers in the NCPDP
format and to receive responses on a real-time basis. ECME is derived from the Point of Sale (POS) Application
developed by the Indian Health Service (IHS) and is assigned to the BPS namespace.
4870
4871
4872
4873
Figure: 3.2-14
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-203
4874
4875
ECME-Electronic Claims Management Engine - (Component diagram)
cmp ECME-Electronic Claims Management Engine
ECME-Electronic Claims
Management Engine
«interface»
BPS
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
Austin Information Technology Center
Figure: 3.2-15
3.2.11 AEMS/MERS-Engineering
The Engineering package, otherwise known as Automated Engineering
Management System/ Medical Equipment Reporting System (AEMS/MERS) was released on a national basis in
1985. In September of 1988, Engineering Service and the Office of Acquisition and Materiel Management (A&MM)
jointly decided that the Engineering Equipment file should become a shared resource. This version of Engineering
includes all data elements required for establishing and maintaining Integrated Supply Management System (ISMS)
nonexpendable equipment records.
This version of the Engineering package frequently invokes VA Kernel Version 6.5 or later and VA FileMan Version
18.0 or later for device selection, task queuing, data entry, and data presentation.
Functional Description
The DHCP Engineering package consists of nine (9) separate but interrelated
modules.
1. Work Order and MERS
2. Project Planning
3. Project Tracking
4. Equipment Management
5. Space/Facility Management
6. Program Management
7. 2162 Accident Reporting
8. Assign (Transfer) Electronic Work Orders
9. IT Equipment Tracking
Work Order and MERS
The Work Order and MERS module generates control numbers for Engineering work requests and provides a means
for assigning work requests to specific Engineering shops, assigning personnel to work orders, and charging work
orders to specific pieces of equipment. It is the basis for automated repair histories on all types of equipment.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-204
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
Although preventive maintenance inspections are scheduled and recorded using the Equipment Management
module, the actual PM work orders that constitute a PM worklist are physically stored in the Work Order file. Special
options exist for displaying incomplete work orders and for transferring electronic work orders (work requests typed
into DHCP by end-users and not by Engineering) from a "receiving area" to a working shop.
Project Planning
The Project Planning module provides enter/ edit options for information that appears on the 5-Year Plan for each
project; information required for forms VAF 10-1193; VAF 10-1193a; and NRM, Minor, and Minor Misc. Prioritization
Scoring Sheets.
The Approval of Project Application option controls the Chief Engineer's and VAMC Director's sign off on the project
application. The security key ENPLK001 controls the Chief Engineer's approval. The security key ENPLK002 controls
the VAMC Director's approval. The Chief Engineer must sign off before the VAMC Director. Both must approve
before the project application can be transmitted electronically to higher approval authorities.
The Report/Print Menu options provide print-outs of the reports and forms required by project planning. The
Electronic Transmission Menu contains options for electronic transmission of the 5-Year Plan and Project Application
data elements.
Project Tracking
The Project Tracking module is used to record significant events during construction and non-recurring maintenance
projects when the management of such a project has been delegated to the facility. Selected data elements are
extracted from the Construction Project file and electronically transmitted to the Regional Construction Office and
VACO. In this way, up-to-date project tracking information is made available to all interested parties with a minimum
of data entry.
The content of the most recent electronic project progress report is always available for reference. Printouts of
progress reports will include an asterisk beside data that differs from what was previously reported. If progress
reports are directed to a CRT, changes will be highlighted.
Equipment Management
The Equipment Management module contains the options to maintain inventory and preventive maintenance
information, print bar code labels, download control programs to portable bar code readers, upload data from
portable bar code readers to DHCP, and to manage CMR (Consolidated Memoranda of Receipt).
Equipment records generally exist for non-expendable personal property, building service equipment, and for
equipment that is classified as expendable from the materiel management point of view but which must be
periodically inspected by Engineering. These inspections are necessary to satisfy the requirements of JCAHO (Joint
Commission on the Accreditation of Healthcare Organizations) and/or other regulatory bodies. The Equipment
Management module includes all options necessary for establishing and maintaining a comprehensive preventive
maintenance program. Bar coding is now an integral part of the equipment management strategies.
The reports available through the Equipment Management module include:
• Repair histories,
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-205
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
•
•
•
•
•
•
CMR listings,
Aggregated repair histories (by Equipment Category),
Warranty expiration listings,
Equipment replacement listings,
Equipment with high failure rates,
Preventive maintenance workload (by shop).
The Equipment Management module is tightly coupled to the Work Order module. Equipment histories are
automatically updated as work orders are closed out. Redundant data entry is avoided whenever possible.
Although entries in the equipment repair histories are most commonly made by the system when work orders are
closed out, users can also make entries without going through the Work Order module. Equipment records to be
updated by direct posting may be selected individually or they may be contained in a VA FileMan sort template. If a
sort template is used, it must begin with "ENPOST."
Program Management
The Program Management module contains options for site-specific population and/or maintenance of files used in
the Engineering package. This option is only available to the Engineering Applications Manager or Engineering Site
Manager. It is where the various lists are established and maintained. The Engineering Employee file and the
Equipment Category list must be maintained on a continuing basis. Populated copies of the Equipment Category file
are available from your supporting ISC upon request.
Space/Facility Management
The Space/Facility Management module is used to maintain data on physical locations within the host facility (usually
a VA Medical Center). Data elements include square footage; wall, ceiling and floor finishes; window types and
treatments; and other architectural features. This module also provides control of locks and keys throughout a facility.
Bar coded location labels are printed from the Space file based on room number. Facilities that intend to take
advantage of the bar code features in the Equipment Management module should insure that the Building file is
completely current and that the Space file contains at least a room number (including building and division, if
applicable) for each physical location. The proper format for a room number (which must be unique and
unambiguous) is Room-Building-Division. Most single division facilities will need to enter only Room-Building.
2162 Accident Reporting
The 2162 Accident Reporting module collects the data elements of VA Form 2162 so that accidents and on-the-job
injuries can be aggregated and analyzed by Service/ Section, cause of accident, nature of accident, etc.
Assign (Transfer) Electronic Work Orders The Assign (Transfer) Electronic Work Orders option was developed to
facilitate the process of transferring electronic work orders from the receiving area(s) to a working shop. Users may
also disapprove electronic work orders when necessary. In such a case, the COMMENTS field is automatically
mailed to whoever entered the work order, along with the information that their request has been disapproved.
IT Equipment Tracking
The IT Equipment Module allows IT personnel to view and update the nonexpendable equipment inventory for IT equipment. It allows IT staff to assign
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-206
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
responsibility for IT equipment to individuals and allows individuals to sign
electronic hand receipts for the assigned equipment.
IT equipment is identified based on the CMR (EIL) field. If an equipment item is ona CMR with IT TRACKING equal
to YES, the equipment is considered tracked IT equipment. The CMR File Enter/Edit [ENCMR] option can be used by
Acquisition & Materiel Management (A&MM) to edit the IT TRACKING field.
Only tracked IT equipment can be edited using the Inventory Edit (IT) option. All tracked IT equipment is expected to
be assigned to individual IT owners. The IT Equipment Tracking module is tightly coupled with the Equipment
Management module.
Figure: 3.2-16
3.2.12 EAS-Enrollment Application System
Enrollment Application System (EAS) is currently a single module application. It facilitates the processing of the 1010EZ Application for Health Benefits, which has been transmitted to the VHA site from the On-Line 10-10EZ webbased software.
This 10-10EZ module allows site staff with enrollment and registration responsibilities to review all data entered by a
veteran on the electronic 10-10EZ form before committing the data to the site database. It also provides a basic
tracking mechanism in order to follow the progress of the veteran’s application and respond to specific inquiries.
Features
 Automatically receives incoming 10-10EZ data transmissions from the Web-based application into a VistA
holding file.
 Provides a List Manager interface that allows the enrollment/registration staff to:
Match the Applicant with an existing Patient record when appropriate.
Review all 10-10EZ data and perform corrections as needed.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-207
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
Print the 10-1 0EZ form with data in order to send to the veteran for signature.
Verify that the veteran has signed the 10-10EZ.
 Commits 10-10EZ data to the VistA Patient database in preparation for further enrollment and/or registration
activities.
 Responds to customer (e.g., veteran) inquiries as to the status of a 10-10EZ Application.
 Provides an audit trail of all significant actions performed in processing a 10-10EZ Application as a basis for
management reports.
 Retains a copy of any original Patient database data elements overwritten by incoming 10-10EZ data elements.
Figure: 3.2-17
3.2.13 Equipment/ Turn-In Request
The Equipment Request/ Turn-In Module Version 1.0, will provide support to a variety of administrative activities in
your medical center concerning your non-expendable equipment requests and any equipment turn-ins.
Functionally, the Equipment/Turn-In module has several organizational elements that use different components of
the software.
• Requestor
• Consolidated Memorandum of Receipt (CMR)
• Personal Property Manager (PPM)
• Engineering
• Other Concurring Officials
• Equipment committee
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-208
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
•
Warehouse
Each organizational element has a different function with some overlapping components. Each of these elements
interact and rely upon each other for the smooth flow and completion of equipment requests and turn-ins.
Figure: 3.2-18
3.2.14 Event Capture
The Event Capture GUI software provides a consistent, event driven, windows style, user interface for Event
Capture. The GUI captures all the utilization data that is presently available in Event Capture.
The Event Capture GUI software provides a mechanism to track and account for procedures and delivered services
that are not handled in any other VistA package. The procedures and services tracked through Event Capture are
associated with the following:
• The patient to whom they were delivered
• The provider requesting the service or procedure
• The DSS Unit responsible for delivering the service
DSS Units typically represent the smallest identifiable work unit in a clinical service at a medical center and are
defined by the VAMCs. A DSS Unit can represent any of the following:
• An entire service
• A section of a service
• A small section within a section
• A medical equipment item used in patient procedures
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-209
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
For every DSS Unit, each of the following must be defined:
• Service - The service associated with the DSS Unit.
• Cost Center - Fiscal identifier for the service using the particular DSS Unit (Cost Centers are defined in detail in
the MP4-Part V Appendix B of the Fiscal Service cost manuals.)
• Medical Specialty - The specialty section associated with the DSS Unit.
Functions of the Software
Event Capture with all patches installed provides the following functions:
• Allows each VAMC to utilize the software for its own resource/costing needs
• Implements DSS Units
• Assigns user access
• Allows single and batch data entry for patient procedures
• Generates reports for workload and other statistical tracking
• EC*2*25 is the first ECS GUI patch. It:
o Provides a Graphical User Interface to the ECS application.
o Allows user to upload patient encounter data to Event Capture from a spreadsheet.
o Allows user to switch between CPRS and ECS via the use of a hot button in the tools menu of either
application.
5091
5092
5093
5094
Figure: 3.2-19
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-210
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
3.2.15 Fee Basis
A veteran is authorized Fee Basis care if s/he is legally eligible for such care and VA facilities are not feasibly
available to meet the patient's medical needs. The authorization may be for non-VA hospitalization, community
nursing home care, short term care, ID card status for ongoing outpatient care, or for home health services which
authorize home health visits only. Veterans authorized Fee Basis care may be reimbursed for:
• Travel expenses from their home to the fee provider
• Prescription services in emergent situations
• Non-VA hospitalization and outpatient care
Following are the main features of the Fee Basis package.
• Ability to perform the entire fee for service process from entering patient authorizations and vendors to
transmitting completed batch data to Austin for payment.
• Quick, easy, and accurate access to a patient's payment history.
• Completion of previously repetitive actions.
• Efficient administration of the Hometown Pharmacy program.
• Ability to set up authorizations for Community Nursing Home and Contract Hospital, and process payments for
services provided.
• Processing of payments ancillary to Contract Hospital and unauthorized inpatient claims.
• Establishing a fee schedule and a pricer check for payment of medical claims.
The Fee Basis software product is fully integrated with V. 20.0 of VA FileMan and V. 7.1 of the Kernel. V. 3.5 is also
integrated with the 1358 module of IFCAP. When outpatient batches are released for payment, there will be a posting
to the appropriate 1358. For inpatient batches, the estimated amount from the VA Form 10-7078, as well as the
actual amount, will be posted to the 1358 when batches are released for payment. The Fee Basis package interfaces
with the ADT (Admission-Discharge-Transfer) DHCP module of the PIMS (Patient Information Management System
(formerly MAS)) package to provide users access to registration data entered through ADT options. It also integrates
with the IB (Integrated Billing) package for patient insurance data. Integration with CPT V. 5.0 allows for entry of
modifiers for CPT codes. Integration with the Patient Treatment File (PTF) allows for the creation of Non-VA PTF
Records.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-211
5124
5125
5126
Figure: 3.2-20
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-212
5127
5128
Fee Basis - (Component diagram)
cmp Fee Basis
Fee Basis
«interface»
FB
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
Austin Pricer System
Figure: 3.2-21
3.2.16 FFP-Fugitive Felon Program
The purpose of Patch DG*5.3*485 is to provide the functionality in support of PL 107-103, Section 505.
Public Law (PL) 107-103, Section 505, prohibits provision of certain benefits to veterans or their dependents that are
classified as fugitive felons. This law requires VA to provide current address information, upon written request, to any
Federal, State, or local law enforcement official, if s/he:
• Provides information required to fully identify the person
• Identifies the person as being a fugitive felon
• Certifies that apprehending such person is within the official duties of such official
This project software provides the following functionality for VHA implementation:
• Adds several fields to the VISTA Patient File to store the Fugitive Felon Flag and track when the flag was
entered and removed
• Creates a new security key to control access to the Fugitive Felon Flag and the associated menu options
• Provides menu options that allow users to set and clear the Fugitive Felon Flag, and to print the various reports
associated with the new fields
• Displays user alert from Scheduling and Registration options
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-213
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
Figure: 3.2-22
3.2.17 GCS-Generic Code Sheet
The Generic Code Sheet package is a Decentralized Hospital Computer Program (DHCP) software module which
manages the input, editing, deletion, and transmission of code sheets from a local hospital computer system to a
centralized computer system as defined by the code sheet.
The Generic Code Sheet package contains a code sheet file, GENERIC CODE
SHEET (#2100), to be used to define field definitions to support the code sheets. The field definitions describe the
type of data to be stored in the actual code sheet. The fields can be arranged in an input template in the order they
will be used to create the code sheet.
Once the code sheet data has been created, the code sheets can be marked for batching. Batching the code sheets
will group like code sheets together for transmission. When the code sheets are transmitted, all code sheets within
the batch will be transmitted in the same VA MailMan message. The exception to this is the Financial Management
System (FMS) code sheets. When the FMS code sheets are created they are queued for transmission using the
GENERIC CODE SHEET STACK file (#2100.1), thus bypassing the batching process. The code sheets are
transmitted from the stack file by a background VA TaskManager job which can be run every 2 hours, 3 hours, etc.
as specified by the systems manager.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-214
5169
5170
5171
5172
Figure: 3.2-23
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-215
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
3.2.18 HEC-Health Eligibility Center
Health Eligibility Center (HEC) v. 1.0
Description:
The Health Eligibility Center (HEC) supports VA's health care enrollment system while providing centralized eligibility
verification and determination services. This office supports VA by verifying veterans' eligibility and processing
enrollment applications. The HEC supports, coordinates, and implements VHA's financial assessment process,
consolidating financial eligibility determinations for VA health care.
The HEC also:
• Conducts VHA's income verification process for veterans whose financial assessments exempt them from medical
care co-payments
• Validates Social Security numbers from the Social Security Administration
• Verifies income from the Internal Revenue Service and the Social Security Administration
• Receives information from VBA to determine Veterans’ eligibility and enrollment assignment
• Implements information system enhancements to support CBO vision of application, eligibility and enrollment
processing
• Assists in the maintenance of the Enrollment Database by performing data management functions focused on
improving the integrity of veterans' personal, eligibility, and financial information
• Is the authoritative source and Data Steward for Demographic, Eligibility, and Enrollment data. This does not
include Patient Identity elements.
• Provides Business oversight to all software products related to Registration, Eligibility and Enrollment.
The HEC recently deployed Enrollment System Redesign (ESR) version 3.0, the HealtheVet replacement system for
the current product known as HEC Legacy. This expert system gathers information obtained from VistA, VBA, and
the HEC staff to determine and communicate verified medical benefits eligibility and enrollment (E&E) information for
all veterans and beneficiaries. For every exception where the expert system process cannot make a determination,
“cases” are created for human intervention. HEC staff utilizes ESR to manage these “cases” to completion so that
verified E&E can be determined.
The HEC, located in Atlanta, GA, receives patient-reported Means Test data from the VistA 1.0 Income Verification
Match (IVM) module. HEC compares the extracted data with earned and unearned income data retrieved from Social
Security Administration (SSA) and Internal Revenue Service (IRS). Patients with reported income in the mandatory
category, but whose actual income has been proven to be above that level, will have their eligibility for health care
changed to the discretionary category and are subject to back billing.
The HEC sends the updated demographic and insurance information to the medical facilities for upload. The IVM
module allows the HEC data to be compared with locally collected data and selectively uploaded. Local revenue staff
may then send healthcare claims to insurance companies for treatment rendered to patients who had not previously
reported health insurance coverage. Updated and verified income information from the HEC is automatically
uploaded upon receipt at each VA facility, which updates the veteran’s eligibility for health care and creates copayment charges for previous episodes of care.
Programming Language:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
J2EE
Spring Framework
Struts Framework
Hibernate Framework
JRules
Deployment Infrastructure:
WebLogic Server
Depends On:
VistA 1.0
FileMan
Income Verification Match (IVM)
MailMan
VistA 1.5
Person Service Identity Management (PSIM)
VA Enrollment System (VES)
External Entities
Social Security Administration (SSA)
Internal Revenue Service (IRS)
The following entities depend on Health Eligibility Center (HEC):
VistA 1.0
Research pending
External Entities
Social Security Administration (SSA)
Internal Revenue Service (IRS)
VistA 1.5
Person Services Identity Management (PSIM)
Master Patient Index (MPI)
Centralized Data Repositories
Administrative Data Repository (ADR)
For more information, reference:
VA Software Document Library (VDL): http://www.va.gov/vdl/application.asp?appid=143
Office of Enterprise Development (OED) Project Repository:
HEC Redesign – Version 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=504
HEC Redesign – Version 2 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=602
HEC Redesign – Version 3 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=737
HEC VistA Enhancements (HVE) Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=843
HEC HL7 Upgrade Phase 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=359
Enrollment System Redesign (ESR) – Version 3.0 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=884
Enrollment System Redesign (ESR) – Version 3.1 Project Notebook:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-217
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1174
Enrollment System Redesign (ESR) – Version 3.2 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1275
Enrollment System Redesign (ESR) – Version 3.3 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1286
Enrollment System Redesign (ESR)-V4.0 IVM Workflow Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1030
Enrollment VistA Changes (EVC) Early Release Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1009
Enrollment VistA Changes (EVC) Release 1 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=951
Enrollment VistA Changes (EVC) Release 2 Project Notebook:
http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=982
Enrollment Priority 8 Enhancements Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1292
VistA Enrollment Database Standards and Procedures:
http://tspr.vista.med.va.gov/warboard/ProjectDocs/HEC_Redesign_V1/HEC%20Redesign%20Database%20Stds%2
0&%20Procs.doc#_Toc517162753
Enrollment System Redesign Project Overview:
http://tspr.vista.med.va.gov/warboard/ProjectDocs%5CEnrollment_System_Redesign_Ver_3.0%5CESR%20Overvie
w%208-23-2005.pdf
Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
Health Eligibility Center (HEC) Homepage: http://vaww.va.gov/hec/
Figure: 3.2-24
HEC-Health Eligibility Center - (Component diagram)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-218
cmp HEC-Health Eligibility Center
«interface»
HL7
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
HL7 Error Messages to
VAMCs
Figure: 3.2-25
3.2.19 HINQ-Hospital Inquiry
The Hospital Inquiry (HINQ) module provides the capability to request and obtain veteran eligibility data via the VA
National Telecommunications Network. Individual or group requests are sent from a local computer to a remote
Veterans Benefits Administration (VBA) computer where veteran information is stored. The VBA network that
supports HINQ is composed of four computer systems located in regional VA payment centers.
HINQ interfaces with other modules to allow users to make eligibility requests. An on-line suspense file stores
requests for later transmission and records HINQ responses, thus creating a log of HINQ activity.
The HINQ module provides facilities with the ability to obtain veteran eligibility information quickly, accurately, and
efficiently, allowing medical center personnel to act expeditiously on patient requests for medical treatment and other
benefits. Additionally, returned HINQ data may be loaded directly into the local Patient file through various screens.
The screens display both the data in the HINQ message and what is currently in the Patient file for comparison.
Features
• Sends on-line requests individually and forwards multiple requests in a batch mode.
• Tracks and updates various requests from customer.
• Establishes ‘real-time’ links between VHA and VBA computers to service time-of-the-essence requests.
• Processes routine requests in background, allowing the requester to perform other tasks.
• Alerts the requester when responses are received from VBA computers.
• Alerts the requester when there is a discrepancy found between the returned HINQ information and what is in
the Patient file.
• Provides the capability to update returned HINQ data directly into the Patient file.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-219
5314
5315
5316
5317
Figure: 3.2-26
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-220
5318
5319
HINQ-Hospital Inquiry - (Component diagram)
cmp HINQ-Hospital Inquiry
HINQ-Hospital Inquiry
«interface»
DVB
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
Veterans Benefits Administation (VBA) via
Austin Automation Center (AAC)
Figure: 3.2-27
3.2.20 ICD-9-CM
The International Classification of Diseases, Clinical Modification (ICD-9-CM) is a clinically-modified statistical
classification system that arranges diseases and injuries into groups according to established criteria. It is based on
the ICD-9, which was designed for the classification of morbidity and mortality information for statistical purposes,
and published by the World Health Organization (WHO). These codes provide an effective means of communication
between physicians, patients, and third parties.
Lexicon service provides the software to update the ICD files. ICD–9-CM consists of the following components:
 A tabular list containing a numerical list of disease code numbers.
 An alphabetical index to the disease entries.
 A classification system for surgical, diagnostic, and therapeutic procedures as defined by WHO.
 Use of ICD-9-CM codes is approved by Centers for Medicare and Medicaid Services (CMS).
Updates to these codes are released in the Federal Register by CMS in May/June of each year. These code updates
include changes to the codes and code narratives. An electronic version of the updates is released by CMS in
September, which must go into effect on October 1st of each year. CMS has a benchmark of 30 days beyond the
effective date of October 1st for implementing these updates.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-221
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
Figure: 3.2-28
3.2.21 IFCAP-Integrated Funds Distribution, Control Point Activity, Accounting, and Procurement
Integrated Funds Distribution, Control Point Activity, Accounting and Procurement (IFCAP) module automates a
spectrum of VA financial activities. VA employees use IFCAP to manage budgets, order goods and services,
maintain records of available funds, determine the status of a request, compare vendors and items to determine the
best purchase, record the receipt of items into the warehouse, and pay vendors. IFCAP automates the written
regulations and policy for VA funding and procurement, which define the actions taken on requests for goods and
services as formal transactions, orders, and payments.
Features
 Allows users in different services to view the same document on-screen.
 Automates funds distribution, request for goods and services, purchase order, funds obligation, and the
receipt process.
 Standardizes funds management. Automatically generates yearly budget elements for IFCAP control points.
 Maintains year-to-date balance for control points. Integrates service-level requisitions and facility
administrative activities, and updates service-level records.
 Shares vendor and item master data to eliminate duplicate input and promote user accuracy.
 Affixes processing status to each request at each step in the ordering cycle. Enhances security with the use
of a unique electronic signature code for each user required to authorize an action.
 Sets an encoded value based on key fields from each record signed.
 Transmits financial and inventory data to VA central accounting and inventory systems.
 Updates IFCAP records automatically with central accounting system data.
 Provides various reports that give the current status of any request, a service fund balance, data required
for budget analysis, and a listing of requests sorted according to control point specifications.
 Enables electronic transmission of purchase orders to vendors through Electronic Data Interchange (EDI).
 Updates purchase order status automatically.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-222
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392








Enables authorized users to purchase goods using Electronic Data Interchange (EDI) process for total
electronic processing between vendor and buyer.
Supports the ordering of goods under contract from specific vendors via delivery orders.
Supports the payment for goods/services via the government purchase card and the subsequent on-line
reconciliation.
Transmits Federal Procurement Data System (FPDS) data to the Austin Information Technology Center
(AITC) to support enterprise level tracking of procurement history.
Supports monthly management analysis activities by transmitting inventory and purchase order activity data
to the Clinical Logistics Report Server at AITC.
Supports, via a graphical tool, the reviewing of purchase order activity and other logistical data within
IFCAP; and the export of that data to MS Excel spreadsheets for further analysis.
Supports both the identification of items by their National Item File number (NIF #) and the standardized
naming of Items through an interface between IFCAP and the National Item File.
Transmits inventory and purchase order activity data to the Clinical Logistics Report Server on a monthly
basis for management analysis.
· Inventory management features:
 Defines desired stock levels of items.
 Automatically generates (autogen) replenishment orders.
 Dispenses goods to supported services or end users.
 Identifies items via bar code technology.
 Supports communication of inventory information between a secondary inventory point and its associated
automated supply cabinet(s).
 Produces reports displaying inventory level, distributions, and dollar values.
 Supports the identification and tracking of on-demand items at the primary and the secondary level.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-223
5393
5394
5395
Figure: 3.2-29
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-224
5396
5397
IFCAP - (Component diagram)
cmp IFCAP
IFCAP-Integrated Funds Distribution, Control Point
Activ ity, Accounting, and Procurement
«interface»
PRC
Austin (LOG,GSA,DLA)
DynaMed
Finacial Management System (FMS)
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
Figure: 3.2-30
3.2.22 Incident Reporting
The Incident Reporting module supports VHA policy by compiling data on patient incidents. It organizes the data into
defined categories for reporting and tracking at medical facility level and for transmission to the National Quality
Assurance Database for Headquarters review and tracking.
Features
• Provides options to simplify the setup of the software.
• Allows for the entry of all required incident information plus descriptive data and actions taken on all reportable
and/or locally defined incidents.
• Prints out a Pseudo 10-2633 Incident Worksheet.
• Provides an ad-hoc reporting mechanism that uses VA FileMan modifiers for sorting or printing the following data
fields:
Patient
Type of Death
Patient ID
Level of Review
Date of Admission
Date of Incident
Patient Type
Incident Case Status
Ward/Clinic
Severity Level
Treating Specialty
Fall Assessment Score
Service
Person Reporting the Incident
Responsible Service
Patient Diagnosis
Medication Errors
Medical Center Action
Case Number
Incident Description
Incident
Pertinent Information
Incident Location
National Case Status
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-225
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
Figure: 3.2-31
3.2.23 IVM-Income Verification Match
The Income Verification Match (IVM) module is designed to extract patient-reported Means Test data and transmit it
to the Health Eligibility Center (HEC) located in Atlanta, Georgia. IVM allows Veterans Health Administration (VHA) to
accurately assess a patient’s eligibility for health care when the eligibility criterion is income-based.
IVM electronically transfers patient income and demographic data for eligible veterans whose VA health care is
based on income and for whom a Means Test has been completed. It also sends automatic updates if pertinent
patient data is edited at the medical center.
As part of this process, HEC compares the extracted data with earned and unearned income data retrieved from
Social Security Administration (SSA) and Internal Revenue Service (IRS). Patients with reported income in the
mandatory category, but whose actual income has been proven to be above that level, may have their eligibility for
health care changed to the discretionary category and are subject to back billing.
The HEC sends the updated demographic information to the medical facilities for upload. The IVM module allows the
HEC data to be compared with locally collected data and selectively uploaded. As a result of the income verification
process performed by the HEC, an updated means test is transmitted to the VA facility, which updates the veteran’s
eligibility for health care and creates co-payment charges for previous episodes of care. The software provides
inquiries and reports that track all IVM activity.
Features
 Transmits data for basic demographics, next-of-kin, income, temporary address, eligibility, guardian, military
service, and employer information to the HEC for patients who are entered into the VAMC database.
Automatically transmits an updated message if this information is changed.
 Allows the HEC to query the medical facility for the most up-to-date patient information.
 Allows updated demographic and insurance information from the HEC to be uploaded into the patient’s record.
 Automatically loads updated income information from the HEC (including IVM Converted financial tests) and
updates the veteran’s eligibility for health care.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-226
5456
5457

Allows generation of status inquiries, statistical Means Test, and data transmission reports.
5458
5459
5460
5461
Figure: 3.2-32
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-227
5462
5463
IVM-Income Verification Match - (Component diagram)
cmp IVM-Income Verification Match
IVM-Income
Verification Match
«interface»
IVM
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
Health Eligibility Center
Figure: 3.2-33
3.2.24 IB-Integrated Billing
Following is an overview of the major functions of the Integrated Billing software, excluding the Encounter Form
functionality. That information can be found in the IB User Manual, Encounter Form Utilities Module.
The release of Integrated Billing (IB) version 2.0 introduces fundamental changes to the way MCCR-related tasks are
done. This software introduces three new modules: Claims Tracking, Encounter Form Utilities, and Insurance Data
Capture.
There are also significant enhancements to the two previous modules, Patient Billing and Third Party Billing. IB has
moved from a package with the singular purpose of identifying billable episodes of care and creating bills, to a
package responsible for the whole billing process through to the passing of charges to Accounts Receivable (AR).
Functionality has been added to assist in capturing patient data, tracking potentially billable episodes of care,
completing utilization review (UR) tasks, and capturing more complete insurance information.
This version of IB has been targeted for a much wider audience than previous versions.
 The Encounter Form Utilities module is used by MAS ADPACs or clinic supervisors to create and print clinicspecific forms. Physicians use the forms and consequently provide input into their creation.
 The Claims Tracking module is used by UR nurses within MCCR and Quality Management (QM) to track
episodes of care, do pre-certifications, do continued stay reviews, and complete other UR tasks.
 Insurance verifiers use the Insurance Data Capture module to collect and store patient and insurance carrierspecific data.
 The billing clerks see substantial changes to their jobs with the enhancements provided in the Patient Billing and
Third Party Billing modules.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-228
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
Patient Billing
 automates billing of pharmacy, inpatient, nursing home care unit (NHCU), and outpatient copayments; inpatient
and NHCU per diem charges; and passing charges to Accounts Receivable (AR).
 automatically exempts patients who are eligible for VA Pension, Aid and Attendance, or House Bound benefits
from the Medication Copayment requirement.
 provides for manual assignment of hardship exemptions from the copayment requirement and the ability to track
those exemptions.
 integrates with the checkout functionality released in the PIMS V. 5.3 package. Patients who claim exposure to
Agent Orange and environmental contaminants, and who are treated for conditions not related to this exposure,
are billed automatically.
 allows patient charges to be added, edited, or deleted if there is no automated charge or the automated charge
is incorrect.
 creates subsistence charges for CHAMPVA patients and passes to Accounts Receivable. This functionality will
not be activated until the AR package releases a patch that allows AR to process CHAMPVA receivables.
 allows Means Test billing data to be transmitted between facilities in conjunction with PDX V. 1.5.
 automatically creates Means Test charges when a verified Means Test is electronically received from the Income
Verification Match (IVM) Center.
Third Party Billing
 automates the creation of third party billing forms (UB-82, UB-92, HCFA-1500), allowing for the entry, editing,
authorizing, printing, and canceling of bills.
 provides the ability to add prescription refills and prosthetic items to bills.
 expands the UB-92 functionality to include ability to add/edit all unlabeled form locators (except 49), additional
diagnosis, some occurrence spans, and value codes.
 provides a check-off sheet (can be replaced by the Encounter Form depending on local needs) that can be
printed in a variety of site configurable formats to be used in clinics to identify CPT codes.
 allows the transfer of CPT codes between the billing screens and the SCHEDULING VISITS file.
 provides reports to identify billable episodes of care, patient and insurance inquiries, and statistical data.
 provides the ability to create CHAMPVA bills. You will not be able to pass them to Accounts Receivable until the
AR package releases a patch that allows AR to process CHAMPVA receivables.
 provides an employer report, which lists uninsured patients who are employed.
 allows printing of all authorized bills in user-specified order.
 provides an Automated Biller which will automatically generate reimbursable insurance bills for inpatient stays,
outpatient visits, and prescription refills. Through the use of site parameters, sites can specify what types of
events are billed using the Automated Biller.
 provides an expanded HCFA-1500 claim form to include inpatient bills, user-specified charges, and multiple
pages.
 provides an addendum sheet to HCFA-1500 claim form to list the bill's prescription refills and prosthetic items.
Insurance Data Capture
 stores multiple addresses (main mailing, outpatient claims, inpatient claims, prescription claims, appeals,
inquiries) for each insurance carrier.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-229
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573







provides insurance company-specific billing parameters so bills can reflect local insurance company
requirements.
provides the ability to establish group plans which will be pointed to by each patient with a policy attached to the
plan. This saves re-entry of the same policy data for each patient.
stores annual benefits associated with group plans.
provides tools to maintain and/or clean up the INSURANCE COMPANY file.
allows patient insurance information to be updated and verified.
stores benefits used by a patient, such as deductibles and lifetime maximums.
provides an insurance worksheet for use by the insurance verifier.
Claims Tracking
 provides the ability to track billing information concerning inpatient visits, outpatient visits, prescription refills,
prosthetics, and fee basis visits from time of event until payment.
 provides a pending review (to do ) list.
 introduces an Admission Sheet which can be placed in the front of the inpatient chart and used to document
concurrent reviews.
 provides the feeding mechanism for automated bill preparation of third party bills.
 provides tracking of those cases requiring utilization review by VA Central Office (VACO) Quality Management
(QM) office based on Interqual criteria.
 provides tracking of those cases where the insurance company requires reviews.
 provides tracking of appeals and denials.
 provides U/R management reports.
Additional Functionality
 purges data from selected IB files.
 provides the medical centers flexibility in implementing the package functionality through site parameters.
 provides the ability to enter new billing rates and VA pension income thresholds.
 produces management reports to provide workload, productivity, statistical, and historical data.
Related materials include the IB User Manual, Encounter Form Utilities Module; IB Technical Manual; Package
Security Guide; Installation Guide; and Release Notes. The Technical Manual assists the site manager in
maintenance of the software. The Package Security Guide provides information concerning security requirements for
the package. The Installation Guide provides assistance in installation of the package while the Release Notes
describe modifications and enhancements to the software that are new to this version.
Features
 Tracks events requiring insurance company reviews from the time of the actual event until final payment is
resolved.
 Provides the ability to setup insurance companies and insurance plans and to store all relevant data associated
with each of the group or individual plans.
 Provides the ability to enter and maintain each patient’s insurance data.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-230
5574
5575
5576

Automates the creation of bills for patient charges for prescriptions, inpatient and outpatient co-payments, and
long term care co-payments. For medication co-payments, it tracks charges billed to a veteran at all sites to
ensure that the annual maximum billing cap is not
5577
5578
Figure: 3.2-34
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-231
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
3.2.25 Integrated Patient Funds
The PFOP system is a computerized program that manages the private finances of Veterans Administration patients.
The material to be stored in this system is the same information you’ve probably recorded on VA Form 10-1083, the
Patient Account Card. Once installed, the PFOP system will accept information that you enter into your computer
terminal, eliminating the need to record information on the form.
This package includes options used to enroll patients in the system; options used to process system transactions;
and options used to print reports about system transactions. The PFOP system accepts information about only those
patients who are REGISTERED WITH YOUR HOSPITAL. Only after Medical Administration Services REGISTERS a
patient -- in other words, ADMITS a patient to your hospital and ENTERS the patient into the Patient file -- will you be
able to enroll the individual in the PFOP System.
The Personal Funds of Patients (PFOP) System automates a number of patient funds tasks - from enrolling new
patient accounts, for example, to processing account transactions and printing reports about account transactions.
What the system does, essentially, is electronically manage the private finances of VA hospital patients.
The objective of PRPF*3.0*15 (Diagnostic Patch 15) is to allow sites to diagnose and resolve as many issues as
possible before they migrate from VistA legacy Personal Funds of Patients (PFOP) to the Veterans Personal Funds
System (VPFS). Install and use Diagnostic Patch 15 well in advance of your actual data migration date to allow time
to run the diagnostic routine, review the reports, and make corrections in the M environment repeatedly to narrow
down the count of errors. Although it is desirable, you do not need to cleanse your data 100%. It is important,
however, to correct any data that violates the rules imposed by the FileMan data dictionary’s input transform for a
field. Such data errors could cause the migration process to fail. For example, if the input transform says a field must
be between 3 and 30 characters, but the actual data is 40 characters, this error should be corrected.
Functional Description
The PFOP system electronically manages money held for patients hospitalized at VA facilities. The system’s
foundation is the Patient Funds account. Essentially, the Patient Funds account operates much like a checking
account; however, the money in a Patient Funds account does not accrue interest and, in some cases, restrictions
limit the amount of cash patients may withdraw in a given time period. While using the PFOP system, you’ll perform
tasks that closely resemble the banking activities required to maintain checking accounts. Along with your
supervisory duties, you’ll be called upon to perform the three basic PFOP system functions that follow.
Establish Patient Funds Account
A Patient Funds account can be opened for any individual listed in both the Patient file (# 2) and the Patient Funds
file (# 470). Your facility’s Patient file stores the patient name, social security number, pertinent addresses used by
the PFOP system, and any additional medical information about a patient. Your facility’s Patient Funds file stores
data associated with the PFOP system (e.g., account balance, restrictions, etc.).
Post Transactions
You may electronically post deposits to Patient Funds accounts and post withdrawals from Patient Funds accounts.
You will also have on-line access to the current balances of all Patient Funds accounts and to all of the transactions
involving those accounts.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-232
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
Reconcile Accounts and Reports
Several reports are provided that can be used to help reconcile accounts with Fiscal Service. When generating these
reports, you’ll be able to select any one of several formats designed to meet the needs of a variety of users.
Features
 Shares patient account data to eliminate duplicate input and promote accuracy.
 Records deposits and withdrawals.
 Promotes security with the use of unique electronic signature codes.
 Allows withdrawal restrictions for designated patients.
 Allows users (e.g., patient funds clerk and agent cashier) to view the same information on-line.
 Allows reconciliation of patient funds records with Fiscal Service.
 Provides varied reports with the current status of patient accounts, summary transaction information, restriction
lists, and suspense files.
Figure: 3.2-35
3.2.26 Library
The purpose of the Library package at the local VA Medical Center is to facilitate the automation of manual serial title
check-in and distribution, the integration of scattered data into a single title record, and the extension of on-line staff
access to holdings and services.
The purpose of the Library package on FORUM is to maintain centralized data integrity and to allow for the request of
Interlibrary Loan items.
Library V. 2.5 provides support to a variety of administrative activities in a VA Medical Center concerning serials. As
the name implies, the Librarians will be the greatest users of this software and will reap the greatest benefits.
Patients can also benefit from the Library package through Interlibrary Loan.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-233
5653
5654
5655
5656
5657
5658
5659
5660
5661
5662
5663
5664
5665
5666
5667
5668
5669
5670
5671
5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
Functionally, the Library module has three organizational elements that reside as different components of the
software. The three functional components are:
• Interlibrary Loan on FORUM
• Serials Authority Files on FORUM
• Serials Processing at local medical center libraries
Library Package on FORUM
The FORUM module of the Library package serves several major needs.
1) Maintain basic serial information
2) Allow interlibrary loan of materials
3) Maintain listings of networked audiovisuals
The first feature of the programs on FORUM allow the National Librarians to input and maintain consistent
information on serials. Serial titles are entered specifying pertinent information about the serial such as title,
frequency of issue, etc. Once the serial has been entered into the Library module on FORUM, the local medical
center libraries have the capability of obtaining that information by requesting information about serial titles to be
transmitted to their local files for utilization.
The second feature on FORUM is the ability to request interlibrary loan of materials from one local medical center to
another. Holdings for each library station are maintained on FORUM for this purpose and for updating the National
Library of Medicine's SERHOLD data for their interlibrary loan module, DOCLINE.
Library Package at Local VAMCs
The Library package module at local VA medical centers serves several major needs; checking in serials,
maintaining local holding records, and renewal of serials material. Please review the Library package User Manual
for more information about this module of the Library package.
The Serials Module provides automation of the data needed to manage these collections, exact bibliographic
identification of the item; data on costs, vendors, numbers of copies; the ability to assign routings to titles and
generate the routing slips automatically; a two-key check-in process to speed up the daily workload; and numerous
reports for claims, holdings lists, and statistics.
Journal and magazine titles tend to change name and frequency very often. A major problem with V. 1.2 was the
inability to keep current the database forming the bibliographic record of the serials titles at the local site. For sharing
purposes, it is also important that all libraries use the same form of a serials title.
The significant effort in V. 2.5 has been to devise a method to keep the bibliographic database at the local site always
up-to-date. This has been accomplished by linking a similar, constantly edited file on FORUM to the local site
modules via network mail. When a change is made in a title record at the FORUM level, it can be downloaded to the
local level, where it will overwrite the old bibliographic record without altering any of the specific local data such as
holdings or check-in information. Downloaded records will also carry predication patterns as they are added or
modified. Prediction patterns significantly speed up the daily check-in process.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-234
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
These major changes in functionality are concentrated in Section E - LTS - Library Title Setup. Other changes in
functionality are found in the following sections.
 Section P - HSF - Hospital Service file where the ability to edit this file has been removed.
 Section S - CHE - Check-In with information about the predicting ability and the effect of the initialization process
on titles.
Features of Serials Control module:
 Creates a local serials database.
 Provides acquisition and retention information.
 Provides purchasing and vendor information.
 Provides holdings information and shelving location information.
 Categorizes by type and subject.
 Provides check-in with next issue prediction.
 Generates routing slips.
 Tracks materials returned from routing.
 Displays check-in history.
 Generates 20 management reports (e.g., listings, monthly check-in statistics, monthly routing statistics, tracking
of unreturned routed issues, missing issue reports for claiming replacements or reports, etc.).
 A centrally produced Title Authority file, a database of over 9,477 serials titles owned by VALNET (VA Library
Network) libraries, was preloaded with standard bibliographic data and provided as a part of this module.
Figure: 3.2-36
3.2.27 Occurrence Screen
The Occurrence Screen package is a fully integrated system which is compatible with V. 7.0 of Kernel and V. 19 of
VA FileMan.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-235
5723
5724
5725
5726
5727
5728
5729
5730
5731
5732
5733
5734
5735
5736
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
The objectives of the package are to increase efficiency in the documenting of occurrences, permit better trend
analysis, and provide a consistent format for stored data to be used for QM review at the regional and national levels.
There are two major components of this package: the automated capture of occurrences for screening and the
automation of the review process. The software contains programs that do the following.
Auto Enrollment
Daily running of the auto enrollment routines populates the Occurrence Screen data base. Auto enrollment is
performed by the Clinical Monitoring System. For further information, please see the Clinical Monitoring System
Technical Manual.
Manual Enrollment
Provides for manual enrollment into the data base of occurrences not captured by the auto enrollment due to data not
being available in the system at this time.
Worksheets
Produces copies of Clinical, Peer, Management, Committee, and worksheets to use in the review process.
Standard reports
Produces reports for trend analysis, including the mandated Semi-Annual report of occurrences.
Ad Hoc reports
Permits the creation of Ad Hoc reports by building sort and print templates on the fly.
This software supports the Occurrence Screening process as described in the VHA (Veterans Health Administration)
circular. It gathers and manipulates data for the following Occurrence Screens.
 Readmission within 10 days (Screen 101.1)
 Admission within 3 days following unscheduled Ambulatory Care visit (Screen 102)
 Return to OR in same admission (Screen 107)
 Death (Screen 109)
Provisions are made within the package for the addition of other hospital-specific screens. National screens that
were discontinued through policy changes are listed in the package as "Inactive" but may be made "Local" to
reactivate them. They are as follows:
1. Readmission within 14 days. (Screen 101)
2. Admission within 3 days following Ambulatory Care surgery procedure. (Screen 103)
3. Admission or ASIH from VA Nursing Home Care Unit.
a. Within 14 days of discharge from Acute Care. (Screen 104.1)
b. To Psychiatry Service. (Screen 104.2)
4. Transfer from Intermediate Medicine.
a. Within 14 days of transfer from Acute Care. (Screen 105.1)
b. To Psychiatry Service. (Screen 105.2)
5. Transfer to a Special Care unit within 72 hours of a surgical procedure. (Screen 106.2)
6. Transfer to a Special Care Unit within 72 hours of transfer from a Special Care Unit. (Screen 106.1)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-236
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
5791
5792
5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805
5806
5807
7. Cardiac or respiratory arrest. (Screen 108)
Functional Description
The Occurrence Screen package is a component of the Quality/ Risk Management sub-system within the VistA
(Veterans Health Information Systems and Technology Architecture) system. It is designed to be used as a tool to
accomplish the following.
 Automate the gathering of Occurrence Screen data. This is accomplished by a daily running of the automatic
enrollment routine, which captures screens 101.1, 102, 107 (when site is using the VistA Surgery package) and
109. Refer to the Overview section above for a listing of types of justified exceptions that are excluded by the
software. There is provision for the manual entry of screens if they cannot be or were not auto enrolled from
data currently available in the VistA system.
 Provide for the inclusion of hospital-specific screens within the program. These screens must be entered
manually. It also allows continued tracking of the screens that are no longer required.
 Automate the creation of clinical, peer, management, and committee worksheets. The findings and/or actions of
the previous review levels can be printed.
 Facilitate the tracking of occurrences by means of various tracking reports. An ad hoc report feature is included
for use in trend analysis.
 Produce the Semi-Annual Summary of Occurrence Screening.
Features
 Provides automatic identification of patients for the following occurrences:
o Readmission within 10 days
o Admission within three days following unscheduled Ambulatory Care visit
o Return to operating room in same admission
o Death anywhere in medical facility, except DNR (Do Not Resuscitate)
 Allows for quick entry of exceptions.
 Provides a tracking and reporting system (ad hoc) for all screens.
 Produces worksheets for clinical, peer, management, and committee-level review.
 Tracks patient occurrences through peer and management-level reviews to final disposition.
 Relates quality of patient care with provider-specific information.
 Tracks problems by provider, systems, and equipment.
 Provides required Summary of Occurrence Screening.
 Compiles numerous reports, including:
o Occurrences by Service
o Review Level Tracking
o Patients Awaiting Clinical Review
o Delinquent Reviews
o Adverse Findings
o System/Management/Equipment Problems
o Occurrence Screen Service Statistics
o Ad Hoc Report
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-237
5808
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
Figure: 3.2-37
3.2.28 Patient Representative
This package has three main functions:
• The primary function is the collection and transmission of Time and Attendance (T&A) Report data. The
purpose of this function is to provide an electronic means by which biweekly payroll data can be collected,
processed and transmitted to the Department of Veterans Affairs' Austin Automation Center (AAC) in Austin,
Texas, for the generation of personnel payroll checks. The users accomplish their tasks with seven menus:
Payroll Supervisor Menu, Payroll Main Menu, Timekeeper Main Menu, T&A Supervisor Menu, T&AOT/
Supervisor Menu, Employee Inquiry/ Reports Menu and Employee Menu. These menus are assigned to
authorized users who are responsible for entering,processing or transmitting time and attendance report data to
the AAC.
Any employee with access to the DHCP system may use this package to make leave requests or view their own
leave balances. The manual provides the users with the information necessary to view, enter, and edit time and
attendance report data. The purpose of the time and attendance (T&A) portion of the software is to collect,
process and transmit data necessary to pay employees. The package allows all time and attendance report data
to be posted via a terminal and applies coded payroll rules to "decompose" this posted data into an 8B record for
transmission to the Austin Automation Center (AAC). The target audience includes all employees since any
employee may have access to the station's DHCP system and can make an electronic leave request. The hard
copy time and attendance report has been eliminated.
•
The secondary function is to receive and store employee master record data. The purpose of this function is
to create an employee database which will be available to Payroll and Personnel users for viewing and local
reporting needs. A regularly updated employee database will be used to create a paperless time and attendance
report "stub" record (i.e., the first 32 characters of an 8B record). The users may view the employee master
record data by means of two menus; the Employee Inquiry Menu (sub-menu) designed for Payroll users and the
Employee Inquiry Reports/ Menu designed for Personnel users.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-238
5838
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848
5849
5850
5851
5852
5853
5854
5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870
5871
5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
The package includes a continuously updated employee master record database. Payroll and Personnel users
are the target audience for this database. They are able to view, but not change this data. Employee master
record data from the AAC is stored at the station and updated regularly. The purpose, scope and target audience
for this portion of the software remains the same. The employee master record database rather than a biweekly
8B download is used to create a time and attendance report stub record.
•
The third function is a module that creates an Education Tracking database featuring programs or classes with
multiple attendees and reasons for attending these programs or classes.
This database is made up of each individual employee's program or class attended and all associated data
including: program or class name and supplier, type of media used for presentation, agency to place where
employee or student is from,purpose of the training, a category or name for a desired grouping of program or
classes, type of training (mandatory inservice, continuing education or other training), mandatory review group (if
a required class), financial agency and cost(if government funded), accreditation board (if continuing education)
and employee or student expense (if any or all funding is provided by the employee or student).
The AAC sends employee master record data to the station where it will be stored and updated regularly. The
AAC will generate five types of employee data downloads. They are: Initial, Edit and Update, Payrun, Transfer,
and Separation. This data will be transmitted through MailMan to the station where it will bestored in the PAID
EMPLOYEE (#450) and/or PAID PAYRUN DATA (#459) file. Payroll users will be able to view payroll-related
data in these two files. Personnel users will be able to look at personnel-related data in the PAID EMPLOYEE
file,only.
Features:
Enhanced Time and Attendance:
 Timekeepers can enter and edit employee’s time, view data for current and prior pay periods, and view time card
status for each employee.
 Payroll can view processing status of T&Ls, locate uncertified or incomplete timecards.
 Payroll may also manage T&L units by enter/edit of supervisors, timekeepers and employees.
 Payroll may view pay period data, master records, and accounting data for employees.
 Payroll can create searches of master record and accounting data for custom local reports.
 The payroll supervisor transmits all payroll data to Central PAID in Austin and monitors transmission status.
 The system automatically builds and updates employee records with Central PAID data.
 Authorized personnel may display and search master record and accounting data for all employees.
 Employees may submit electronic leave requests and view leave balances, status of requests, and service
records.
 Supervisors can approve electronic requests and timecards and view employee leave reports.
Education Tracking:
 Creates a class database with pertinent class information: class name, presenter, location, purpose, category,
type, mandatory review group, sponsoring agency, cost, accrediting organizations, employer/student expenses,
contact hours, etc.
 Contains a class registration component that limits class registrants by number or service.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-239
5882
5883
5884
5885
5886



Credits class participation to individual attendee records and allows attendance corrections.
Provides site-configurable mandatory training groups, accrediting organizations, presentation media, supplier
demographics, and class purpose.
Contains reports, such as a calendar of events, a registration roster, service-based class, and a variety of
employee training reports.
5887
5888
5889
5890
Figure: 3.2-38
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-240
5891
5892
Patient Representative - (Component diagram)
cmp Patient Representativ e
Patient Representativ e
«interface»
QAC
5893
5894
5895
5896
Austin Automation Center
Figure: 3.2-39
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-241
5897
5898
3.2.29 PAID-Personnel and Accounting Integrated Data
5899
5900
5901
5902
Figure: 3.2-40
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-242
5903
5904
PAID-Personnel and Accounting Integrated Data - (Component diagram)
cmp PAID-Personnel and Accounting Integrated Data
PAID-Personnel and
Accounting
Integrated Data
«interface»
PRS
Austin Automation Center
5905
5906
5907
5908
5909
5910
5911
5912
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
5932
Figure: 3.2-41
3.2.30 Police and Security
The V. 1.0 Police & Security software package provides an automated system of procedures that generates the
necessary reports and other forms of records pertinent to the VA Police and Security Service (VA Police) operation.
In most instances, a single data entry procedure will create the permanent record, as well as generate statistical data
necessary to produce a variety of management level reports.
By statutory provisions, the Secretary of Veterans Affairs (VA) is responsible for the protection of patients, visitors,
employees, protection of property, and the maintenance of law and order on property under the charge and control of
the Department of Veterans Affairs. This responsibility is subsequently delegated to the Deputy Assistant Secretary
for Security and Law Enforcement who provides program guidance and assistance to the VA Police located at each
VA Medical Center (VAMC). The primary function of the VA Police is to prevent crime on VA property.
The role of the VA Police Officer is crime prevention, preliminary investigation of crimes, apprehension, legally
correct handling of suspected offender(s), and the transfer of suspected offender(s) to appropriate authorities. This
package is designed to assist the VA Police Officers in accomplishing these goals.
The ESP MASTER NAME INDEX file (#910) serves as the primary repository file for the storage of names,
addresses, and other demographic data for all persons who come in contact with the VA Police during normal
operations.
National Upward Reporting includes transmitting the Monthly Crime Report through MailMan to Central Office. The
local office will be able to send a Uniform Offense Report (UOR) to VACO through MailMan to facilitate meeting the
48 hour notification requirement on specific types of investigations.
The V. 1.0 Police & Security software is composed of the following modules.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-243
5933
5934
5935
5936
5937
5938
5939
5940
5941
5942
5943
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
5968
5969
5970
5971
5972
5973
5974
5975
Daily Operations Journal Module
The Daily Operations Journal module provides a system for storage and retrieval of information currently being
manually placed on the VA Police Daily Operations Journal (VA Form 10-1433) and Continuation Sheet (VA Form
10-1433A).
Evidence/Property Module
The Evidence/Property module provides a system to record and retrieve information contained on the Evidence
Property Custody Record (VA Form 10-3524). The electronic record of this information allows the formation of the
required Evidence Property Log and other necessary documentation in a faster manner than the current manual
methods. This module contains several report options for management purposes.
Package Management Module
There are several files contained within the program that should only be altered sporadically once the package has
been fully implemented. This is accomplished through the options in this module.
Quick Name Check Module
The Quick Name Check module allows for the retrieval of stored information for a selected person(s) from files in
several different modules and displays the information. The Quick Name Check option displays any data on file for
an individual, such as vehicle registrations, demographics, wants and warrants, violations, offenses, and previous
investigative involvements.
Criminal Statute Module
The primary menus assigned throughout this program can look at or print any criminal offense code and its definition
within the ESP OFFENSE CODES file (#915). This file is referenced by any “Offense Committed” question
throughout the various modules of the program. Its use is expanded to include an on line lookup in order to
determine the legal wording of each particular criminal offense. It is necessary for each local field station to add any
local medical center, city, county or state ordinances under which they can place criminal charges to the ESP
OFFENSE CODES file.
Training Records Module
The Training Records module provides a system for storing information about training completed by staff members
assigned to VA Police and Security Service. The accumulation of this data allows for the printing of training records
for documentation purposes, as well as management planning for funding justifications.
Uniform Crime Reports Module
The Uniform Crime Reports module accesses selective data from entries in the Offense Report and Violations
modules. This data will be assembled into a standardized report format for the VA Police Chief to document the
numbers and types of criminal incidents occurring at the medical center. The Uniform Crime Report is a greatly
expanded version of the Automated Management Information System (AMIS) report. It provides a much more in
depth record of the type of criminal activities which occur, as well as recording dollar values for investigations dealing
with loss and recovery factors. The Uniform Crime Reports module downloads and transmits the Uniform Crime
Reports to the database maintained within Security and Law Enforcement in Washington, DC. The combined
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-244
5976
5977
5978
5979
5980
5981
5982
5983
5984
5985
5986
5987
5988
5989
5990
5991
5992
5993
5994
5995
5996
5997
5998
5999
6000
6001
6002
6003
6004
6005
6006
6007
6008
6009
6010
6011
6012
6013
6014
6015
6016
6017
6018
statistical data from all VAMCs will provide important information at the national level to the Deputy Assistant
Secretary for Security and Law Enforcement regarding program planning strategies.
Offense Reports Module
The Offense Reports module facilitates the entry of data normally contained on the VA Police Uniform Offense
Report, Investigative Notes, and Case Log. It will also facilitate entry of data from preparatory documentation
assembled during a criminal investigation. By entering the data into the Offense Reports Module, the VA Police
Officer will be creating an electronic record of his investigation that will be readily retrievable for future use. At the
same time, the software package will be assembling statistical data for creating trend studies and other beneficial
management tools.
Vehicle Registrations Module
The Vehicle Registrations module records all information necessary for the maintenance of the VA Police Vehicle
Registration program. The information contained within this module is highly beneficial to those VAMCs operating a
Ride Sharing Program. Because of the diverse complexity of operations throughout the VAMCs, ranging from single
building high-rise complexes to large expanded-campus style facilities, this module also contains a system of
miscellaneous registration files that can be used at the discretion of the individual VA Police Chief.
Violations Module
The Violations module allows for the entry of all violation information contained on US District Court Violations
Notices and Courtesy Warnings issued by VA Police Officers at the medical center. This module generates several
types of management tracking reports.
Wants & Warrants Module
The Wants & Warrants module is used to record any data pertinent to individuals currently under any type of criminal
proceedings. This includes individuals with outstanding warrants, summons, court commitments, or other types of
legal documentation. This module provides a flag notification to officers on duty that the individual in question is
wanted, has been involved in some prior serious physical altercation, or other incident that can require additional
preparation, or requires caution when being approached. The Wants & Warrants module contains several print
options for maintaining list of persons currently in an active want or detained status.
Daily Activity Module
The Daily Activity module provides a method for VA Police Officers to enter specific activities that occurred during
their tours of duty and the time required to complete these activities. This module also allows a VA Police Officer to
create an entry of his or her activities and combine them with the entries of other VA Police Officers. This information
helps the Chief of VA Police to justify and plan the patrol activities of the VA Police and Security Service.
Features
 Serves as the repository file for the names, addresses, and other demographic data of persons who come in
contact with the VA Police and Security staff.
 Allows for the retrieval and display of stored information for a selected person.
 Stores electronic data normally entered on the VA Police Uniform Offense Report, Investigative Notes, Case
Log, and other documentation assembled during an investigation.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-245
6019
6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049










Contains all violation information on US District Court Violations Notices and Courtesy Warnings issued by VA
Police Officers at the medical facility.
Assembles selective data into a standardized report format documenting the numbers and types of criminal
incidents that are occurring at the site.
Records information necessary for the Vehicle Registration program.
Records any data pertinent to individuals currently under any type of criminal proceedings or other legal
restraining document.
Provides a system to record all information contained on the Evidence Property Custody Record (VA Form 103524).
Allows each police officer to record the specific activities performed during a shift and the time required to
complete the activities.
Stores all information relative to training completed by staff members assigned to the Police and Security
Service.
Stores all information entered on the VA Police Daily Operations Journal (VA Form 10–1433) and Continuation
Sheet (VA Form 10-1433a).
Transmits Monthly Crime Reports and selected Offense Reports through Mailman to VA Headquarters.
Produces supervisory management, quality management, and crime trend studies; a standardized Uniform
Offense Report, Uniform Crime Report, and Evidence Register Report; and Case Progress Notes and Case
Assignment Register.
Figure: 3.2-42
3.2.31 Quality Management Integration Module
The QM Integration Module (often called the QAQ routines) contains utilities that are common to some or all of the
QM software packages. Utilities that you may recognize are as follows.
• The date selector is found within many of the reports options. It lets the user choose the date range that is
needed for the report.
• The group selector lets the user select more than one item to print or view at a time. This reduces the number of
key strokes needed to produce a specific outcome.
• The Ad Hoc Report Generator uses basic VA FileMan sort and print modifiers and adds the capability of building
macros (often termed templates) for those reports that are routinely required.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-246
6050
6051
6052
6053
6054
6055
6056
6057
6058
6059
6060
6061
6062
6063
6064
6065
6066
6067
6068
6069
6070
6071
6072
6073
6074
6075
6076
6077
6078
6079
6080
6081
•
The audit file builds an audit trail for each record in the QM packages. You can see the contents of the audit file
in the Occurrence Screen software by using the Audit File Inquiry option. In other software, the audit trail is
accessible to the IRM staff through VA FileMan.
•
The QM Integration Module links the QM software through a QM Manager menu.
The Combined Site Parameters Edit option should be used whenever any new package is installed. Refer to the user
documentation for each individual QM software package for suggestions on menu management.
Figure: 3.2-43
3.2.32 Record Tracking
The prompt availability of patient records is an essential ingredient in the delivery of quality medical care. Lack of
access to vital patient history contained in these records may lead to life-threatening situations.
The VA Record Tracking system is a comprehensive software package, written to aid file activities in assuring
optimum availability of these records to a broad range of users within and outside the facility. Functions which were
previously done manually have been computerized, promoting greater efficiency, uniformity and accuracy.
Demographic record information is now available on-line to a broad range of users as well as a variety of reports
which have been included to assist management in workload analysis and quality assurance.
The system has been designed so that it may be used in conjunction with bar code technology, further enhancing
efficiency and accuracy. The Record Tracking system uses VA FileMan and integrates with the Radiology and PIMS
packages in performance of its functions.
This package was originally designed for use in tracking Medical Administration and/or Radiology records. A great
deal of flexibility has been built into the system so that it may be custom-tailored to meet the needs of practically any
file activity.
Features:
 Uses bar code technology, prints bar code labels for the charts, and uses bar code equipment to charge records.
 Displays informational bulletins when a record is checked into a file room.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-247
6082
6083
6084
6085
6086
6087
6088
6089
6090
6091
6092
6093
6094
6095
6096
6097
6098
6099
6100
6101
6102
6103
6104
6105
6106
6107




Bulletins may include the following information: pending requests for the record, the record has previously been
flagged as missing, loose filing exists, the patient is currently an inpatient, or the record is being checked into a
file room other than its home.
Offers a complete system for maintenance and control of records that may be used with ease in any type of file
setting.
Produces a variety of reports associated with the module that may be used to assist management in workload
analysis and control of records.
Creates pull lists to provide requests for records in conjunction with clinic scheduling and record retirement.
Figure: 3.2-44
3.2.33 ROI-Release of Information Manager
The Release Of Information System (ROI) is a Document Storage Systems, Inc. (GUI) application that is designed to
provide health care facilities with an intuitive, user friendly Windows interface for end-users to use to request patient
medical record information.
The ROI Manager is an application that uses "RPC Broker" technology that permits the facility users to retrieve
clinical data within the VistA System. The user can work offline of VistA and only administrator functions will be
active. The ROI Manager Encounter System database is linked to the VistA System database that stores registered
patient documentation. These databases are “in sync” with each other and reduce data entry time because certain
data fields are automatically populated (or filled-in) ensuring data accuracy.
The ROI system tracks requests for privacy act information for patients receiving
treatment at VA facilities.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-248
6108
6109
6110
6111
6112
6113
6114
6115
6116
6117
6118
6119
6120
6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133
6134
6135
6136
Figure: 3.2-45
3.2.34 VIC/PICS-Veteran Identification Card
The Veteran Identification Card (VIC) replaces the embossed data card as a means of identifying veteran patients
entitled to care and services at Department of Veterans Affairs (DVA) health care facilities.
The replacement VIC displays a larger color photograph of the veteran and the veteran’s name. There is no
embossed information on the card. A VistA print option provides labels with the patient’s identifying information. The
labels can be affixed to medical record forms in lieu of using the embossed cards to imprint this information when
pre-printed forms are not available.
A color photograph of the veteran is taken at the local medical center using the Patient Image Capture Software
(PICS) on a Clinical Context Object Workgroup (CCOW) enabled workstation. The photograph is sent to the local
VistA Imaging server, making it available to the Computerized Patient Record System (CPRS) and other VistA
applications. The photograph and VistA patient data is also transmitted to the National Card Management Directory
(NCMD) in Silver Spring, MD (a repository of VIC data).
Once the Health Eligibility Center (HEC) has verified the patient’s eligibility, the veteran has been assigned an
appropriate enrollment status, and also assigned a national Integration Control Number (ICN), the VIC data and
images are transmitted to the external card print vendor using secure protocols. The external card print vendor
creates the VIC cards and mails them to the veterans. For homeless veterans, the external card print vendor mails
the cards to the appropriate medical center, which then issues the cards to those veterans.
Features
• Veteran’s picture, name, and care type (i.e., service connected) on card face as well as POW and Purple Heart
status as appropriate.
• Magnetic stripe on card encoded with the patient’s name, social security number, date of birth, sex, patient type,
veteran status, and service-connected indicator.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-249
6137
6138
6139
6140
Figure: 3.2-46
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-250
6141
6142
VIC/PICS-Veteran Identification Card - (Component diagram)
cmp VIC/PICS-Veteran Identification Card
VIC/PICS-Veteran
Identification Card
«interface»
DG
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
6160
6161
6162
6163
6164
6165
6166
6167
6168
6169
6170
6171
National Card Management
Diretory (NCMD)
Figure: 3.2-47
3.2.35 VSS-Voluntary Service System
The Voluntary Service System (VSS) software is the first application to be developed in the current VistA Migration
effort. VSS is a national-level application replacing the site-based Voluntary Timekeeping System (VTK). VTK has
been used for many years at VA medical centers to track and manage the hours of service contributed by volunteers
and volunteer organizations.
To improve data collection and reporting, users interact directly with a national, centralized database. Consolidated
national reporting no longer requires data transmissions back and forth between sites and the Austin Information
Technology Center (AITC). Direct access to data provides instantaneous updates and up-to-minute reporting for all
users. Central Office administrators and voluntary staff thus have broader and more reliable data for managing
volunteer services.
The VSS application helps voluntary staff accomplish their tasks more easily through a Web-based graphical user
interface. Users at the local and national level are able to generate a wider array of reports about volunteers and
sponsoring organizations. In addition, volunteers are able to log their own hours and print meal tickets themselves at
secure log-in “kiosks.”
Features
• Provides multi-lingual interaction with volunteers during log-in.
• Supports and enhances security for multiple division facilities.
• Displays/prints entire master record for a single volunteer.
• Provides local printing of address labels and telephone lists.
• Reduces workload required to input mass award code changes.
• Prints individual meal ticket for volunteer after Auto Log-in.
• Provides real-time national reporting of data for all stations.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-251
6172
6173
6174
6175
6176
6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187
6188
6189
6190
6191
6192
6193
6194
6195
6196
6197
6198
6199
6200
6201
Figure: 3.2-48
3.2.36 Wounded Injured and Ill Warriors
This document is in response to the action item developed by the Wounded, Ill, and Injured Senior Oversight
Committee, Support and Care for the Wounded - Task Force, under Line of Action (LOA) #8 Pay Management, to
develop a tool to provide accurate and timely personnel and health related data to the Defense Finance and
Accounting Service (DFAS) supporting adequate maintenance of pay and entitlements for all wounded warriors. This
document specifies the Technical and Security Guide for the Interim Solution which will satisfy this requirement. It is
envisioned that a future solution will be fully automated and is described below.
Currently, the Department of Defense’s (DoD) Wounded Warrior Pay Management Program (WWPMP) has identified
pay issues for Active Duty Service Members who are admitted to non military medical treatment facilities due to
combat-related injuries. Veterans Health Administration (VHA) often provides inpatient and outpatient health care
services to Active Duty Service members. The Department of Defense/Defense Finance and Accounting Service
(DoD/DFAS) has experienced difficulty in keeping accountability for this population and the lack of accurate
accountability may adversely impact the pay of Service Members.
In the fall 2007, through a collaborative effort between the Department of Veterans Affairs (VA), VHA and DoD/DFAS
VA and VHA agreed to provide defined data elements to DoD/DFAS to facilitate tracking of Active Duty Service
Members admitted to inpatient VA facilities. In February 2008 a Memorandum of Understanding (MOU) by and
between VA and VHA and DoD/DFAS was executed. The MOU established the authorities and agreement for the
exchange of information relating to admission to and discharge from inpatient VA health care facilities of Active Duty
personnel. A copy of the executed MOU is enclosed in Appendix A. This agreement is consistent with and supports
the mission of the VA/DoD Joint Executive Council to improve the quality, efficiency and effectiveness of the delivery
of pay benefits to service members admitted to inpatient VA services.
There were two (2) solutions conceived during the conceptualization of how these requirements could be met. The
first is the Interim solution, which can be put into service in a short period of time, but has the drawback of being
more labor intensive. The Interim Solution is the focus of this Technical Manual and Security Guide. The second
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-252
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
6213
6214
6215
6216
6217
6218
6219
6220
6221
6222
6223
6224
6225
6226
6227
6228
6229
6230
6231
solution, named the Future solution will eliminate all manual processes, sending the records to a central server which
will collect and transmit them automatically to the DoD/DFAS on a periodic basis. The Future solution will not be
started until the Interim Solution is implemented and analyzed. The Interim Solution requires a weekly data collection
process at each VA inpatient facility of Active Duty Service Members admitted and discharged. DoD/DFAS requires
a complete list of all Active Duty patient admissions/ discharges within the VA. Appendix B provides a detailed list of
the data requirements. Each VA inpatient facility will transmit its list of Active Duty inpatients by secure email to the
central collection facility. The approved/ released list is then sent to the VA collecting repository at the central
collecting facility, via a secure Vista mail server. Each facility’s transmission is collected into one list by a VA
coordinator specifically trained to perform this function. The list of all Active Duty Service Members admitted to or
discharged from inpatient VA facilities is then transmitted to the DoD/DFAS via an encrypted email to a secure
DoD/DFAS mailbox. This address has been provided to the VA and VHA by DoD/DFAS. The report, as defined in
Appendix B and detailed in Section Format Transmissions to DFAS (page 24) will include the Active Duty Service
Member’s first name, middle name or initial, last name, and social security number, and his/her admission date and
time and/or discharge date and time and the facility identification number.
Note: Facilities that do not have any admissions and/or discharges during the reporting period are required to submit
an email stating that there were no admissions and/or discharges.
It is assumed that the Interim Solution will be accomplished as follows:
 A patch delivered to the Vista ADT software.
 Training of designated staff at each facility
 Deployment of patch following a several week testing period.
Figure: 3.2-49
3.3 Infrastructure
Common Services team develops and maintains the underlying software infrastructure supporting both
legacy and current veteran health-related applications. Though largely transparent to end users,
Common Services provides essential infrastructure elements such as identity management, security,
message routing, transformation, and data transport for clinical and administrative applications. Core
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-253
6232
6233
6234
6235
common services are addressed through three programs: Identity Management, Security and Other
Common Services, and Messaging and Interface Services.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-254
class Infrastructure
EELS
STK
MDWS
E3R
FatKAAT
VA FileMan
Surv ey Generator
Standard Files
and Tables
KDC
National Patch
Module
KAAJEE
Kernel Toolkit
Kernel
Toolkit-Parameter
Tools
Kernel
Toolkit-Patch
Monitor
Inpatient
MPI-Master
Patient Index
(AUSTIN)
MailMan
XML Parser
(VistA)
CIRN
Registration
HL7 (VistA
Messaging)
Laboratory
NDBI
Kernel
OE/RR-Order
Entry/Results
Reporting
New Person,
3/6/16/20 Killer
Patch
CPRS:ART
Pharmacy
DSM for OpenVMS
AXP
Open VMS AXP
SQLI
MPI
RPC
Context Vault
Patient Merge
KIDS
TaskMan
NHE
M-to-M Broker
Kernel Unw inder
ZSLOT
RUM
VDEF
Name
Standardization
SAGG
HDI
CMT
M-to-SQL Product
SSO/UC
List Manager
PDX
NOIS
IFR
VistALink
FMDC
6236
6237
Figure: 3.3-1
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-255
6238
6239
6240
6241
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
3.3.1 CMT-Capacity Management Tools
The Capacity Management Tools software application provides fully automated support tools developed by Capacity
Planning Service. It entails the daily capture of the following data from participating sites:
• VistA Health Level Seven (HL7) Workload Information—VistA HL7 workload data is summarized and transmitted on
a weekly basis.
• VistA Timing Data—Timing data is summarized and transmitted on a daily and weekly basis.
Data collected is automatically transferred via network mail (i.e., VistA MailMan) to the Capacity Planning National
Database. The data is displayed graphically on the Capacity Planning Statistics Web page located at:
http://vista.med.va.gov/capman/Statistics/Default.htm
The Veterans Health Administration (VHA) developed the Capacity Management Tools software in order to obtain
more accurate information regarding the current and future VistA HL7 workload data at VA sites.
Figure: 3.3-3
3.3.2 Duplicate Record Merge
Kernel Toolkit (Duplicate Record Merge: Patient Merge) is a Kernel Installation and Distribution System (KIDS)
software release. It requires a standard VistA operating environment in order to function correctly.
Patient Merge provides an automated method to eliminate duplicate patient records within the VistA database. It is an
operational implementation of the Duplicate Resolution Utilities, which were released to the field with Kernel Toolkit
(Patch XT*7.3*23).
The overall process consists of three major subject areas: 1) the search for and identify potential duplicate record
pairs, 2) the review, verification, and approval of those pairs, and 3) the merge process.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-256
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
6293
6294
6295
6296
6297
6298
6299
6300
6301
6302
6303
6304
6305
6306
The search and identification of potential duplicate records performs comparisons on key patient traits in the
centralized Person Service Identify Management (PSIM) database. The goal of PSIM is to provide an authoritative
source for persons’ identity traits throughout the Veterans Health Administration (VHA). The Initiate Probabilistic
Search Implementation in PSIM adds advanced search capabilities to improve the overall matching process during
Search, Add and Update processes. The advanced search capabilities also provide enhanced capabilities for Identity
Management Data quality (IMDQ) case workers who perform patient identity management data quality tasks.
PSIM determines that a pair of patients is a duplicate, or potential duplicates. Potential duplicates are further
reviewed by the Identity Management Data Quality team (IMDQ). If a pair of patients is determined to be duplicates,
and if both patients are known at a VistA site, the patient pair is added to the local VistA DUPLICATE RECORD file
(#15). An email is sent to members of the mail group found in the DUPLICATE MANAGER MAIL GROUP field of the
record associated with patients, in the DUPLICATE RESOLUTION file (#15.1). Once a potential duplicate pair has
been identified, the process of verifying record pairs begins.
The review and verification process includes two levels of review. The primary reviewer, initially seen as an MAS
responsibility, performs a review of patient demographic information. The primary reviewer initially determines if the
pair represents a duplicate record. If so, the primary reviewer selects the merge direction. If data from ancillary
services is present, notification (via MailMan message or alert – or both) is sent to those designated as ancillary
reviewers. A site may determine reviewers based upon their business practices. Reviewers determine whether the
record pair is a duplicate, not a duplicate (so that subsequent processing need not occur), or that they are unable to
determine the status. Where appropriate, reviewers may mark data to be overwritten. Those record pairs that are
determined to be verified duplicates are marked as such and are then available for approving to be merged.
The intent of the approval step is to ensure that a conscious decision will be made in taking verified duplicate record
pairs and making them available for a merge process. All verified record pairs, or selected pairs, can be approved.
The approval step follows a site defined waiting period. Reviewers are responsible for approving verified duplicates.
The merge process is available for initiation by IRM personnel. All approved record pairs are included in a merge
process when scheduled. The merge process is a lengthy process that is recommended for off-peak hours. Utilities
are available for pausing and restarting the merge process. The merge process merges verified duplicate records in
the following order: first, files that require special handling, then the primary file, then the resolution of pointers. The
resolution of pointers for the primary file or any of those involving special processing involves three phases. The first
two phases permit identification of entries requiring modification based on their IENs (DINUMed) or by crossreferences and are fairly rapid. The third phase involves all other pointers and can be lengthy. Several special
processing routines have been written to handle those database entries that point to the PATIENT file (#2) in an
unusual manner. Entries for each special processing routine have been made in the PACKAGE file (#9.4) multiple,
AFFECTS RECORD MERGE field (#20). A stub record is maintained in order to disallow reuse of PATIENT file (#2)
internal entry numbers.
Concurrent with the merge, entries are made in a new global for each record making up the pair. The entries are
intended to provide a "before-merge" image. However, please note that the merge is a non-reversible process. Once
the pair of records is merged, there is no automated way of undoing the process.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-257
6307
6308
The application has been written to support multiple parallel jobs (threads - as specified by the site) during the merge
process. However, decreased overall processing time is exchanged for increased system utilization.
6309
6310
6311
6312
Figure: 3.3-4
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-258
6313
6314
6315
6316
6317
6318
6319
6320
6321
6322
6323
6324
6325
6326
3.3.3 E3R-Electronic Error and Enhancement Reporting
There are no documents for this application at this point. (As of: October 30, 2009)
Figure: 3.3-5
3.3.4
EELS-Enterprise Exception Log Service
There are no documents for this application at this point. (As of: October 30, 2009)
Figure: 3.3-6
3.3.5 FatKAAT
There are no documents for this application at this point. (As of: 30 October 2009)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-259
6327
6328
6329
6330
6331
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
6351
6352
6353
6354
6355
6356
Figure: 3.3-7
3.3.6 VA FileMan
VA FileMan is a database management system (DBMS) with powerful Application Program Interfaces (APIs) and
provides useful utilities for application developers. VA FileMan can be used as a database management system for
data entry and output and its DBS calls are utilized in application packages with tools like Filegrams, auditing,
archiving, and statistics.
• Database Management System (DBS)—As a database management system (DBS), VA FileMan supports the
entering, editing, printing, searching, inquiring, transferring, cross-referencing, triggering, and verifying of information.
It includes special functions to create new files, modify an existing file, delete entire files, re-index files, and create or
edit templates.
• Application Program Interfaces (APIs)—As an application program interface (API), the Database Server routines
manage interactions between the application software and the database management system "silently," that is,
without writing to the current device. Package developers use DBS calls to update the database in a non-interactive
mode. Information needed by the VA FileMan routines is passed through parameters rather than through interactive
dialogue with the user. Information to be displayed to the user is passed by VA FileMan back to the calling routine in
arrays. This separation of data access from user interaction makes possible the construction of alternative front-ends
to the VA FileMan database (e.g., a windowed Graphical User Interface [GUI]).
• Utilities—As a set of utilities, VA FileMan provides tools like the Filegram, which is a tool that moves file records
from one computer to another; archiving, which is a tool that stores data onto an offline storage medium; auditing,
which is a tool that tracks changes to data in a field or to the file's structure (the data dictionary); and statistics, which
is a tool that accumulates totals and subtotals of individual fields.
Programmers and non-programmers use VA FileMan alike. VA FileMan can be used as a stand-alone database or
as a set of application utilities. In either mode, it is used to define, enter, and retrieve information from a set of
computer-stored files, each of which is described by the data dictionary.
VA FileMan is a public domain software package and is widely used in clinical, administrative, and business settings
in the United States and abroad.
Standalone VA FileMan
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-260
6357
6358
6359
6360
6361
6362
6363
6364
6365
6366
6367
6368
VA FileMan is designed to be used either with Kernel or as a standalone application running under a variety of
implementations of ANSI standard M. If VA FileMan is used without Kernel, the basic DBMS features of VA FileMan
all work as described in the manuals. However, there are some features (e.g., bulletin-type cross references, print
queuing, and Filegrams) that do not work without portions of Kernel. Whenever Kernel is needed to support a
particular VA FileMan feature, that fact is mentioned in the manuals.
The installation of VA FileMan 22.0 is not integrated with the installation of Kernel. The VA FileMan Installation Guide
contains instructions on how to install VA FileMan, both for standalone sites and for sites running Kernel.
NOTE: The Kernel Toolkit (Duplicate Record Merge: Patient Merge) application brings a new browser setup.
XDRBROWSER1 is specifically designed to work with Patient Merge. It is a modified version of the VA FileMan
Browser.
6369
6370
6371
6372
Figure: 3.3-8
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-261
6373
6374
6375
6376
6377
6378
6379
6380
6381
6382
6383
6384
6385
6386
6387
6388
6389
6390
6391
6392
6393
6394
6395
6396
6397
6398
6399
6400
6401
6402
6403
6404
6405
6406
6407
6408
6409
6410
6411
6412
6413
6414
6415
6416
3.3.7 FMDC-FileMan Delphi Components
The FileMan Components for Delphi applications make it easy for developers to work with VA FileMan data in Delphi
applications. The components encapsulate the details of retrieving, validating and updating VA FileMan data within a
Delphi application. This saves you from creating your own custom remote procedure calls (RPCs) when you need to
access VA FileMan data.
The FileMan Delphi Components also include special enhanced features such as complete server-side error
checking and data dictionary help.
If you're already familiar with Delphi, the time needed to develop an application to edit a set of VA FileMan fields
using the FileMan Delphi Components is comparable to the time needed to create the same application using VA
FileMan's roll-and-scroll ScreenMan interface.
The FileMan Delphi Components provide three types of components:
• Data Access Components are invisible to the user, but contain the functionality for calling the server to find,
retrieve, validate, and file data. Each of the data access components encapsulates the functionality of one or
more VA FileMan Database Server (DBS) calls.
• Custom Dialogues are like mini-applications you can include in your own application. The TFMLookUp custom
dialogue makes it easy to perform lookups in files with large numbers of records.
• Data Controls are visual controls users can interact with to change data values. For example, a TFMCheckBox
control is good for editing "Boolean" two-value set of codes fields; a TFMMemo control is good for editing wordprocessing fields; and a TFMEdit control is good for editing free text fields. Data controls are directly populated
by the data access components. Values are directly validated and filed from the controls by the data access
components.
There are 17 FileMan Delphi Components, and each one has a variety of methods and properties that allow you to
fine-tune its behavior. However, a basic approach to using them, involving only a subset of their properties and
methods, is appropriate for most data editing situations.
To follow this basic approach: First, determine the set of fields you want to edit in your Delphi application. Then follow
this Quick Start Guide to provide that access in your Delphi application.
The FileMan Delphi Components provide the following components for use in Delphi:
1. TFMFiler
2. TFMFinder
3. TFMFindOne
4. TFMGets
5. TFMHelp
6. TFMLister
7. TFMValidator
8. TFMLookUp
9. TFMCheckBox
10. TFMComboBox
11. TFMComboBoxLookUp
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-262
6417
6418
6419
6420
6421
6422
6423
6424
6425
6426
6427
6428
6429
6430
6431
6432
6433
6434
6435
6436
6437
6438
6439
6440
6441
6442
6443
6444
12.
13.
14.
15.
16.
17.
TFMEdit
TFMLabel
TFMListBox
TFMMemo
TFMRadioButton
TFMRadioGroup
The FileMan Delphi Components provide the following objects for use in Delphi:
 TFMErrorObj
 TFMFieldObj
 TFMHelpObj
 TFMRecordObj
The FileMan Delphi Components provide the following Pascal routines for use in Delphi:
 DeleteRecord
 LockNode
Referenced in FMDC-FileMan Delphi Components documentation.
Broker Development Kit. Provided with VISTA's RPC Broker software package, this contains the files necessary to
connect to a VISTA M server from a Windows client.
Figure: 3.3-9
3.3.8 Health Data Informatics
The Health Data Informatics (HDI) package provides a basic method for seeding VHA Unique Identifiers (VUIDs) for
reference data in existing VistA applications. A VUID is a meaningless number, which is automatically assigned to
concepts, properties, and relationships in a terminology to facilitate their access and manipulation by computers.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-263
6445
6446
6447
6448
6449
6450
6451
6452
6453
6454
6455
6456
6457
6458
6459
6460
6461
6462
6463
6464
6465
6466
6467
6468
6469
6470
6471
6472
6473
6474
6475
6476
6477
6478
6479
6480
6481
The HDI package will be used by each VistA site to seed VUIDs in their existing global files that contain reference
data, such as drug names, names of known allergens, and so forth. These files have been grouped into domains,
and each domain will be standardized separately. As each domain’s files are originally standardized, the HDI
package is used to assign a VUID to each term or concept in the file. Subsequent standardization updates and
maintenance on these files will be handled separately by the New Term Rapid Turnaround (NTRT) program.
Installation of this package anticipates the installation of domain-specific application patches, applied to any
application(s) that make use of the standardized reference data files. Requirements documentation for each affected
domain is separately available from Data Standardization. These application patches (e.g. GMRV*5.0*8) will, in
general terms: change the data dictionary and global files to prevent modification of data; and modify existing data
dictionary files to add additional fields, including the VUID field and fields for determining the current status of a term.
The application patches will also modify user interfaces (both graphical and roll-and-scroll) to screen out all reference
data whose status is ‘not active.’ Once these changes are in place, the application patch makes a procedure call to
the HDI package, instructing it to seed the VUIDs and statuses for each reference term.
Once the Application Patch has been installed for the Data Domain, the Application post-initialization routine calls an
API in the HDI package which creates an XML file for each of the files being standardized. The XML file includes the
Term/Concept (.01 Field) from each of the files. Each XML file is then forwarded to the central server, FORUM. On
the FORUM server, the XML file is compared with the standardized data from Enterprise Terminology Services
(ETS). The data received from the facility is modified as follows: (1) FORUM sets a VUID value for every matching
entry; (2) any unmatched local entries are assigned a VUID from a block of available numbers, and identified as
inactive terms; and (3) any duplicate entries are identified as inactive terms. This information is then passed back to
the facility as an XML file, which is used by the HDI package on the Facility Server to update the VistA files.
Once the Facility’s VistA files have been updated, a MailMan mail message is automatically sent to the Enterprise
Reference Terminology (ERT) team. The ERT team will manually initiate a Master File Server (MFS) push through
the Vitria Interface Engine (VIE), which will complete the file update with data for additional fields not modified by the
HDI package. This ERT update relies on VUIDs as a key for inserting the standardized data. At this point, the facility
is considered standardized for that particular VistA file.
Once the Facility’s VistA file is standardized, the Application patch may optionally invoke a post-processing routine
through MFS—for example if there is a need to perform any necessary cleanup tasks on the standardized file. When
the post-processing routine completes its processing, or if there was no post-processing routine, the Health Data
Repository (HDR) Implementation managers are notified automatically via another MailMan message. This message
notifies HDR that the site is ready to have VistA Data Extraction Framework (VDEF) triggers turned on, which
enables communication between the Facility’s VistA Server and the HDR/IMS database.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-264
6482
6483
6484
6485
6486
6487
6488
6489
6490
6491
6492
6493
6494
6495
6496
6497
6498
6499
6500
6501
6502
6503
6504
6505
6506
6507
6508
Figure: 3.3-10
3.3.9 Health Level Seven (HL7) (VistA Messaging)
Patches
 HL*1.6*131
 HL*1.6*126
The Health Level Seven (HL7) software package provides an interface that allows DHCP applications to exchange
healthcare data with other applications using the HL7 protocol.
The HL7 package consists of a set of utility routines and files that provide a generic interface to the HL7 protocol for
all DHCP applications. The HL7 package can be divided into two parts:
• Lower level* protocol support between sending and receiving applications
• DHCP interface to the HL7 protocol
The DHCP Interface to the HL7 Protocol
With the release of V. 1.6, DHCP HL7 supports several methods for interfacing to the HL7 protocol. The method
established by v1.5 is still supported (for backwards compatibility), and a new method is introduced, as well as new
routines,file structures,
templates, menus, and options. There are some significant differences between the v1.5 and v1.6 interface methods,
as shown in the following table.
v1.5 Interface Method / v1.6 Interface Method
 One sender and one receiver per message. / One sender, one or more receivers.
 Sender and receiver must be on different systems. / Sender and receiver can be on the same or different
systems.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-265
6509
6510
6511
6512
6513
6514
6515
6516
6517
6518
6519
6520
6521
6522
6523
6524
6525
6526
6527
6528
6529
6530
6531
6532
6533
6534
6535
6536
6537
6538
6539
6540
6541
6542
6543
6544
6545
6546
6547
6548
6549
6550
6551
6552



Messages must go through a communications protocol. / Messages sent to applications on the same system
do not have to go through a communications protocol.
All messages are processed in the background. / Messages are processed in either the foreground or
background, based on the priority assigned by sending/ receiving applications.
No support for event points. / Event points are supported.
History of the VistA HL7 Package
VistA HL7 is an implementation of an HL7 interface engine. It is an M-based software product that assists M-based
VistA applications by providing a means for those applications to send and receive HL7 messages.
VistA HL7 does not provide tools to map VistA data directly to HL7 messages. It does provide a repository of
supported HL7 transactions, connectivity between systems, and guaranteed delivery of messages using supported
Lower Layer Protocols (LLPs). It supports point-to-point interfaces, publish and subscribe, and content-based
dynamic routing.
[*Lower Level Protocol refers to a portion of the Open Systems Interconnect (OSI) model. The OSI model is divided
into seven layers or levels. The lower levels (Layers 1 through 4) support the actual movement of data between
systems. This includes the actual physical connection between the systems and the communications protocol used.]
M-based VistA applications can use VistA HL7 to interfac!
e with any other system that also supports standard HL7 messaging, including many standalone medical devices,
non-M-based applications on other systems, and VistA M-based applications running on a different VA facility's
systems. As such, VistA HL7 acts as an Enterprise Application Integration (EAI) solution for VistA applications.
HL7 Standard Support
VistA HL7 supports message transactions for each of the following versions of the HL7 standard:
• 2.1 (HL7 standard publication date: 6/1990)
• 2.2 (HL7 standard publication date: 12/1994)
• 2.3 (HL7 standard publication date: 4/1997)
• 2.3.1 (HL7 standard publication date: 5/1999)
• 2.4 (HL7 standard publication date: 11/2000)
Evolution of VistA HL7
The first released version of VistA HL7 was 1.5, and supported simple point-to-point HL7 transactions between VistA
and a local COTS system using Hybrid Lower Layer Protocol (HLLP), and to other VA facilities using VA MailMan.
The initial release of version 1.6 added the ability to "broadcast" a message to multiple recipients, and support for the
X3.28 LLP. A continuing increase in the demand for additional messaging services has resulted in enhancements to
HL 1.6, released through patches, including more complex message routing (dynamic addressing), and messaging
using Minimal Lower Layer Protocol (MLLP) over TCP.
The current release of HLO is a substantial redesign of HL 1.6. It is designed to be able to operate alongside HL 1.6,
and provides significantly higher operating efficiency and the ability to operate with a substantially decreased system
load. In addition, HLO has some enhancements in the way it provides support for building and parsing of HL7
messages.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-266
6553
6554
6555
6556
6557
6558
6559
6560
6561
6562
6563
6564
6565
6566
6567
6568
6569
6570
6571
6572
6573
6574
6575
6576
6577
6578
6579
6580
6581
6582
6583
6584
6585
6586
6587
6588
6589
6590
6591
6592
6593
6594
6595
Since the early 1990’s, the VA has maintained a corporate membership with the Health Level Seven standards
organization, and has been an active participant in the evolution of the HL7 standard. Application developers for
VistA's Radiology, Pharmac!
y, Lab, PIMS, and other packages have aggressively enhanced those packages to support HL7-defined event points.
Examples include "patient registration," "admit a patient," "lab results available," and "place an order." When one of
these event points occurs, the VistA application now generates a corresponding HL7 message, which VistA HL7
distributes to all interested subscribers.
Overview and Background - HL Optimized (HLO)
HLO is an optimized version of HL 1.6.
 All but one file used by HLO is new. The only HL 1.6 file that is used by HLO is the HL LOGICAL LINK File
(#870).
 There are more than 30 new routines used by HLO, as opposed to approximately 200 routines in the existing HL
1.6.
 The new namespace is HLO*.
HLO engine will co-exist with the existing HL 1.6 engine.
 Existing HL7 applications written for the HL 1.6 engine (HL 1.6 applications) can continue to run without
modification.
 The conversion of existing HL 1.6 applications to HLO applications can be fairly straightforward, though testing
of the application is essential.
 There is virtually no shared code between the HL 1.6 and HLO engines. Thus, modifications and enhancements
of applications written for one HL7 engine can be made without extensive testing of the application being
required on the other HL7 engine.
Goals of HLO:
 Improve the messaging throughput.
 Make it easier for application developers to use.
 Make the software more robust, less susceptible to bugs, and require minimal maintenance overhead.
The following HL7 patches are required before installation of HL*1.6*126:
• HL*1.6*84
• HL*1.6*118
Archiving
There is no archiving in the HL7 software package.
Purging
For purging, use the Purge HL7 MESSAGE TEXT File Entries [HL PURGE TRANSMISSIONS] option in the HL7
Main Menu (HL MAIN MENU), which purges entries from the !
HL7 MESSAGE TEXT file (#772). The purge will only delete entries that are at least seven days old.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-267
6596
6597
6598
6599
6600
6601
6602
6603
6604
6605
6606
6607
6608
6609
6610
6611
6612
6613
6614
6615
6616
6617
6618
6619
6620
6621
6622
6623
The HL7 MESSAGE TEXT file (#772) contains a record of all outgoing HL7 transmissions and their statuses. The
purge [HL PURGE TRANSMISSIONS] option purges all entries in the file that have been successfully transmitted
and, optionally, those entries with a status of ERROR IN TRANSMISSION.
To purge entries with an error status, run the [HL PURGE TRANSMISSIONS] option directly from the menu, and
answer YES at the "Purge entries that were not successfully transmitted?" prompt. Entries with an error status should
be reviewed before purging.
It is recommended that this option be queued to run once a day as a background task in order to automatically purge
entries that were successfully transmitted.
Figure: 3.3-11
3.3.10 IFR-Institution File Redesign
NOTE: Kernel is the designated custodial software application for the Institution File Redesign (IFR)-related software.
Kernel Patch XU*8.0*206 is designated as the primary Kernel patch for the IFR software.
Originally, the IFR software was released to the field as Kernel Patch XU*8.0*126 but was re-released and is
superseded by Kernel Patch XU*8.0*206. In addition, through the years subsequent IFR-related software patches
have been released in order to continually maintain and update the IFR software.
Master Files—What is the Problem?
In an open-architecture healthcare environment, there often exists a set of common reference files used by one or
more applications. These files are called "master files." The INSTITUTION (#4) and FACILITY TYPE (#4.1) files are
two examples of Veterans Health Information Systems and Technology Architecture (VistA) master files. With the
advent of VA-wide data exchange initiatives, such as Master Patient Index/Patient Demographics (MPI/PD), the need
to maintain reliable and accurate data within these master files across all Veterans Health Administration (VHA) sites
has become more apparent.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-268
6624
6625
6626
6627
6628
6629
6630
6631
6632
6633
6634
6635
6636
6637
6638
6639
6640
6641
6642
6643
6644
6645
6646
6647
6648
6649
6650
6651
6652
6653
6654
6655
Currently, the VHA does not automate updates and synchronization of national entries in standard master files
utilized VHA-wide. Each individual VHA site is responsible for updating and maintaining the INSTITUTION and
FACILITY TYPE master files located at their site. Through time and due to many unforeseen circumstances, these
master files no longer contain accurate, synchronized national data. Thus, there is a need to provide a mechanism to
automatically maintain reliable, accurate, and synchronized national data within the INSTITUTION and FACILITY
TYPE master files across all sites VHA-wide.
Purpose
The Institution File Redesign (IFR)-related software (i.e., Kernel Patch XU*8.0*206) provides the mechanism to
standardize national entries in VistA's INSTITUTION (#4) and FACILITY TYPE (#4.1) master files and automatically
update and maintain synchronization of these files at all sites VHA-wide. It also provides the baseline software to
maintain other master files in the future. Thus, Kernel Patch XU*8.0*206 ensures that the data in the INSTITUTION
and the FACILITY TYPE master files is reliable, accurate, and consistent VHA-wide. This allows sites to easily
establish data sharing relationships without the overhead of researching each other's INSTITUTION and FACILITY
TYPE file's data. This in turn ensures that future CIO initiatives involving multi-site data exchange will operate more
effectively and efficiently.
In addition, Kernel Patch XU*8.0*206 does not alter the currently existing procedures for the following:
• Requesting a New Station Number—The Information Management Service (045A4) will continue to approve the
official Station Numbers. Non-VA Institutions must receive a Station Number to be included in the Institution
Master File; VISN directors will continue to request new Station Numbers from the Chief Network Officer (10N).
• Austin Automation Center (AAC) Coordination Requirements—The coordination requirements currently placed
on sites by the Austin Automation Center (AAC) are not affected by this patch. The Institution Master File (IMF)
on FORUM will immediately be updated upon notification from the Information Management Service (045A4).
That updated data will then be immediately transmitted to all local INSTITUTION files (#4) VHA-wide via the
Master File Server (MFS). This patch does not require any additional coordination with the AAC. The same,
current procedures will be followed when the AAC has not yet updated its tables to include new Station Numbers
stored in the INSTITUTION file (#4).
• National Data Base Integration (NDBI) Procedures—NDBI will create new integrated sites after a new Station
Number has been added to the Institution Master File (IMF) on FORUM and that information has been
transmitted VHA-wide. Subsequent procedures followed by NDBI will remain the same.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-269
6656
6657
6658
6659
6660
6661
6662
6663
6664
6665
6666
6667
6668
6669
6670
6671
6672
6673
6674
6675
6676
6677
6678
6679
6680
6681
6682
6683
6684
Figure: 3.3-12
3.3.11 KAAJEE-Kernel Authentication & Authorization for Java 2 Enterprise Edition
The Kernel Authentication and Authorization for Java (2) Enterprise Edition (KAAJEE) software was developed by
Common Services Security Program.
Kernel is the designated custodial software application for KAAJEE; however, KAAJEE comprises multiple software
and patches from several HealtheVet-VistA applications.
KAAJEE is not an application but a framework. It provides secure sign-on architecture for HealtheVet-VistA Webbased applications. These HealtheVet-VistA Web-based applications are able to authenticating against Kernel on the
VistA M Server via an Internet Browser on the client workstation and a middle tier application server (e.g.,
WebLogic). KAAJEE is designed to run on the WebLogic 9.2 and higher.
KAAJEE addresses the Authentication and Authorization (AA) needs of HealtheVet-VistA Web-based applications in
the J2EE environment. Over the long term, the Department of Veterans Affairs (VA) wil
l provide AA services to perform end-user Authentication and Authorization enterprise wide; however, in the interim
period, OI has a choice to make as to which AA mechanism(s) would be the most effective. This applies both to the
needs of the applications themselves, as well as in anticipation of an expected migration to the future AA solution.
Most major J2EE application servers (e.g., WebLogic 9.2 and higher and Oracle's 10g) allow enterprises to override
the default source of AA and replace it with custom, enterprise-specific sources for AA.
KAAJEE authenticates against a VistA M Server first with Access and Verify codes via VistALink's AV connection
spec (i.e., KaajeeVistaLinkConnectionSpec). After the user has been properly authenticated against a VistA M
Server, KAAJEE dynamically creates a temporary username and password and populates this into a Structured
Query Language (SQL) database via custom Security Service Provider Interfaces (SSPIs). This username and
password is needed for the second level/phase/pass authentication for the J2EE container.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-270
6685
6686
6687
6688
6689
6690
6691
6692
6693
6694
6695
6696
6697
6698
6699
6700
6701
6702
6703
6704
6705
6706
6707
6708
6709
6710
6711
6712
6713
6714
6715
6716
6717
6718
6719
6720
6721
6722
6723
6724
6725
6726
6727
6728
Currently, Kernel maintains the primary VistA and HealtheVet-VistA user store (i.e., NEW PERSON file [#200]),
which provides both Authentication and Authorization (AA) services for all VistA and HealtheVet-VistA applications.
By leveraging Kernel, KAAJEE authenticates and authorizes J2EE Web users by using Kernel's AA capabilities.
Some potential advantages to employing Kernel as the AA source include the following:
• Provides a single point of user management for existing and new HealtheVet-VistA applications.
• Allows the use of an existing credential—the Access and Verify code—for Authentication and Authorization,
rather than introducing a new security credential.
• Eliminates the need to maintain a mapping from WebLogic accounts to VistA M Server Kernel accounts.
• Avoids an additional user store, which simplifies the migration to the future AA solution.
• Partitions user authorizations by Vete!
• rans Health Administration (VHA) site.
Some potential KAAJEE strategy limitations due to employing Kernel as the AA source include the following:
• Kernel user accounts are not currently VA-wide; instead, they are facility-specific.
• Users must have an active VistA M Server Kernel account on some VistA system. Not all users fit this
requirement (e.g., Veterans Affairs Central Office [VACO] users).
• This strategy introduces a dependency on the M system's availability, to perform virtually any function in a J2EE
application.
• Correlating a user at one VA facility with the same user at a different VA facility is not supported, given the
current lack of an enterprise-wide VA person identifier (e.g., VA-wide Person Identifier [VPID]).
REF: KAAJEE does not currently use the Department of Veterans Affairs Personal Identification (VPID), since this
field is not currently populated enterprise-wide.
The KAAJEE software provides a Kernel-based Authentication and Authorization (AA) service for all HealtheVetVistA Web-based applications in the J2EE/ WebLogic environment.
Features
KAAJEE provides the following high-level features and functionality:
• Prompts users to enter their Access and Verify code when he/she attempts to access a protected application
resource for the first time during a user session.
• Validates the entered Access and Verify code against the M system/division selected by the user at logon.
• Permits administrators to configure the display list of M systems, by division, against which an end-user can log
in.
• Returns all VistA M Server J2EE security keys and uses these as the basis for authorization decisions, as each
security key is cached as a WebLogic group name. The KAAJEE SSPIs currently use an external Oracle 10g
database to store this information for later authentication.
KAAJEE roles are defined by the list of roles in the web.xml file, VistA M Server J2EE security keys, and WebLogic
group name!
s found in your application's weblogic.xml file.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-271
6729
6730
6731
6732
6733
6734
6735
6736
6737
6738
6739
6740
6741
6742
6743
6744
6745
6746
6747
6748
6749
6750
6751
6752
6753
6754
6755
6756
6757
6758
6759
6760
6761
6762
6763
6764
6765
6766
6767
6768
6769
6770
6771
6772
REF: For more information on groups and roles, please refer to Chapter 5, "Role Design/Setup/Administration," in
this manual.
•
(optional) Maps J2EE security role names with security key role names. Through <security-role-assignment>
tags (e.g., in weblogic.xml) the actual J2EE security role names can be different than the security key role
names. This mapping is optional, because if the same names are used throughout, no <security-roleassignment> tags are required.
REF: For a sample spreadsheet showing a mapping between WebLogic group names (i.e., principals) with J2EE
security role names, please refer to "Appendix B—Mapping WebLogic Group Names with J2EE Security Role
Names" in this manual.
•
Transforms valid Access and Verify codes into a J2EE-compatible username (e.g.,
"kaaj_DUZ_8888~CMPSYS_523") and password, and submits the information to the J2EE container. It then
passes the submitted information to the KAAJEE SSPIs, which validate the username and makes that username
the current user.
Application developers can use the HttpServletRequest.getRemoteUser servlet method to return demographic data,
such as the KAAJEE-created username (e.g., "kaaj_DUZ_8888~CMPSYS_523").
REF: For more information on formatting J2EE usernames, please refer to the "J2EE Username Format" topic in
Chapter 7, "Programming Guidelines," in this manual.
•
•
Calls the KAAJEE SSPIs when the J2EE container checks user roles, which checks the role cache for the given
user, created at user login. This allows user authorizations to be managed on the VistA M Server, and yet have
fast response time in the J2EE application.
Provides user demographics information, which includes the selected Division at login, user VPID, user DUZ,
and user Name, all which are available to the application after login via the Session object (cookie).
REF: For more information on the user demographics provided, please refer to the following:
• "LoginUserInfoVO Object" topic in Chapter 7, "Programming Guidelines," in this manual.
• VistALink and the HealtheVet-VistA documentation can be downloaded from the VHA Software Document
Library (VDL) Web site:
• http://www.va.gov/vdl/
• Uses the SIGN-ON LOG file (#3.081) on the VistA M Server (i.e., the same M system used for user
authentication) to track user logons and logoffs.
REF: For more information on the SIGN-ON LOG file (#3.081), please refer to the Kernel Systems Management
Guide.
Security Service Provider Interfaces (SSPIs) can be used by developers and third-party vendors to develop security
providers for the WebLogic Server environment. SSPIs allow customers to use custom security providers for securing
WebLogic Server resources.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-272
6773
6774
6775
6776
6777
6778
6779
6780
6781
6782
6783
6784
6785
6786
6787
6788
6789
6790
6791
6792
6793
6794
6795
6796
6797
6798
6799
6800
Security providers are modules that "plug into" a WebLogic Server security realm to provide security services to
applications. They call into the WebLogic Security Framework on behalf of applications implementing the appropriate
SSPIs from the weblogic.security.spi package to create runtime classes for the security provider.
Some of the WebLogic security providers and utilities include (descriptions taken from WebLogic Website):
• WebLogic Authentication Provider—"Supports delegated username/password authentication, and utilizes an
embedded LDAP server to store, edit, and list user and group information." NOTE: KAAJEE (Iteration 1) does
not use WebLog
• ic's embedded LDAP server. It uses an Oracle 10g database to store users and groups by using SSPIs.
• WebLogic Identity Assertion Provider—"Supports certificate authentication using X.509 certificates."
• WebLogic Principal Validation Provider—"Signs and verifies the authenticity of a specific type of principal, much
as an Identity Assertion provider supports a specific type of token; therefore, you can use the WebLogic Principal
Validation provider to sign and verify principals that represent WebLogic Server users or WebLogic Server
groups."
• WebLogic Authorization Provider—"Supplies the default enforcement of authorization for this version of
WebLogic Server. Using a policy-based authorization engine, the WebLogic Authorization provider returns an
access decision to determine if a particular user is allowed access to a protected WebLogic resource."
• WebLogic Role Mapping Provider—"Determines dynamic roles for a specific user (subject) with respect to a
specific protected WebLogic resource for each of the default users and WebLogic resources."
• WebLogic Auditing Provider—"Records information from a number of security requests, which are determined
internally by the WebLogic Security Framework. The WebLogic Auditing provider also records the event data
associated with these security requests, and the outcome of the requests."
• WebLogic MBeanMaker Utility—This command-line utility takes an MBean Definition File (MDF) as input and
output files to generate an MBean type, which is used to configure and manage the security provider.
NOTE: For more information on the WebLogic security providers, utilities, and other related information, please visit
the following WebLogic Websites:
http://e-docs.bea.com/wls/docs92/secintro/archtect.html
http://e-docs.bea.com/wls/docs92/secintro/terms.html
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-273
6801
6802
6803
6804
6805
6806
6807
6808
6809
6810
6811
6812
6813
6814
6815
6816
6817
6818
6819
6820
Figure: 3.3-13
3.3.12 Kernel
Kernel is a vendor-independent applications development environment, as well as a run-time environment providing
standard vendor-independent services to applications software. It is not an operating system, but a set of utilities and
associated files that are executed in an M environment. Kernel is central to VA VistA software strategy, in that it
permits any VistA software application to run without modification on any hardware/software platform that supports
American National Standards Institute (ANSI) Standard M. All operating system-specific, M implementation-specific,
or hardware-specific code is isolated to Kernel. Therefore, porting VistA to a new environment requires modification
only to a handful of Kernel routines.
As a whole, Kernel provides a computing environment that permits controlled user access, presents menus for
choosing from various computing activities, allows device selection for output, enables the tasking of background
processes, and offers numerous tools for system management and application programming. Kernel also provides
tools for software distribution and installation.
VistA users see the same user interface, regardless of the underlying system architecture, because VistA
applications are built using Kernel facilities for signon, database access, option selection, and device selection. As a
result, user interaction with the system is constant across VistA applications.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-274
6821
6822
6823
6824
Figure: 3.3-14
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-275
6825
6826
6827
6828
6829
6830
6831
6832
6833
6834
6835
6836
6837
6838
6839
6840
6841
6842
6843
6844
3.3.13 KDC-Kernel Delphi Components
Kernel Components for Delphi v4.0, v5.0, v6.0
This version of the Kernel Delphi Components provides programmers with the capability to develop and deploy new
VISTA client/ server software using the Kernel Delphi Components in the 32-bit environment.
Please note that multiple installation procedures are provided in this guide. The Kernel Delphi Components have
separate installations for the following target environments:
• Programmer Client Workstations
• VISTA M Servers
Figure: 3.3-15
3.3.14 Kernel Toolkit
All Kernel Toolkit content will be moved to the appropriate Kernel manual, section, and chapter, except where noted
below. Toolkit resides on the Kernel's Systems Manager Menu [EVE]
All of the combined Kernel/Kernel Toolkit manuals and standalone Kernel/ Kernel Toolkit manuals will now be located
on the VDL under "Kernel" at the following Web address: http://www.va.gov/vdl/application.asp?appid=10
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-276
6845
6846
6847
6848
6849
6850
6851
6852
6853
6854
6855
6856
6857
6858
6859
6860
6861
6862
6863
6864
6865
6866
6867
6868
6869
6870
6871
6872
6873
6874
6875
6876
6877
6878
6879
6880
6881
6882
6883
6884
6885
6886
The Kernel Toolkit is a robust set of tools developed to aid the Decentralized Hospital Computer Program (DHCP)
development community and Information Resources Management (IRM) in writing, testing, and analysis of code. It is
a set of generic tools that are used by developers, documenters, verifiers, and packages to support distinct tasks.
The Kernel Toolkit provides utilities for the management and definition of development projects. Many of these
utilities have been used by the San Francisco Information Systems Center (ISC) for internal management and have
proven valuable. Kernel Toolkit provides many programming and system management tools, and interacts directly
with the underlying MUMPS (Massachusetts General Hospital Utility Multi-Programming System) environment in
many different ways.
Also included in Kernel Toolkit are the following tools provided by other ISCs, and supported by the San Francisco
ISC, based on their proven utility:
 Multi-Term Look-Up (MTLU){ XE "Multi-Term Look-Up (MTLU)" }:
 Duplicate Resolution Utilities{ XE "Duplicate Resolution Utilities," }:
The Parameter Tools patch (XT*7.3*26) provides a method of managing the definition, assignment, and retrieval of
parameters for VistA software applications.
VistA software applications are designed to be used in a variety of ways. Many aspects of hospital activity vary from
one hospital to another and thus there are many possible ways software applications can be used that also vary from
one institution to another. Each site has its own requirements—its own settings for each software application. IRM
staff must modify the software parameters to fit their requirements.
Previously, each software application had its own files and options but no two software applications had the site
parameters set up the same way or found in the same place. Thus, when a new software application was released,
each site would have to look for the location where the settings were stored for that software. Next, they would have
to look to see what settings were available and how to set them. Very little about the parameters was uniform from
software to software.
With the Computerized Patient Record System (CPRS) software, the idea was born that a parameter file could be
created to export with the software. The CPRS parameter file and parameter utility were subsequently modified to
create a generic method of exporting and installing other VistA software applications. Most developers were willing to
abandon previous methods and use this tool for software they were developing.
Parameter Tools was designed as a method of managing the definition, assignment, and retrieval of parameters for
VistA software. A parameter may be defined for various levels at which you want to allow the parameter described
(e.g., software level, system level, division level, location level, user level).
Patch XT*7.3*26 contains a developer toolset that allows creation of software parameters in a central location.
Integration Agreements (IAs) 2263 and 2336 define the supported entry points for this application. Kernel Patch
XU*8.0*201 allows KIDS to transport the parameters.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-277
6887
6888
6889
6890
6891
6892
6893
6894
6895
6896
6897
6898
6899
6900
6901
6902
6903
6904
6905
6906
6907
VistA Patch Monitor is being released in Kernel Toolkit Patch XT*7.3*98. This package is designed to assist package
support and management personnel in keeping up with VistA patch requirements. It monitors patches as they arrive
in the VistA MailMan, records pertinent data and then monitors them on a daily basis through automated processing.
This package will track only patches that are released from the National Patch Module on Forum. It will not track
Class III patches, test patches or hand-entered patches from other sources due to its link with the Kernel Installation
and Distribution System (KIDS) INSTALL file (#9.7).
Figure: 3.3-16
3.3.15 Kernel Unwinder
The Unwinder is a utility that is used in conjunction with the Protocol file (#101) to create modular building blocks for
applications.
The Unwinder allows hierarchical traversing of menus, as found in Menu Management, and also the structuring of
order protocols into independent, reusable modules. Each node becomes a "building block" from which more
sophisticated modules may be built. For instance, the node "Order Shirt" may have as sub-items, "Get Size," "Get
Color," "Get Style," and "Get Delivery Date." Each of these sub-items may, in turn, be used to build other modules.
Provisions have been made to allow additional building blocks to be placed at the item level of the node. Their
purpose is to allow modifying actions to be executed and thus increase the flexibility of each module.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-278
6908
6909
6910
6911
6912
6913
6914
6915
6916
6917
6918
6919
6920
6921
6922
Figure: 3.3-17
3.3.16 List Manager
List Manager was originally developed as an interface for the Scheduling module of DHCP's MAS V. 5.2 package.
Since then it has been used as an interface for a number of other applications, including Text Integration Utility and
NOIS (National Online Information Sharing).
Core Functions
List Manager provides a generic method of presenting lists of items to terminal users. Its core functions are:
• Display a list of items.
• Users can browse through the list.
• Users can select one or more items from the list.
• Users can execute an action for selected list items.
• You can use List Manager recursively within an action.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-279
6923
6924
6925
6926
Figure: 3.3-18
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-280
6927
6928
6929
6930
6931
6932
6933
6934
6935
6936
6937
6938
6939
6940
6941
6942
6943
6944
6945
6946
6947
6948
6949
6950
6951
6952
6953
6954
6955
6956
6957
6958
6959
6960
6961
6962
6963
6964
6965
6966
6967
6968
6969
6970
3.3.17 M-to-M Broker
The VistA M-to-M Broker is a new implementation of the RPC Broker offering Client/ Server functionality resident
solely within a VistA non-Graphical User Interface (GUI) environment. It enables the exchange of VistA M-based data
and business rules between two VistA M servers, where both servers reside on local and/or remote VistA systems:
• The requesting server functions in the capacity of a Client.
• The server receiving that request functions in the capacity of a Server.
The Client/ Server roles of each server can vary depending on what point in time each VistA M server is making the
request for data from its counterpart VistA M server.
All M-to-M Broker client and server routines are packaged in one KIDS build, Patch XWB*1.1*34, which will need to
be installed on all VistA systems required for M-to-M Broker processing.
Scope
The M-to-M Broker provides a new implementation of the RPC Broker enabling the exchange of VistA M-based data
and business rules between two VistA M servers, where both servers reside on the same, or on different VistA M
systems.
For the VistA Imaging Digital Imaging and Communication in Medicine (DICOM) Gateway, the M applications on
separate VistA systems will be converted to use this new M-to-M Broker software to communicate to the main VistA
Hospital Information System (HIS). This eliminates the need for Distributed Data Processing (DDP).
Background
VistA Imaging requested the development of the M-to-M Broker to be used to communicate between the M client on
the VistA Imaging DICOM Gateway and the M server on the main HIS.
The VistA Imaging DICOM Gateway architecture uses M software on a workstation to create associations between
newly acquired images and computerized patient records. Before the development of the M-to-M Broker, the gateway
system communicated with the main Hospital Information System using the DDP protocol, stored the acquired
images on Microsoft Operating System (NT) file servers, and set database entries to reference them.
Problems with DDP (Distributed Data Processing):
• Causes database inconsistencies
• Lacks security
• Bound to MAC addresses
• Responds slow on a busy Hospital Information System and/or network
• Runs very slowly in a Wide Area Network (WAN) environment because of inherent network latencies
WARNING: Because of the database inconsistency problem, incidents of matching images to the wrong patient
occurred at one particular site.
DDP provides no security. M-to-M Broker uses many of the robust security features implemented by the VistA RPC
Broker and Kernel software. These security features are transparent to the end-user and without additional impact on
Information Resources Management (IRM).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-281
6971
6972
6973
6974
6975
6976
6977
6978
6979
6980
6981
6982
6983
6984
6985
6986
6987
6988
6989
6990
6991
6992
6993
6994
6995
6996
6997
6998
6999
7000
About the Remote Procedure Call (RPC) Broker
The RPC Broker (also referred to as "Broker") is a Client/Server system within VA's Veterans Health Information
Systems and Technology Architecture (VistA) environment. It establishes a common and consistent foundation for
Client/Server applications being written as part of VistA. It enables client applications to communicate and exchange
data with M Servers.
The RPC Broker is a bridge connecting the client application front-end on the workstation (e.g., Delphi GUI
applications) to the VistA M-based data and business rules on the server. It links one part of a program running on a
workstation to its counterpart on the server.
INFORMATION: For information on the RPC Broker, documentation is made available online in Adobe Acrobat
Portable
Document
Format
(PDF)
at
the
following
Web
address:
http://vaww.vista.med.va.gov/vdl/Infrastructure.asp#App23 .
Figure: 3.3-19
3.3.18 MailMan
NOTE: Installation of MailMan v8.0 requires that a site already have MailMan v7.1 installed and running, and that it is
fully patched through at least MailMan Patch XM*7.1*198.
MailMan has many documented Application Program Interfaces (APIs). In addition to the "classic" APIs, additional
APIs have been created to support other front ends to MailMan (e.g., a Graphical User Interface [GUI]). Where
possible, existing MailMan code has been altered to use the latest APIs.
MailMan, the Department of Veterans Affairs (VA) electronic mail system, is a communications tool that provides
electronic communication among users sharing computing facilities. A communications link can be made with cables,
telephone lines, or satellite connections. In this manner, the networking of electronic mail on a large scale is made
possible.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-282
7001
7002
7003
7004
7005
7006
7007
7008
7009
7010
7011
7012
7013
7014
7015
7016
7017
7018
7019
7020
7021
7022
7023
7024
7025
7026
7027
7028
7029
7030
7031
7032
MailMan provides teleconferencing via chained responses. MailMan is the transport vehicle for most VistA
applications. MailMan is also used to preserve copies of software and data. MailMan also has the ability to include
non-textual data in messages (i.e., Multimedia). Network features allow users to construct dialogues for logging onto
remote systems for mail delivery. Message actions allow users great flexibility in managing personal mail. Users can
address mail to individuals and groups at local and remote sites, with the tedium of waiting for process completion
being reduced by the system's background filer. In addition, the system has extensive online documentation, which
can be printed to create a manual.
MailMan is designed to allow users to send and receive mail from individuals or groups. A message can take the
form of a personal letter or a formal bulletin extracting data from VA FileMan. The text of messages is not difficult to
edit, and the context can be made confidential in several ways. Surrogates can be appointed to read mail. Mail
groups can be set up to allow each member to respond to a message and to view the replies, as in an informal
committee meeting. Mail can be sorted, deleted, forwarded, queried, copied, revised, or printed. In addition, MailMan
cross-references messages by subject and message number.
MailMan allows users to send, receive, copy, respond to, and organize electronic mail. It has entry points to allow
other applications to trigger bulletins or send messages without user intervention. There is a communications facility
(i.e., TalkMan) to allow users to automatically hook into the VA Wide Area Network(WAN) or modems. This feature
connects the user to a remote domain, playing the script to that domain without displaying it to the user. It then
informs the user that the connection was successful, and can capture whatever has been displayed to the user's
terminal into a message called DIALOGUE CAPTURE.
An extended search for messages can be invoked at the "Message Action" prompt or as a stand-alone option. The
extended search includes filters on the subject, sender, recipient, responder, the date sent, and text contents.
MailMan informs users of network delivery failures and their causes. Message characteristics including Closed,
Confidential, Confirmation Requests, Information, and Scrambling can be carried across the network. Software
security information for PackMan can also be conveyed on the network.
MailMan allows the transfer of any word-processing text from any VA FileMan file or message into a message or
response. New documents are placed in a user's "IN" basket or to any other designated basket (e.g., based on mail
filters).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-283
7033
7034
7035
7036
7037
7038
7039
7040
7041
7042
7043
7044
7045
7046
7047
7048
7049
7050
7051
7052
7053
7054
7055
7056
7057
7058
7059
Figure: 3.3-20
3.3.19 MPI-Master Patient Index
Master Patient Index/ Patient Demographics (MPI/PD) was developed to initialize active patients to the Master
Patient Index (MPI) and to establish the framework for the sharing of patient information between sites. During the
process of initialization to the Master Patient Index, each active patient received:
• An Integration Control Number (ICN)
• A Coordinating Master of Record (CMOR)
• A Treating Facility List of sites where the patient is also known by this ICN
Each site becomes part of the network of sites that share key demographic data for patients via HL7 messaging.
Master Patient Index VistA (MPI) and Patient Demographics (PD) were distributed and installed together. This
manual covers the functionality of both packages.
The objectives of the MPI/PD VistA are to:
• Create an index that uniquely identifies each active patient treated by the Veterans Administration.
• Identify the sites where a patient is receiving care.
This is crucial to the sharing of patient information across sites.
Master Patient Index Patch MPI*1*40 constituted a change in the business process that updates the patient identity
fields across VA facilities. Patch MPI*1*40 phased out the use of the facility Coordinating Master of Record (CMOR)
concept, and introduced the Primary View methodology. Primary View is an enterprise view of the most current data
for a patient based on authority scoring and the latest data rules.
History
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-284
7060
7061
7062
7063
7064
7065
7066
7067
7068
7069
7070
7071
7072
7073
7074
7075
7076
7077
7078
7079
7080
7081
7082
7083
7084
7085
7086
7087
7088
7089
7090
7091
7092
7093
7094
7095
7096
7097
7098
7099
7100
7101
7102
7103
MPI/PD was originally part of the Clinical Information Resource Network (CIRN) project. CIRN was to be a threephase project consisting of Phase 1: Pre Implementation (site cleanup), Phase 2: Master Patient Index/Patient
Demographics (Master Patient Index seeding for VHA-wide patient identification and patient demographics
synchronization), and Phase 3: CIRN Clinical Repository. Master Patient Index/Patient Demographics is now a
separate, independent package. Due to its beginnings, you will still notice references to CIRN (e.g., shared name
and number spaces, file names, package terminology, etc.). The clinical repository is now a separate, independent
project called Health Data Repository (HDR).
Distinguishing MPI (Austin) from MPI/PD (VistA)
MPI (Austin) refers to the actual index located at the Corporate Data Center Operations (CDCO). MPI/PD (VistA)
refers to the software that resides in VistA at sites and sends patient data to the MPI (Austin) and to other sites where
a patient has been seen. These terms i.e., MPI (Austin) and MPI/PD (VistA) are used throughout this manual only
when it is not obvious to which component of the MPI the documentation is referring. Otherwise, the reader should
assume the information is referring to MPI/PD (VistA).
Master Patient Index (Austin)
The Master Patient Index (MPI) is located at the Austin Information Technology Center (AITC). It is composed of a
unique list of patients and an associated list of VAMCs (Veterans Affairs Medical Centers) and other systems of
interest where each patient has been seen. This enables the sharing of patient data between operationally diverse
systems. Each patient record (or index entry) on the MPI contains multiple demographic fields which are updated to
the Primary View of the MPI.
When a patient is first presented into the MPI for an Integration Control Number (ICN) assignment, that patient's
identifying information (i.e., name, Social Security Number (SSN), date of birth, gender, mother's maiden name,
multiple birth indicator, place of birth city and state) is passed to the MPI.
The MPI checks to see if an exact match on Name (first and last), SSN, date of birth, and gender is found. A check is
also made to see if the patient's internal entry number (DFN) from the querying site is already known to the MPI. If
so, this is also considered an exact match. If an exact match is found, the ICN, and ICN Checksum are returned to
the requesting site. The requesting site is added to the list of treating facilities (TF) in which this patient has been
seen and the updated list is broadcasted to all systems of interest, including VAMCs.
If an exact match is not found, the MPI returns a message indicating this. The patient entry is then added to the MPI.
If a potential match is found, a potential match exception is logged for the HC IdM group to review, the patient is still
added to the MPI.
NOTE: The term "systems of interest" refers to VA facilities that have seen patients and entered them as entries onto
the MPI. This also refers to non-VistA systems that have a registered interest in a patient (e.g., Federal Health
Information Exchange [FHIE], HomeTeleHealth, Person Service Identity Management [PSIM], Health Data
Repository [HDR], etc).
HC IdM Team is Data Steward for the Master Patient Index (MPI)
The Healthcare Identity Management (HC IdM) team is the Data Steward for the Master Patient Index (MPI). They
have the ability to perform the following functions on the Primary View of the MPI:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-285
7104
7105
7106
7107
7108
7109
7110
7111
7112
7113
7114
7115
7116
7117
7118
7119
7120
7121
7122
7123
7124
7125
7126
7127
7128
7129
7130
7131
7132
7133
7134
7135
7136
7137
7138
7139
7140
7141
7142
7143
7144
7145
7146
7147
•
•
•
View and/or edit the authority values for the Primary View business rules criterion.
Override Primary View identity traits for selected identity fields in the MPI VETERAN/CLIENT file (#985) and
broadcast the new Primary View out to the systems of interest.
View the Primary View Reject Report from the data in the MPI REJECTED UPDATE file (#985.65).
NOTE: For a list of the fields stored on the MPI, see the section titled: "Appendix B: Data Stored on the MPI in
Austin" in this documentation.
Master Patient Index/Patient Demographics (VistA)
The Master Patient Index/Patient Demographics (MPI/PD) software resides in VistA enabling sites to:
• Request an ICN assignment.
• Resolve a potential duplicate on the MPI.
• Review and process exceptions received from MPI including Primary View Reject exceptions.
• Query the MPI (Austin) for known data.
• Update the MPI when changes occur to demographic fields stored on the MPI or of interest to other
facilities/systems of interest.
Distinguishing MPI (Austin) from MPI/PD (VistA)
MPI (Austin) refers to the actual index located at the Corporate Data Center Operations (CDCO). MPI/PD (VistA)
refers to the software that resides in VistA at sites and sends patient data to the MPI (Austin) and to other sites where
a patient has been seen. These terms i.e., MPI (Austin) and MPI/PD (VistA) are used throughout this manual only
when it is not obvious to which component of the MPI the documentation is referring. Otherwise, the reader should
assume the information is referring to MPI/PD (VistA).
Master Patient Index (Austin)
The Master Patient Index (MPI) is located at the Austin Information Technology Center (AITC). It is composed of a
unique list of patients and an associated list of VAMCs (Veterans Affairs Medical Centers) and other systems of
interest where each patient has been seen. This enables the sharing of patient data between operationally diverse
systems. Each patient record (or index entry) on the MPI contains multiple demographic fields which are updated to
the Primary View of the MPI.
When a patient is first presented into the MPI for an Integration Control Number (ICN) assignment, that patient's
identifying information (i.e., name, Social Security Number (SSN), date of birth, gender, mother's maiden name,
multiple birth indicator, place of birth city and state) is passed to the MPI.
The MPI checks to see if an exact match on Name (first and last), SSN, date of birth, and gender is found. A check is
also made to see if the patient's internal entry number (DFN) from the querying site is already known to the MPI. If
so, this is also considered an exact match. If an exact match is found, the ICN, and ICN Checksum are returned to
the requesting site. The requesting site is added to the list of treating facilities (TF) in which this patient has been
seen and the updated list is broadcasted to all systems of interest, including VAMCs.
If an exact match is not found, the MPI returns a message indicating this. The patient entry is then added to the MPI.
If a potential match is found, a potential match exception is logged for the HC IdM group to review, the patient is still
added to the MPI.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-286
7148
7149
7150
7151
7152
7153
7154
7155
7156
7157
7158
7159
7160
7161
7162
7163
NOTE: The term "systems of interest" refers to VA facilities that have seen patients and entered them as entries onto
the MPI. This also refers to non-VistA systems that have a registered interest in a patient (e.g., Federal Health
Information Exchange [FHIE], HomeTeleHealth, Person Service Identity Management [PSIM], Health Data
Repository [HDR], etc).
HC IdM Team is Data Steward for the Master Patient Index (MPI)
The Healthcare Identity Management (HC IdM) team is the Data Steward for the Master Patient Index (MPI). They
have the ability to perform the following functions on the Primary View of the MPI:
• View and/or edit the authority values for the Primary View business rules criterion.
• Override Primary View identity traits for selected identity fields in the MPI VETERAN/CLIENT file (#985) and
broadcast the new Primary View out to the systems of interest.
• View the Primary View Reject Report from the data in the MPI REJECTED UPDATE file (#985.65).
NOTE: For a list of the fields stored on the MPI, see the section titled: "Appendix B: Data Stored on the MPI in
Austin" in this documentation.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-287
7164
7165
7166
7167
7168
Figure: 3.3-21
3.3.20 MDWS-Medical Domain Web Services
There are no documents for this application at this point. (As of: October 30, 2009)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-288
7169
7170
7171
7172
7173
7174
7175
7176
7177
7178
7179
7180
7181
7182
7183
7184
7185
7186
7187
7188
Figure: 3.3-22
3.3.21 Name Standardization
The Name Standardization (Patch XU*8.0*134) provides utilities that enable VISTA applications to standardize the
way person names are entered and stored in Veterans Health Administration (VHA) databases.
Features
The Name Standardization release (Patch XU*8.0*134) features:
• A standard format for person names in VISTA.
• The data conversion of the NEW PERSON file (#200).
• A new NAME COMPONENTS file (#20).
• Changes to the data dictionary of the NEW PERSON file.
• Changes to Kernel options that allow editing of individual name components.
• New Application Programming Interfaces (API)s.
• A new VA FileMan FUNCTION to display names in various formats.
Patch Designation(s): A4A7*1.01*11
Description: Remove the DD and data for Files #3, #6, #16, and #20, and the x-refs in File #200 that set data into
them.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-289
7189
7190
7191
7192
Figure: 3.3-23
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-290
7193
7194
7195
7196
7197
7198
7199
7200
7201
7202
7203
7204
7205
7206
7207
7208
7209
7210
7211
3.3.22 NOIS-National Online Information Sharing
Used to track requests for service. It is used on Forum and can be implemented for local use. NOIS can be used as
only an M application or as a client/server application with M as the server and Windows as the client.
Figure: 3.3-24
3.3.23 National Patch Module
The National Patch Module (NPM) is a software package that provides a database for the distribution of software
patches and updates for the Department of Veterans Affairs' Decentralized Hospital Computer Program (DHCP).
Options are provided for systematic entry and review of patches by developers, review and release of patches by
verifiers, and display and distribution of the released verified patches to the users.
Once a problem is found in DHCP software and the solution identified, a developer enters a patch in the NPM
identified by package namespace, version, and a patch number. At this point, the patch entry has a status of "under
development" and is accessible only by other developers of the package. When the patch is completed and ready for
review, a second developer changes the status to "completed/unverified" and the patch becomes available for review
by designated verifiers of the package. After the verifier(s) have checked the patch and determined that it is ready for
release, the status is changed to "verified". The patch is automatically distributed and becomes available for display
by users.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-291
7212
7213
7214
7215
7216
7217
7218
7219
7220
7221
7222
7223
7224
7225
7226
7227
7228
7229
7230
7231
7232
7233
7234
7235
7236
Figure: 3.3-25
3.3.24 NHE-Network Health Exchange
Network Health Exchange (NHE) Version 5.1, a component of the Department of Veterans Affairs (VA) Veterans
Health Information Systems and Technology Architecture (VistA), is software that allows Veterans Affairs Medical
Centers (VAMC)s to request either complete or pharmacy patient Health Summaries from each other. NHE was
created by the Chicago Westside VAMC. This software is being released as an interim bridge to a more fully
integrated clinical patient data exchange system.
Network Health Exchange (NHE) was developed at the Chicago Westside Veterans Affairs Medical Center (VAMC)
and has evolved over several iterations. The Network Health Exchange is VistA software that provides clinicians with
quick and easy access to patients' information from any site where they have been treated. NHE provides the
computer mechanism for VAMC clinicians to retrieve clinical patient data from other medical centers. The requester
is notified of returned patient data through an alert that appears with the VistA menu system. Patient data is
displayed in a format similar to the integrated clinical reports found in Health Summary and can be viewed onscreen
or printed.
The NHE software accesses several other VistA files which contain information concerning diagnoses, prescriptions,
laboratory tests, radiology exams, hospital admissions, and clinic visits. This allows a clinical staff to take advantage
of clinical data supported through VistA.
Network Health Exchange is based on the Health Summary software. However, NHE does not make calls to Health
Summary so it is not necessary for a site to install Health Summary nor is familiarity with Health Summary required in
order to use NHE.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-292
7237
7238
7239
7240
7241
7242
7243
7244
7245
7246
7247
7248
7249
7250
7251
7252
7253
7254
7255
7256
7257
7258
7259
7260
7261
7262
7263
Figure: 3.3-26
3.3.25 PDX-Patient Data Exchange
The Patient Data Exchange (PDX) software is designed to manage the transfer of patient information (demographics,
episodes of care, medications, and diagnostic evaluations) between VA facilities using the MailMan electronic mail
utility. Once transferred, this information may be combined with pertinent local information and assembled into a
coherent composite record.
To which VistA Allergy Tracking application this is referring is not known. Identified in PDX-Patient Data Exchange
Technical Manual, Section 7, External/ Internal Relations in listing of, "minimum software versions or higher are
required in order to install this version of PDX."
Requests for PDX data can be processed manually or automatically. For requests to be processed manually, the site
would have to be a member of the Release Group and meet the requirements for automatic processing. Records
determined to be "sensitive" and those which exceed the maximum time and occurrence limits for Health Summary
components may not be returned automatically and will be held for manual processing.
PDX V. 1.5 uses the List Manager utility extensively. The List Manager is a tool designed to display a list of items. It
allows you to select items from the list and perform specific actions against those items.
The software provides numerous system reports (current transactions and work- load) that allow predefined and
customizable sorts.
The Following is a brief description of the major options and menus contained in the PDX software:
• Request PDX for Patient—This option is used to electronically request PDX data for a selected patient from
another VA facility(s).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-293
7264
7265
7266
7267
7268
7269
7270
7271
7272
7273
7274
7275
7276
7277
7278
7279
7280
7281
7282
7283
7284
7285
7286
7287
7288
7289
7290
7291
7292
Unsolicited PDX—This option is used to send PDX information to a remote site without having first received a
request.
• Process External PDX—This option is used to process PDX requests received from other VA facilities that do
not meet the criteria for automatic processing.
• Load/Edit PDX Data—This option allows you to load or edit data fields in your PATIENT file with data from your
PDX file.
• Display PDX Data Menu—This menu allows you to display or print PDX data for a selected patient by either
transaction or user who requested the information.
• System Reports Menu:
 Requires Processing Report—This option is used to print a report of all PDX requests that require
manual processing.
 Current Transactions Report Menu—The options on this menu allow you to print reports of PDX
transactions on file by several different sorting methods.
 Workload Reports Menu—The options on this menu allow you to print workload reports of PDX
transactions on file by several different sorting methods.
• PDX Edit Files Menu:
 Add/Edit Fields to Encrypt—This option provides the ability to encrypt selected data fields in the PDX
transmission.
 Edit Maximum Limits for Automatic Processing—This option is used to edit the maximum time and
occurrence limits that your site is willing to allow for automatic processing of a PDX transaction.
 Add/Edit Outgoing Group—This option is used to create outgoing groups and add/edit/delete remote
facilities in those groups.
 Edit Parameter File—This option is used to set up site specific PDX parameters.
 Add/Edit Segment Group Options—These three options are used to create segment groups (selected
group of data segments).
 Add/Edit Release Group—This option is used to enter/edit facilities into the release group for automatic
processing of PDX requests.
• Purging Menu—These three options provide purging capabilities by default age, user defined age, or user defined
date.
•
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-294
7293
7294
7295
7296
7297
7298
7299
7300
7301
7302
7303
7304
7305
7306
7307
7308
7309
7310
7311
7312
7313
7314
7315
7316
7317
Figure: 3.3-27
3.3.26 RPC-Remote Procedure Call Broker
The RPC Broker is considered to be part of the infrastructure of VistA. It establishes a common and consistent
foundation for communication between clients and VistA M Servers.
The RPC Broker is a bridge connecting the client application front-end on the workstation (e.g., Delphi GUI
applications) to the M-based data and business rules on the server. It links one part of a program running on a
workstation to its counterpart on the server. The client and the server can be, and most often are, written in different
computer languages. Therefore, the RPC Broker bridges the gap between the traditionally proprietary VistA and
COTS/HOST products.
The RPC Broker includes:
• A common communications driver for the M server interface that handles the device-specific characteristics of
the supported communications protocol.
• An interface component on the M server, separate from the communications driver, that interprets client
messages, executes the required code, and eventually returns data to the communications driver.
• A common file on the M server that all applications use to store the information about the queries to which they
respond (i.e., REMOTE PROCEDURE file [#8994]).
• The Client Agent application that runs on client workstations, supporting single signon.
• The TRPCBroker component for Delphi, enabling development of client applications that can communicate via
the RPC Broker.
• A dynamic link library (DLL) that provides access to RPC Broker functionality for development environments
other than Delphi.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-295
7318
7319
7320
7321
7322
7323
7324
7325
7326
7327
7328
7329
7330
7331
7332
7333
7334
7335
7336
7337
7338
7339
7340
7341
7342
7343
7344
Figure: 3.3-28
3.3.27 Resource Usage Monitor
The Resource Usage Monitor (RUM) software is a fully automated support tool developed by Capacity Planning (CP)
Services. It entails the capture of all system and VistA option workload specifics from participating sites. This
workload data is then summarized on a weekly basis and is automatically transferred via network mail (i.e., MailMan)
to the Capacity Planning National Database.
The Veterans Health Administration (VHA) developed the Resource Usage Monitor (RUM) software in order to obtain
more accurate information regarding the current and future VistA system and option workload at the VA Medical
Centers (VAMCs).
Installing the RUM software creates the collection process mechanism and other necessary components of the
software. The fully automated data collection mechanism entails capturing all system and VistA option workload
specifics at the site into a temporary ^KMPTMP("KMPR") temporary collection global. The collection mechanism is
continuously monitoring each process on the system while trapping system and VistA option workload data.
On a nightly basis, the RUM Background Driver option [KMPR BACKGROUND DRIVER] moves the data within the
^KMPTMP("KMPR") temporary collection global to the RESOURCE USAGE MONITOR file (#8971.1). Upon
completion, the data within the ^KMPTMP("KMPR") temporary collection global is purged.
Every Sunday night, the RUM Background Driver option [KMPR BACKGROUND DRIVER] monitors the RESOURCE
USAGE MONITOR file to ensure that only a maximum of three weeks worth of data is maintained at the site.
Also, each Sunday night, the RUM Background Driver option automatically compresses the information contained
within the RESOURCE USAGE MONITOR file (#8971.1) into weekly statistics. These weekly statistics are converted
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-296
7345
7346
7347
7348
7349
7350
7351
7352
7353
7354
7355
7356
7357
7358
7359
7360
7361
7362
7363
7364
7365
7366
into an electronic mail message that is automatically transferred via network mail (i.e., VistA MailMan) and merged
into a Capacity Planning National Database where this data is used for evaluation purposes. The site also receives a
summary of the system workload data in the form of an electronic turn-around message.
Figure: 3.3-29
3.3.28 SSO/UC-Single Signon/User Context
SSO/UC is not an application but a framework. Users of the software need to understand how it integrates in their
working environment. Thus, installing SSO/UC means to understand what jars and files need to be put where and
what are the configuration files that you need to have and edit.
SSO/UC provides a secure signon architecture for Vista client/ server-based applications. For example:
• Care Management
• Computerized Patient Record System-Rehosted (CPRS)
• Vitals
These VistA client/server-based applications are able to authenticating against Kernel on the VistA M Server via an
application graphical user interface (GUI) on the client workstation.
Kernel (i.e., Kernel Patch XU*8.0*337) is the designated custodial software package of the Infrastructure & Security
Services (ISS) SSO/UC and related software. However, SSO/UC comprises/ depends on multiple patches and
software releases from several VistA/HealtheVet-VistA applications.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-297
7367
7368
7369
7370
7371
7372
7373
7374
7375
7376
7377
7378
7379
7380
7381
7382
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
7395
7396
Figure: 3.3-30
3.3.29 SlotMaster (Kernel ZSLOT)
Slotmaster is a quick login utility for VMS systems. SlotMaster is a combination of items which include DCL
procedures and MUMPS routines. It utilizes a feature available under VMS LAT known as dedicated LAT ports where
an application can be dedicated to a specific LAT device. Slotmaster saves users time by letting the user connect
directly to an active M partition. This saves users from sitting through VMS process creation and loading an M
partition, allowing them to log in to DHCP directly.
Slotmaster also conserves system resources by re-using the same VMS process for new users, rather than creating
a new process for each new user.
Only "DETACH" mode of SlotMaster supported.
How SlotMaster Works
SlotMaster is a combination of DCL command procedures and M routines. It uses a feature available under
OpenVMS LAT known as dedicated LAT ports. With dedicated LAT ports, an application can be dedicated to a set of
specific LAT devices.
With SlotMaster, the user connects to a service that is a set of dedicated LAT ports that are connected to already
running ZSLOT0 DSM jobs waiting to call the Kernel's sign-on. This keeps the user and the system from having to go
through process creation and image activation at the time of login to DHCP applications.
SlotMaster Process
The system manager starts up SlotMaster on a given node using the STARTUP$ZSLOT.COM command file. This
command file creates a set of custom files and submits them to a VMS queue. These files start up the set of slot
processes for the node, plus one instance of a controller process, called SlotMaster, that manages the set of slots.
The SlotMaster process scans the set of slots for the current node, restarts processes that have been force-exited or
have otherwise disappeared, and collects usage statistics for reference.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-298
7397
7398
7399
7400
7401
7402
7403
7404
7405
7406
7407
7408
7409
7410
7411
7412
7413
7414
7415
7416
7417
7418
7419
7420
7421
7422
7423
Figure: 3.3-31
3.3.30 SQLI-SQL Interface
VistA's SQLI software product (part of VA FileMan), along with an M-to-SQL Product purchased from a vendor (see
below), provides SQL access to your VA FileMan data.
From an operational point of view, VA FileMan is a hierarchical database, because it supports multiples (nested
tables). However, the nature of VA FileMan's underlying file and data dictionary structures allow its files and multiples
to be viewed as relational tables as well.
M-to-SQL vendors have provided relational access to VA FileMan data in the past by scanning VA FileMan's internal
data dictionary structures, and interpreting the information found there to provide a relational view of the underlying
data.
SQLI software (i.e., VA FileMan Patch DI*21.0*38) insulates the M-to-SQL vendors from direct access to VA
FileMan's internal data dictionaries by projecting all information needed for a relational view of VA FileMan in a
supported manner. Instead of accessing internal data dictionary structures, M-to-SQL vendors need only scan the
SQLI's projection to build their relational view of VA FileMan data.
Why Map VA FileMan to SQL?
SQL (Structured Query Language) is the predominant language and set of facilities for working with relational tables.
The reason to access VA FileMan data through SQL is to take advantage of features provided both by SQL and by
Commercial Off-the-Shelf (COTS) software. For example, if a vendor's M-to-SQL product can act as an ODBC data
source, this provides direct access to VA FileMan data for ODBC-enabled Windows software!
Some ways you can work with VA FileMan data using an M-to-SQL product include:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-299
7424
7425
7426
7427
7428
7429
7430
7431
7432
7433
7434
7435
7436
7437
7438
7439
7440
7441
7442
7443
7444
7445
7446
7447
7448
7449
7450
7451
7452
7453
7454
7455
7456
7457
7458
7459
7460
7461
7462
7463
7464
7465
7466
7467
•
•
•
Query VA FileMan data through SQL.
Manipulate VA FileMan data in Open Database Connectivity (ODBC) aware applications. This is possible if the
M-to-SQL product can act as an ODBC data source. In this case, VA FileMan data can be accessed and
manipulated by ODBC-compatible applications (e.g., Access, Excel, ReportSmith, Crystal Reports, etc.).
Make VA FileMan data accessible over an Intranet or the Internet using an ODBC-aware Web server.
What Other Software is Required to View VA FileMan Data Through SQL?
To enable SQL access to VA FileMan data at your site, you need to purchase an M-to-SQL product (software that
can view structured M globals as relational tables through SQL).
Components of an M-to-SQL System Using SQLI
Providing SQL access to your VA FileMan data requires using a number of software components, all working
together. VistA's SQLI software product is one component of several needed for a complete system.
Required Components
1. SQLI: Part of VA FileMan. Projects VA FileMan's internal data dictionary information in a format tailored for use by
M-to-SQL vendors.
2. M-to-SQL Product. Must be purchased from a vendor. It should:
• Provide SQL services
• Be able to map its SQL data dictionaries so that SQL tables can reference data stored in M globals.
3. SQLI Mapper. Provided by the vendor of the M-to-SQL product. This utility reads the information published by
SQLI to map the M-to-SQL product's SQL data dictionaries to reference VA FileMan data.
4. ODBC Drivers (optional). If the M-to-SQL software can act as an ODBC data source, the vendor can provide
ODBC workstation drivers.
Mapping VA FileMan to SQL without SQLI
Several commercial vendors have already implemented SQL interfaces to the VA FileMan database, by mapping
directly to VA FileMan's internal data dictionary structures. Despite their success, you should consider using an M-toSQL product that can construct its mapping to the supported relational view of VA FileMan data structures provided
by SQLI.
Advantages of Mapping to VA FileMan through SQLI
SQLI publishes all of the information M-to-SQL vendors need to access VA FileMan data through SQL. It places a
layer between M-to-SQL vendors and VA FileMan's data dictionary, projecting the format for SQL access to VA
FileMan files in a uniform manner. This approach results in a number of advantages, compared to vendors mapping
directly against VA FileMan's internal data dictionary:
 SQLI projects VA FileMan files as tables and VA FileMan field types as SQL data types, functions, and
domains.Insulates M-to-SQL vendors from directly accessing VA FileMan's data dictionary structures, which are
subject to change.
 SQLI provides standard interpretations of data structures such as pointer fields, variable pointer fields, wordprocessing fields, multiples, and internal entry numbers. It also provides a standard treatment of primary
keys.Enables standard approaches to writing queries across all VA sites.
 SQLI publishes standard SQLI identifiers for each VA FileMan file and field.Enables one site's SQL queries to
work across all VA sites.
 SQLI provides a standard layer in VA FileMan for SQL access features.The presence of SQLI lays the
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-300
7468
7469
7470
7471
7472
7473
7474
7475
7476
7477
7478
7479
7480
7481
7482
7483
7484
7485
7486
7487
7488
7489
7490
7491
7492
7493
7494
7495
7496
7497
7498

groundwork for deeper integration of SQL access with VA FileMan.
SQLI provides code for many of the data retrieval tasks inherent in accessing VA FileMan data through
SQL.Should save vendor work, and encourage uniform approaches to retrieving VA FileMan data among
vendors.
Developer Notes
As a developer, you may want to work with VA FileMan data relationally, using embedded SQL commands. You
might then wonder if SQLI and its APIs would help you in doing this.
SQLI does not itself provide an API for directly accessing VA FileMan data. Nor is it able to provide access to VA
FileMan data relationally on its own. Instead, it provides a framework for M-to-SQL vendors to access VA FileMan's
internal data dictionary information. M-to-SQL vendors are then able to provide relational access to VA FileMan data.
As a developer, to work with VA FileMan data relationally your application should make use of services provided by
COTS M-to-SQL software. Your application can then use SQL statements to access VA FileMan data, either directly
or in conjunction with ODBC-aware client applications. Using services provided by the COTS M-to-SQL product (and,
optionally, ODBC-aware client software), your application can:
• Run SQL queries on VA FileMan data
• Implement business rules using SQL stored procedures
• Create and use database views
• Optionally incorporate business rules (as SQL stored procedures) in database views
Figure: 3.3-32
3.3.31 Standard Files and Tables
Documentation available in vdl does not provide information regarding this application and/or its features (nor does
the Monograph) but only two patches for the KERNEL application:
KERNEL Patch XU*8*105 (31 Mar 1999) is designed to identify and correct two data problems associated with the
following files:
1. Patient (File #2)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-301
7499
7500
7501
7502
7503
7504
7505
7506
7507
7508
7509
7510
7511
7512
7513
7514
7515
7516
7517
7518
7519
7520
7521
7522
7523
7524
7525
7526
7527
7528
7529
7530
7531
2. Fee Basis Vendor (File #161.2)
3. Person (File #16)
4. HBHC Patient (File #631)
The two problems being addressed and corrected with this patch are
described below:
1. Dangling pointers associated with the County Fields in the
aforementioned files are identified and cleaned up. (set to null)
2. State and County entries that are currently null are identified
and listed as exceptions. The exceptions are listed in the temporary
global ^XTMP("XUXTMP") This is a new temporary global created by the
patch. These exceptions are identified to provide a list of current state
and county entry errors at each site. They will need to be addressed on a
site-to-site basis.
KERNEL Patch XU*999*3 (2 Sep 1998) is an informational patch providing instructions for synchronizing the VISTA
STATE file (#5) and the AAC edit table. These recommended modifications will standardize State and County entries
across all Veterans Affairs Medical Centers and with the Austin Automation Center.
Figure: 3.3-33
3.3.32 SAGG-Statistical Analysis of Global Growth
Statistical Analysis of Global Growth (SAGG) Version 2.0 (Patch KMPS*2*0)
The Veterans Health Administration (VHA) developed the Statistical Analysis of Global Growth (SAGG) software in
order to obtain more accurate information regarding the current and future VistA database growth rates at the VA
Medical Centers (VAMCs).
SAGG is a fully automated support tool developed by the Capacity Planning (CP) team, which entails the monthly
capture of global database, software, and file size information from participating sites.
Installing the SAGG software creates the collection process mechanism and other necessary components of the
software. The fully automated data collection cycle entails capturing all production global, software, and file specifics
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-302
7532
7533
7534
7535
7536
7537
7538
7539
7540
7541
7542
7543
7544
7545
7546
7547
7548
7549
7550
7551
7552
7553
7554
7555
7556
7557
at the site into a temporary ^XTMP("KMPS") collection global. Once collected, the information is converted into an
electronic mail message that is automatically transferred via network mail and merged into a CP National Database.
The temporary collection global is then deleted from the site's system. The site also receives a summary of the global
statistical data in the form of an electronic turn-around message.
After the initial setup procedures are performed as detailed in the patch description for KMPS*2*0, the collection
process basically operates transparent to IRM with minimal impact on system resources. The software uses the
Kernel supplied TaskMan utility to schedule the initial global collection cycle, and it is then rescheduled to capture on
a regular monthly basis.
All options in the SAGG V. 2.0 software under the SAGG Project Manager Menu [KMPS SAGG MANAGER] can
function independently. Only the Schedule/ Unschedule Options option [XUTM SCHEDULE] under the TaskMan
Management menu can invoke the SAGG Master Background Task option [KMPS SAGG REPORT].
Figure: 3.3-34
3.3.33 Survey Generator
The Survey Generator is a software package which allows creation and maintenance of computerized survey forms.
It also provides for entry of any respondents answers via computer terminal or a hard copy filled out and then entered
by any designated person. In addition, it provides useful statistical information by survey alone or by demographic
data items.
This package is designed with both the survey author and the respondent in mind. It is simple to use and
straightforward in operation and does not require any exceptional skills on the user's part.
Functional description
Creating a survey:
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-303
7558
7559
7560
7561
7562
7563
7564
7565
7566
7567
7568
7569
7570
7571
7572
7573
7574
7575
7576
7577
7578
7579
7580
7581
7582
7583
7584
7585
7586
7587
7588
7589
7590
7591
7592
7593
7594
7595
7596
7597
7598
7599
7600
7601
The survey author designs a survey, complete with layout and questions for it. The survey is then entered via any
terminal using the supplied menu items ' then printed in a draft f orm and reviewed for accuracy. If the survey is as
the author desires, it then can be released to users who may participate via any terminal. The survey also may be
printed in a final hard copy form for distribution to persons who do not have ready computer access.
In addition, there are other menu options which allows the survey author to manipulate, maintain, copy or report on
surveys.
Editing and Maintenance of a survey:
The author of the survey may use the supplied menu options or sub-options to create, edit, or maintain any part of a
survey. There are, however, certain constraints to maintenance. Several maintenance items may only be used
provided the survey has not yet been responded to. This includes things like adding or deleting questions and
demographic items. other maintenance items like copying, printing, complete survey deletions and counting the
number of current participants may be done at any time. Persons who hold the QAP MANAGER key or who are
designated by the creator as authorized editors, may act on behalf of the creator for any maintenance items.
Survey Participation:
A person who wishes to respond to a survey may use the option 'Participate in a Survey' to enter his/her answers via
any computer terminal. Users who do not have
access to a computer terminal may fill out a hard copy of the survey and return it to the proper person for manual
input. Users who have only partially completed a survey may suspend the survey and resume at a later date.
It should be noted that survey creation and participation is entirely voluntary on the part of the authors and
participants.
Other items:
There are no electronic signatures or other similar items for this package. This package requires no periodic purging
or regular maintenance from the IRM Service.
The Survey Generator Package consists only of two main menus and two sub-menus.
Survey Generator Manager Menu
1 Create/Edit a Survey
2 Copy a Survey
3 Print a Survey
4 Release/Disable a Survey for Participation
5 Count Survey Participants
6 Delete a Survey, Questions and Responses
7 Clear a Survey of Responses
8 Generate Survey Statistics
9 Print Statistics by a Demographic Data Item
10 Print all Survey Responses Individually
11 Export a Survey
12 Import a Survey
13 Populate the Demographic Reference File
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-304
7602
7603
7604
7605
7606
7607
7608
7609
7610
7611
7612
7613
7614
14 Fix a Survey Response
Survey participant Menu
1 Participate in a Survey
2 Edit an Incomplete Survey Response
3 Print Statistics by a Demographic Data Item
4 Generate Survey Statistics
5 User Hardcopy Print of Survey
Figure: 3.3-35
3.3.34 STK-System Toolkit
There are no documents for this application at this point. (As of: October 30, 2009)
7615
7616
7617
7618
Figure: 3.3-36
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-305
7619
7620
7621
7622
7623
7624
7625
7626
7627
7628
7629
7630
7631
7632
7633
7634
7635
7636
7637
7638
7639
7640
7641
7642
7643
7644
7645
7646
3.3.35 VDEF-VistA Data Extraction Framework
VistA Data Extraction Framework (VDEF) is a VistA package that uses hard-coded MUMPS (M) routines to create
and deliver Health Level 7 (HL7) messages. The VDEF package supports queuing requests for messages, control of
the timing of message creation, monitoring of the request queue, and recording of errors encountered during
message creation. The hard-coded programs are M programs belonging to an application’s namespace.
Messages are delivered using the VistA HL7 package.
The VDEF package is installed as a regular Kernel Installation and Distribution System (KIDS) build.
Figure: 3.3-37
3.3.36 VistALink
VistALink enables HealtheVet applications to communicate with VistA/M systems. The VistALink resource adapter is
a transport layer that provides communication between HealtheVet-VistA Java applications and VistA/M servers, in
both client-server and n-tier environments. It is a runtime and development tool that allows java applications to
execute remote procedure calls (RPCs) on the VistA/M system and retrieve results, synchronously. VistALink is also
referred to as VistALink J2M.
VistALink consists of Java-side adapter libraries and an M-side listener:
 The adapter libraries use the J2EE Connector Architecture (J2CA) 1.5 specification to integrate Java
applications with legacy systems.
 The M listener process receives and processes requests from client applications.
 Java applications can call Remote Procedure Calls (RPCs) on the M server, executing RPC Broker RPCs on the
M server without modification.
All components of VistALink 1.6 are compatible with WebLogic 9 and higher, up to and including WebLogic 11g.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-306
7647
7648
7649
7650
7651
7652
7653
7654
7655
7656
7657
7658
7659
7660
7661
7662
7663
7664
7665
7666
7667
7668
7669
7670
7671
7672
7673
7674
7675
7676
7677
7678
VistALink 1.6 has been tested and is supported on Oracle WebLogic Server 9.x and 10.x, only.
Reasons for VistALink:
 Alternatives for communication between Java and M applications exist, but at the time of release of VistALink
(v1 .0 and v1 .5), the needs of HealtheVet applications had not been met by these alternatives. Each of these
alternatives is described below:
 Remote Procedure Call (RPC) Broker—The RPC Broker is COM-based, rather than Java-based. Using a Java
wrapper around the COM-based Broker was proven by the Care Management team to have unacceptable
performance limitations.
 Vitria BusinessWare software—Vitria BusinessWare software is used as an HL7 interface engine by the VA for
asynchronous server-to-server messaging.
 However, there are many situations where applications need to access functionality on another server
synchronously, almost always while an end-user is interacting with the HealtheVet application and waiting for the
next page to be composed and displayed.
 Caché—Caché provides some connectivity mechanisms between itself and Java applications. However, these
features did not meet the architectural requirements for HealtheVet applications.
 Third-Party J2EE Connector-Compliant Adapters—At least one company marketed an adapter for J2EE-M
connectivity that is J2EE Connector compliant (as is VistALink). This adapter, however, was for a version of M
(Digital Standard Mum ps/DSM) no longer used by VA.
 Web Services—At the time of design and subsequent release of VistALink v1 .5, Web services functionality was
not yet standardized in J2EE. It is well-noted, however, that post-VistALink-v1.5, this has changed, and that
current versions of Caché provide Web services support as well.
Features
 Client/Server connectivity from Java client to M—Supports Java rich client applications connecting to M servers
and executing RPCs on those servers. This provides the equivalent of RPC Broker functionality for Java
applications.
 J2EE Application Server connectivity to M—Supports applications and services running on a J2EE application
server, enabling them to initiate a call to an M server and execute RPCs. Implements the Java 2 Enterprise
Edition (J2EE) Connectors specification. HealtheVet applications using this functionality include Patient
Advocate Tracking System (PATS), Veterans Personal Finance System (VPFS) and Blind Rehabilitation.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-307
7679
7680
7681
7682
7683
7684
7685
7686
7687
7688
7689
7690
7691
7692
7693
7694
7695
7696
7697
7698
7699
7700
7701
7702
7703
7704
Figure: 3.3-38
3.3.37 XML Parser (VistA)
The VistA Extensible Markup Language (XML) Parser is a full-featured, validating XML parser written in the M
programming language and designed to interface with the VistA suite of M-based applications. It is not a standalone
product. Rather, it acts as a server application that can provide XML parsing capabilities to any client application that
subscribes to the application programmer interface (API) specification detailed in this document.
The VistA XML Parser employs two very different API implementations. The first is an event-driven interface that is
modeled after the widely used Simple API for XML (SAX) interface specification. In this implementation, a client
application provides a special handler for each parsing event of interest. When the client invokes the parser, it
conveys not only the document to be parsed, but also the entry points for each of its event handlers. As the parser
progresses through the document, it invokes the client’s handlers for each parsing event for which a handler has
been registered.
The second API implementation is based on the World Wide Web Consortium (W3C’s) Document Object Model
(DOM) specification. This API, which is actually built on top of the event-driven interface, first constructs an inmemory model of the fully parsed document. It then provides methods to navigate through and extract information
from the parsed document.
The choice of which API to employ is in part dependent on the needs of the application developer. The event-driven
interface requires the client application to process the document in a strictly top-down manner. In contrast, the inmemory model provides the ability to move freely throughout the document and has the added advantage of ensuring
that the document is well formed and valid before any information is returned to the client application.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-308
7705
7706
7707
7708
7709
The VistA XML Parser employs an Entity Catalog to allow storage of external entities such as document type
definitions. The Entity Catalog is a VA FileMan-compatible database and can be manipulated using the usual VA
FileMan tools.
The parser uses the Kernel function FTG^%ZISH for file access.
7710
7711
7712
7713
7714
7715
Figure: 3.3-39
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-309
7716
7717
7718
7719
7720
7721
7722
7723
7724
7725
7726
7727
7728
7729
7730
7731
7732
7733
7734
7735
7736
7737
7738
7739
7740
7741
7742
7743
7744
7745
7746
7747
7748
7749
7750
7751
7752
7753
7754
3.4 HealtheVet
The subsystem is also known as VistA 1.5. My HealtheVet (MHV) is a Web-based application that creates
a new, online environment where Veterans, family, and clinicians may come together to optimize
veterans’ health care. This Web technology combines essential health record information enhanced by
online health resources to enable and encourage patient/clinician collaboration. It is the first Web-based
application created by the Office of Information for the exclusive use by veterans. MHV provides a onestop shop for information on VA benefits, special programs, and health information and health services.
MHV also provides services and tools that enable veterans to keep record of their health status and
communicate more effectively and on a more consistent basis with their care providers, as well as
become better-informed participants in improving their health. Veterans can now partner with their
clinicians to gain a better understanding of their health status and to take a more active role in selfmanagement and in shared health care decision-making.
Features
 Enables all veterans to participate voluntarily and have access to and control of his/her
customizable online environment.
 Provides a commercial Health Education Library that contains information on medical conditions,
medications, health news, and preventive health.
 Makes the library available to clinicians; addressable from the CPRS toolbar and included in
order sets.
 Showcases education and program information developed by VHA program offices.
 Contains the latest VA/VHA news.
 Contains a prescription checker, health calculators, and self-assessment tools.
 Maps to benefits and resources available in VA and other federal sources.
 Provides online prescription refills for veterans enrolled in VA health care.
 Provides ability to view next appointment date and time at a VA health care facility.
 Provides ability to see total co-payment balance.
 Allows patient to enter and store personal information in a secure eVAult.
 Provides ability to format and print reports, such as information cards and medication profiles.
 Enables veterans to journal readings and chart progress in five self-entered metrics (e-logs)—
blood pressure, blood sugar, cholesterol, weight, and heart rate.
 Enables veterans to utilize additional e-logs, journal readings, and chart progress.
 Allows veterans to request and store key portions of their VA health record in a secure, unique, and
personal repository.
 Enables veterans to let a delegate access and manage all or some of their health information,
including, family, veteran advocates, and VA and non-VA providers.
 Allows veterans to receive wellness reminders, written specifically for the patient, to provide
effective delivery of preventive medicine served through standardized reminders.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-310
7755
7756
7757
7758
7759
7760
7761
7762
7763
7764
7765
7766
7767
7768
7769
7770
7771
7772
7773
7774
7775
7776
7777
7778
7779
7780
7781
7782
7783
7784
7785
7786
7787
7788
7789
7790
7791
7792
7793
7794
7795
HealtheVet Desktop is an application framework that will host the new generation of Veterans Health Administration
(VHA) clinical applications. Care Management is the first application to run on the new HealtheVet Desktop, and is an
enhancement of CPRS designed to assist health care providers to follow-up on clinical interventions that might
otherwise be missed. Care Management provides an automated method for tracking follow-up actions/tasks for a
panel of patients for a designated period of time. The four perspectives of Care Management are the Clinician
Dashboard, the Nursing Dashboard, the Query Tool, and the Sign List. Implementation of the Care Management
project will improve patient care by:
•
•
•
•
Ensuring that appropriate clinical interventions are provided on a timely basis;
Ensuring that clinical notifications are processed on a timely basis;
Reducing the amount of time primary care providers spend reviewing individual patient records; and,
Reducing the risk of erroneous data entry.
HealtheVet-VistA (Future)
A strategy has been developed to move the Veterans Health Information Systems toward “HealtheVet,” an ideal
health information system to support the ideal veterans health system. Collaboratively among the Department, field,
and central office leadership and the Chief Information Officer, a proposed strategy has been developed for both VA
and Veterans Health Administration needs. The strategy is built around five major systems and integrates five crosscutting issues:
•
•
•
•
•
The Health Data System Health Data Repository (HDR) will create a true longitudinal health care record,
including data from VA and non-VA sources. The Health Data System will support research and population
analyses, facilitate patient access to data and sharing of information across VHA, and improve data quality and
data security. The Health Data System will also emphasize “eHealth,” to include prescription refills,
appointments, fillable forms online, and My HealtheVet (access to health record, on-line health assessment
tools, and high-quality health information).
Provider Systems support health care providers' care for veterans and feed information to VistA today and the
HDR in the future. These include CPRS, VistA Imaging, Blood Bank, Pharmacy, Laboratory, and Federal Health
Information Exchange (FHIE).
Management/Financial Systems include four applications that are each ten or more years old, and will be
replaced: the Financial Management System, Billing and Accounts Receivable (AR), and Fee Basis (paying
providers).
Registration, Enrollment, and Eligibility Systems will be developed as a single, department-wide data system and
demographic database that supports registration and eligibility for the three Administrations, and makes this
information more accessible and consistent.
Common Services develops and maintains the underlying software infrastructure that supports both legacy and
current veteran health-related applications. Though largely transparent to end users, Common Services provides
essential infrastructure elements such as identity management, security, message routing, transformation, and
data transport for clinical and administrative applications. Core common services are addressed through four
programs: Identity Management, Security Services, Messaging and Interface Services, and Other Common
Services.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-311
7796
7797
7798
7799
7800
7801
7802
Figure: 3.4-1
3.4.1 CISS-Clinical Information Support System
There are no documents for this application at this point.
(As of: October 30, 2009)
7803
7804
Figure: 3.4-2
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-312
7805
7806
7807
7808
7809
7810
7811
7812
7813
7814
7815
7816
7817
7818
7819
7820
7821
7822
7823
7824
7825
7826
7827
7828
7829
7830
3.4.2 ESig-Electronic Signature
As HealtheVet-VistA developers migrate VistA applications to modern technologies, interim solutions may be
required until enterprise solutions are mature and stable. The Electronic Signature (ESig) service provides an interim
solution for the use of electronic codes in place of wet signatures while HealtheVet-VistA’s security infrastructure and
architecture are being defined. The service duplicates for Java applications (J2EE or J2SE) the Kernel 8.0 electronic
signature functionality currently used by VistA/M applications.
ESig furnishes a standard, consistent set of APIs that HealtheVet -VistA developers can implement to provide users
access to electronic signature data stored on VistA/M systems. ESig APIs make calls from Java applications to
VistA/M systems to retrieve, validate, and store electronic signature codes and signature block information (name,
title, office phone, etc.). Additional Java APIs provide encoding/decoding, hash, and checksum calculation utilities,
but do not interact with the VistA/M system.
Applications that implement the ESig service must provide a user interface (UI) to prompt users for their secret codes
when authorizing orders, prescriptions, financial transactions, or other business processes. Users may also need the
UI to create or modify their code or signature block data.
Figure: 3.4-3
3.4.3 HWSC-HealtheVet Web Services Client
As VistA is migrated to the new HealtheVet-VistA system, some legacy VistA applications will need synchronous
access to HealtheVet application services and data. HWSC uses Caché’s Web Services Client to invoke web service
methods on external servers and retrieve results. It provides helper methods and classes to improve the use of the
Web Service Client in a HealtheVet-VistA environment.
Features
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-313
7831
7832
7833
7834
7835
7836
7837
7838
7839
7840
7841
HWSC acts as an adjunct to the web services client functionality provided in Caché, by:
• Leveraging Caché's platform-provided Web services client capabilities.
• Adding a file and UI to manage the set of external web server endpoints (IP, port, etc.)
• Adding a file and UI to register and manage the set of external web services.
• Providing runtime API to invoke a specific web service on a specific web server.
• Providing a runtime API to facilitate error processing in a VistA environment.
• Providing a deployment API to install/register a web service proxy from a WSDL file.
• Providing a management UI including the ability to 'ping' (test) a given web service/server combination from
VistA/M.
• Supporting both SOAP- and REST-style web services
• Fostering consistent implementation of VistA/M web service consumers
7842
7843
7844
7845
Figure: 3.4-4
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-314
7846
7847
7848
7849
7850
7851
7852
7853
7854
7855
7856
7857
7858
7859
7860
7861
7862
7863
7864
7865
3.4.4 My HealtheVet
The My HealtheVet VistA package supports the internet prescription refill functionality of the MHV website. It
includes HL7 interfaces supporting queries for prescription information, and orders for refills.
My HealtheVet prescription refill functionality allows patients to request refills of their prescriptions online, resulting in
fewer refill requests made via mail and telephone. My HealtheVet also allows veterans to get information on their
current prescriptions, and their historical prescriptions. Online access to this information results in fewer calls to the
pharmacy and Release of Information office.
My HealtheVet (MHV) is an online environment where veterans, family members and clinicians may come together to
optimize veterans’ healthcare. Web technology combines essential health record information with online health
resources to enable and encourage veteran/clinician collaboration.
The My HealtheVet system consists of a national system housed at the Austin Automation Center (AAC), and the My
HealtheVet VistA package. The national system is comprised of a website available to all veterans on the public
internet (http://www.myhealth.va.gov), and its supporting database, application, and internet servers. More
information on that system is available from the My HealtheVet Product Homepage at
http://vaww1.va.gov/MyHealtheVet.
MHV should be journaled.
7866
7867
7868
Figure: 3.4-5
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-315
7869
My HealtheVet - (Component diagram)
cmp My HealtheVet
Name:
Package:
Version:
Author:
My HealtheVet
My HealtheVet
1.0
Pat
My HealtheVet
«interface»
MHV
7870
7871
7872
7873
7874
7875
7876
7877
7878
7879
7880
7881
7882
7883
7884
7885
7886
7887
7888
7889
7890
7891
7892
7893
7894
7895
7896
7897
7898
7899
7900
7901
7902
7903
Austin Information
Technology Center
Figure: 3.4-6
3.4.5 NUMI-National Utilization Management Integration
The National Utilization Management Integration (NUMI) application is a web-based solution that automates
utilization review assessment and outcomes. The Utilization Management (UM) Process is a tool used to help ensure
that patients are receiving the right care, at the right time, and in the right place. UM is both a quality and efficiency
tool, as it is used to move patients efficiently through the VA system to maximize use of resources. UM reviewers
assess patient admissions and hospital stay days using standardized objective evidence-based clinical criteria to
determine whether patients meet criteria for acute hospital care.
The NUMI application standardizes UM review methodology and documentation at the facility level and creates a
national VHA utilization information database. In NUMI, patient movement data is obtained from read-only VistA
access to pre-populate a patient stay database, eliminating redundancy and errors from manually re-entering patient
data. A Commercial Off-the-Shelf (COTS) product, McKesson Care Enhanced Review Management Enterprise
(CERME), is integrated into NUMI to provide access to the InterQual® standardized clinical appropriateness criteria
and algorithms. The CERME functionality is used to determine whether patient admissions and hospital days meet
clinical appropriateness criteria for acute care hospital care. The national NUMI database is built in SQL and will
enable facility, VISN, and national reporting of UM review outcomes.
The NUMI system provides critical functionality to help UM reviewers to organize UM review workload, document UM
review outcomes, and generate reports to help identify system constraints and barriers to providing the appropriate
services at the appropriate level of care. NUMI users can perform the following functions:
• Pre-populate patient stay information from VistA into a NUMI SQL database which records patient stay
information. UM review outcomes, reasons, and recommended levels of care are saved in the NUMI database
• Generate a list of patient admissions and hospital days that need to be reviewed to assist UM reviewers in
organizing their workload
• For newly admitted patients, collect patient and treatment information to determine whether patients meet clinical
criteria for inpatient admission
• Following admission, collect treatment information for each hospital day to determine whether patients meet
continued stay criteria
• Standardize documentation of a) reasons for inpatient admissions or continued stays that do not meet clinical
criteria for inpatient care, and b) recommended levels of care for admissions and continued stay days not
meeting criteria
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-316
7904
7905
7906
7907
7908
7909
7910
7911
7912
7913
7914
7915
7916
7917
7918
•
•
•
•
Provide Physician UM Advisors with an automated UM review list to access reviews, document agreement or
disagreement with current levels of care, and add comments and recommendations regarding patients not
meeting criteria
Generate summary reports of UM outcomes to provide insight into system constraints and barriers and identify
quality improvement opportunities
Assign specific reason codes for reviews that do not meet criteria. The VA-specific reason code structure will
enable UM staff to aggregate and analyze the most prevalent reasons why patients are not meeting criteria at
their current level of care. This information provides insight to help identify quality and access improvement
opportunities.
Display a list of patient stays and review information, with filters and search features to assist in organizing
individual reviewer workloads
NUMI was developed to address the Utilization Management data needs of the VHA and to provide the UM staff with
a web-based solution for capturing patient information in compliance with VHA Directive 2005-040 (Utilization
Management Policy).
7919
7920
7921
7922
Figure: 3.4-7
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-317
7923
7924
7925
7926
7927
7928
7929
3.4.6 OHRS-Occupational Health Record-keeping System
The Occupational Health Record-keeping System (OHRS), is a web-based application that enables occupational
health staff to create, maintain, and monitor medical records for VA employees and generate national, Veterans
Integrated Service Network (VISN), and site-specific reports.
The OHRS help topics provide detailed information to assist Clinical Information Support System (CISS) site staff
members and other users to successfully use CISS and OHRS.
7930
7931
7932
7933
Figure: 3.4-8
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-318
7934
7935
7936
7937
7938
7939
7940
7941
7942
7943
7944
7945
7946
7947
7948
7949
7950
7951
7952
7953
7954
7955
3.4.7 PATS-Patient Advocate Tracking System
The Patient Advocate Tracking System (PATS) is a web-based application with a centralized database and
notification function (email) for tracking patient-related issues. PATS is designed to work on various operating
systems (e.g., Windows 2000, Windows XP, Linux).
PATS enables users to perform the following tasks:
 Add a Report of Contact (ROC) which details a Veteran’s issue (compliment or complaint).
 Edit, close, reopen, and delete an ROC.
 Send Informational Notifications to communicate an issue to an employee involved in a Report of Contact and/or
the employee’s supervisor.
 Send Action Request Notifications, which require a response from the individual regarding action to be taken or
next steps.
 Generate site-specific and National reports.
 Create ad hoc reports.
 Display reports online and save them in a variety of formats (i.e., Word, Excel, PDF files).
PATS automatically rolls up data to the VISN Support Service Center (VSSC) to provide additional National reports.
National Program Office and Patient Advocates can add and change (update, activate, and inactivate) PATS tablereference data (e.g., Hospital Location).
PATS includes online help pages that you can access from the menu or directly from each page within the
application.
7956
7957
7958
7959
Figure: 3.4-9
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-319
7960
PATS-Patient Advocate Tracking System - (Component diagram)
cmp PATS-Patient Adv ocate Tracking System
Name:
Package:
Version:
Author:
PATS-Patient Advocate Tracking System
PATS-Patient Advocate Tracking System
1.0
Pat
PATS-Patient
Adv ocate Tracking
System
«interface»
PATS
7961
7962
7963
7964
Austin VISN Support Service Center - VSSC
Figure: 3.4-10
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-320
7965
7966
7967
7968
7969
7970
7971
7972
7973
7974
7975
7976
7977
7978
7979
7980
7981
7982
7983
7984
7985
7986
7987
3.4.8 Person Services
Enhancements (Release Notes):
North Chicago Enhancement
• Add new "Attended Search threshold" value to support the returning a larger range of selectable candidates
(needed to support when SSN is not provided or unavailable)
VRM IAM IPT
• Add DoD Correlation based on VA LOB Business
IdM User -HcIdM (WorkStream)
• General Usability enhancements
• Manage Potential Duplicate enhancement
• Exception search enhancement
• TK display support for NHIN larger Identifiers
• TK support for PIV card login authentication
IdM Service (WorkStream)
• Establish DoD Query WebService Interface
• Establish DoD Update Patient WebService Interface
• Establish DoD Add Person WebService Interface
• Establish GetProfile WebService
• Create Admin tools to manually monitor and trigger WebServices
• Enhance VA IdM Service internal integration to support Baker VRM (EDIPI/ MVI) decision
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-321
7988
7989
7990
7991
7992
7993
7994
7995
Figure: 3.4-11
3.4.9 Registries
There are no documents for this application at this point.
(As of: October 30, 2009)
The Registries Program supports the population-specific data needs of the enterprise.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-322
7996
7997
7998
7999
8000
8001
8002
8003
8004
8005
8006
8007
8008
8009
8010
8011
8012
8013
8014
8015
8016
8017
8018
8019
Figure: 3.4-12
3.4.10 SCIDO-Spinal Cord Injury and Disorders Outcomes
The Spinal Cord Injury and Disorders Outcomes (SCIDO) application is a system for compiling spinal cord injury and
disorders information. The SCIDO application accesses several other VistA programs that contain information
regarding diagnoses, prescriptions, surgical procedures, laboratory tests, radiological exams, patient demographics,
hospital admissions, and clinical visits. This access allows clinical staff to take advantage of the data supported by
VistA. Information can be summarized at three levels: local medical center, SCI&D region, or national research
access.
Overview and Features
The SCIDO application has been organized using World Health Organization concepts. After a cover sheet
summarizing the patient’s status and a registration sheet, tabs address impairments, medical complications,
activities, and participation. The reports tab and administration tab follow these health domain tabs.
Subject Tabs
The footer of each page contains seven tabs representing the pages of the application. Moving from one page to
another is possible by simply selecting the tabs located at the bottom of each page. For example, if the user is on the
Activities tab and wants to open the Impairments tab, the user selects the Impairments tab in the footer. The SCIDO
application can be navigated through the following tabs:
Cover Sheet – displays a summary of the patient’s status. It displays recent diagnoses and CPT codes from the past
five years. The Cover Sheet also displays information the user may have entered through three other tabs of the
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-323
8020
8021
8022
8023
8024
8025
8026
8027
8028
8029
8030
8031
8032
8033
8034
8035
8036
8037
8038
8039
8040
8041
8042
8043
8044
8045
8046
8047
8048
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
application. If the information has not been entered, these fields will be blank. The patient record opens to the Cover
Sheet unless the Veteran has not been registered in the SCIDO application.
Registration Tab – used to register Veterans into the SCIDO application and to enter data, which allows staff access
to valuable regional and local program data. This information is designed to simplify your job. Investing a small
amount of time entering registration and other useful information will return valuable dividends when the information
is needed in reports or displayed.
Impairments Tab – Impairments refer to any loss of psychological, physiological, or anatomical structure or function.
Impairments affect organ systems, thought, or emotion. Information about impairments is provided on both the
Impairments Tab and the Medical Complications Tab.
Medical Complications Tab – Medical Complications are impairments that are commonly associated with spinal cord
injury; therefore, this tab focuses on respiratory complications, urinary tract infections, influenza, pressure ulcers, and
pain. These secondary complications are common, costly, and can be disruptive to activities, participation, and
satisfaction with life.
Activities Tab – activities are tasks and actions by an individual at the level of a person rather than the anatomic,
physiological, or social levels. Activities have been associated traditionally with abilities, disabilities, or independence.
This tab summarizes common activity limitation measures such as the FIM, FAM, and Kurtzke EDSS and FSS
measures, which are used specifically for multiple sclerosis.
Participation & SWLS Tab – participation reflects the nature and extent of a person’s involvement in life situations at
a social or societal level and often pertains to participating in meaningful social roles. This tab summarizes
participation information based on the CHART-SF and also includes Diener’s Satisfaction with Life Scale (SWLS).
Reports Tab – reports reflect the benefits of accurately maintaining the SCIDO application for the Veterans you
serve. Templated reports regarding impairments and medical complications, aggregate outcome reports, and patient
listings are available for ready review. Filtered reports allow the selection of specific portions of the population for
review before the reports are generated. For unique reports that affect your practice, you can learn how to use the
Report Designer to generate custom reports for the population.
Administration Tab – provides the functionality to display user names and roles; SCI Regional definitions; activate or
inactivate a patient status; activate or inactivate patient assessments; activate or inactivate Episodes of Care; import
patient records from the national database; and add or delete SCI and Multiple Sclerosis (MS) mail groups.
Information Resource Management (IRM) tab – allows a person within the IRM/ISS/ITS user role to add or delete
medical centers from SCI&D regions, modify regional attributes, perform a national or regional audit, and monitor
system activity.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-324
8059
8060
8061
8062
8063
8064
8065
8066
8067
8068
8069
8070
8071
8072
8073
8074
8075
Figure: 3.4-13
3.4.11 VES-VA Enrollment System
Enrollment System Redesign (ESR) V3.4 (a.k.a. HECMS) is the HealtheVet replacement system for the
decommissioned product known as HEC (Health Eligibility Center, Atlanta) Legacy. It is both a re-host of HEC
Legacy and in some instances (use cases/features), a re-engineering. HECMS allows staff at the HEC to work more
efficiently and determine patient eligibility in a more timely manner. Messaging with the VAMC (Department of
Veterans Affairs Medical Center) allows updates to the enterprise enrollment system to be shared with the field.
It is one component of the "system of systems" needed to implement the HealtheVet REE (Registration, Eligibility
and Enrollment) environment.
Its two main functions are:
1. Expert System
 Based on information obtained from sites, VBA (Veterans Benefit Administration) and HEC staff determine and
communicate verified medical benefits eligibility and enrollment (E&E) information for all Veterans and
beneficiaries.
2. Work Flow (Case Management)
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-325
8076
8077
8078
8079
8080
8081
8082
8083
8084
8085
8086
8087
8088
8089
8090
8091
8092
8093
8094
8095
8096
8097
8098
8099
8100
8101
8102
8103
8104
8105
8106
8107
8108
8109
8110
8111
8112
8113
8114
8115
8116
8117
8118
8119

For every exception where the expert system process cannot make a determination, "cases" are created for
human intervention.
HEC staff utilizes HECMS to manage these "cases" to completion so that verified E&E can be determined.
________________________________________
To satisfy the Program Management Accountability System (PMAS) initiative to provide more frequent software
releases with reduced functionality, ESR V3.1 was released separate from the Veterans Online Application (VOA)
package, which will be released at a later date. The unpopulated VOA fields are identified by adding “VOA” in
parenthesis next to the respective field names in this manual. These placeholder fields will not be populated until
VOA is released.
ESR V3.2 added the General Counsel’s (GC) Ruling on changes to the Geographic Means Test Threshold (GMTT).
The GC ruling dictates that people with very low income who live where the GMTT is less than the Means Test
Threshold (MTT) and whose net income is less than the GMTT, yet their net income plus assets is greater than the
Net Worth Threshold, be placed in Priority Group (PG) 7.
ESR V3.3 added the Eligibility and Enrollment (E&E) Web Service which supports requests for data or information
regarding the enrollment or eligibility of Veterans on an as-needed basis. An Enrollment Web Service brokers
requests from other systems to ESR, carrying out the system specific information request.
VBA Pension Data Sharing expanded on the pension information gathered by ESR. Additional Pension Award fields
related to VA Pension were added to the Edit Current Eligibility screen. Also included as part of the VBA Pension
Data Sharing enhancement were two Class II Dental fields added to the Current Military Service screen.
Priority Group Relaxation % Phase II expanded upon the P8 Relaxation Enhancement, which allowed Veterans to be
enrolled based on a fixed percentage allowance above the Means Test or Geographical Means Test Thresholds, by
providing the ability to change the Relaxation Percentage by income year. The change was retroactive back to the
beginning of the current Income Year for any Veterans who were rejected at that time, but would now qualify under
the new relaxation percentage.
ESR V3.4 adds the following additional Military Service Data Sharing (MSDS) capabilities.
 A manual query to the Beneficiary Identification Records Locator System (BIRLS) and VA/DoD Identity
Repository (VADIR) via the MSDS Broker can be initiated from the Military Service page.
 The MSDS Query Status is displayed on the Current Eligibility page.
 The veteran’s record will be updated if the incoming data received data from BIRLS and VADIR is more
favorable for the veteran.
 Medal of Honor Indicator data is now stored and displayed on the Military Service page.
 When new Military Service Episode (MSE) or Operation Enduring Freedom/Operation Iraqi Freedom (OEF/OIF)
data is received from a site, an MSDS Broker query is triggered.
 HEC and Broker data is now used rather than site data to determine the Veteran Indicator, calculate the Combat
Veteran End Date, and determine the veteran’s Period of Service.
 MSE data is shared with the sites (VistA).
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-326
8120
8121
8122
8123
8124
8125
8126
8127
8128
8129
8130
8131
8132
8133
8134
8135
8136
8137
8138
8139
The main areas and releases in which some enhancements were made are:
 Data Handling Process (3.1)
 Reporting (3.1)
 Standardizing Date Checks (3.1)
 Enrollment Processing (3.1)
 Message Processing Improvements (3.1)
 System Administration (3.1)
 Veterans Online Application (10-10EZ supplement) (3.1)
 Identity Traits (3.1)
 Financials/Adjudication (3.2)
 E&E Web Services Phase II (3.3)
 VBA Pension Data Sharing (3.3)
 Priority Group Relaxation % Phase II (3.3)
 Remove Unecessary Data Consistency Checks (3.3)
 Duplicate Merge Tool Enhancement (3.3)
 Military Service Data Sharing (MSDS), Phase I (Phase I will create HEC-owned MSE records based on site data
from incoming ORUZ07 messages) (3.X)
 Patient Benefits Handbook Phase I (3.X)
 MSDS Phase II (3.4)
8140
8141
8142
8143
Figure: 3.4-14
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-327
8144
VES-VA Enrollment System - (Component diagram)
cmp VES-VA Enrollment System
Name:
Package:
Version:
Author:
VES-VA Enrollment System
VES-VA Enrollment System
Sep 2011
Pat
«interface»
Veterans
Enrollment
System
VA/DoD Information Repository (VADIR)
VBA Beneficiary Indentity Record Locator System (BIRLS)
8145
8146
8147
8148
8149
8150
8151
8152
8153
8154
8155
8156
8157
8158
8159
8160
Figure: 3.4-15
3.4.12 VPFS-Veterans Personal Finance System
Veterans Personal Finance System (VPFS) is the mini-banking system used by the Veterans Health Administration
(VHA) to manage the accounts of VHA patients in the VHA hospital system. VPFS replaces the Personal Funds of
Patients (PFOP) system that was used previously. VPFS looks different from PFOP because it is a web-based
application; however, its design and functionality are modeled after PFOP. You can perform all of the functions in
VPFS that were available in PFOP, with the exception of a few functions that are no longer needed because of the
new built-in security controls.
One of the major changes is that VPFS is a centralized system. With PFOP, each site used a stand-alone copy of the
software and there were differences between local versions, such as data structures, business rules, etc. With VPFS,
all sites access the same centralized application using a web browser over the VHA secure Intranet. VPFS stores all
data for all sites in one centralized database. Access to the data in the database is controlled by security software
that limits access according to your VistA site and user role.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-328
8161
8162
Figure: 3.4-16
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 3-329
81634
8164
8165
8166
8167
8168
8169
8170
8171
8172
8173
8174
8175
8176
8177
8178
8179
8180
8181
8182
8183
8184
8185
8186
8187
8188
8189
8190
8191
Appendix A: Product Definition
This "Product Definition" is the inventory of modules, which comprise OSEHRA/VistA, where:
 The FOIA release is the “core” set of modules.
 We flag FOIA modules, no longer used by the VA (e.g., HealtheVet)
 We list non-mumps modules used by the VA with appropriate comments.
 We list non-FOIA open-source and commercial modules used by the VA with appropriate comments/links.
 We list the 4 regional and 1 administrative class 2 modules with appropriate comments.
 We list VA approved class 3 modules, used by individual hospitals with appropriate comments/links.
 We list re-factored and in-flight modules with appropriate comments.
 We list the Cache environment & related modules as the primary VA platform.
 We list the GT.M environment & related modules as the available open-source platform.
 We include links to the Visual Cross Reference tool, source code/package directory, documentation Wikis, discussion groups, tests and entries per
package.
Note that a particular build will require the selection of a subset from the OSEHRA/VistA Product Definition; as an example there may be alternative modules,
which do the same function (e’g’, graphical user interfaces).
For each module, we define:
 Module grouping (e.g., Clinical, Admin/Finance/ HealtheVet)
 Class (e.g., 1, 2, 3)
 Core FOIA (yes/no)
 Module Name
 FOIA Package Name)
 Version
 Namespace
 Patch Number
 Comment
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-1
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
clinical
1
Yes
Admission Discharge
Transfer
(ADT)/Registration
Registration
5.3
DG,
DGQE,
DPT, VA,
VIC
DG*5.3*829
clinical
1
Yes
Ambulatory Care
Reporting
Scheduling,
Registration,
PCE
5.3
SD
SD*5.3*66,
DG*5.3*139,
PX*1.0*41
An add-on to Scheduling Package - ACR
menu and
Incomplete
Encounter
Management Module (IEMM)
clinical
1
Yes
Anticoagulation
Management Tool
(AMT)
Order Entry
Results
Reporting
3.0
OR
OR*3.0*307
Uses OE/RR namespace.
Uses a
windows client - AntiCoagulate.exe that
is initiated from CPRS
clinical
Vendor
No
Audiofax
Vendor Audiofax Inc
clinical
1
Yes
Automated Service
Connected Designation
(ASCD)
Scheduling,
HINQ, PCE
5.3
SD, DVB,
PX
SD*5.3*495,
PX*1.0*184,
DVB*4.0*58
clinical
1
Yes
Beneficiary Travel
Beneficiary
Travel
1.0
DGBT
DGBT*1*17
www.oserha.org
VEX
OSEHR System-Architecture, Product Definition and Roadmap
Comment
Vendor SW by AudioCARE Systems that
processes telephone refill requests. - not
included in FOIA release.
Page 4-2
Enhancement to PCE and Scheduling
application to automated clinician
decision making process in support of
service connected or non-service
connected patient encounter. Require
patches in Scheduling, Patient Care
Encounter, and Hospital Inquiry (HINQ).
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
clinical
1
No
Blind
Rehabilitation/Visual
Impairment Service
Team
Visual
Impairment
Service Team
5.0
ANRV
ANRV*5*3
BR 5.0 provides a web-enabled GUI that
uses VistALink to communicate with the
M-Server component . Although the MServer component is part of the FOIA
release, the J2EE web application is not.
Therefore, this module is not a Core
FOIA.
clinical
1
No
Care Management
Care
Management,
HealtheVet
Desktop
1.0
ORRC,
XHD
clinical
1
Yes
Clinical Case
Registries
Clinical Case
Registries
1.5
ROR,
IMR
ROR*1.5*16
Contains a Windows client component ClinicalCaseRegisteries.exe, accessed via
CPRS Tool menu
clinical
1
Yes
Clinical Procedures
Clinical
Procedures
1.0
MD
MD*1*26
The Windows client consist of three
components (CP Gateway Service, CP
Console, and CP Flowsheets). The CP
Manager app is no longer supported after
MD*1*16 patch.
clinical
1
No
Clinical/Health Data
Repository (CHDR)
www.oserha.org
Based on the HealtheVet Desktop
framework. VA will not be using this
package; hence, it is not a Core FOIA
2.0
OSEHR System-Architecture, Product Definition and Roadmap
The Department of Defense (DoD) and
the Department of Veterans Affairs (VA)
in partnership, designed and implemented
a Clinical Data Repository/Health Data
Repository
(CHDR)
system
that
generates standards-based, computable
electronic health records that can be
exchanged and shared between the two
agencies healthcare systems. This is
outside the scope of VistA 1.0 and 1.5.
Page 4-3
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
clinical
1
Yes
Computerized Patient
Record System
(CPRS)(OE/RR)
Order Entry
Results
Reporting
3.0
OR, OCX
OR*3*338
Contains CPRS GUI version 28 - a Dephi
based
Windows
client
called
CPRSChart.exe. CPRS GUI uses RPC to
communicate with various M-Server
components.
clinical
1
Yes
CPRS: Adverse
Reaction Tracking
(ART)
Adverse
Reaction
Tracking
4.0
GMRA
GMRA*4*45
Part of CPRS applications
Accessible via CPRS GUI.
group.
clinical
1
Yes
CPRS: Authorization
Subscription Utility
(ASU)
Authorization
Subscription
1.0
USR
USR*1*29
Part of CPRS applications
Accessible via CPRS GUI.
group.
clinical
1
Yes
CPRS: Clinical
Reminders
Clinical
Reminders
2.0
PXRM
PXRM*2*20
Part of CPRS applications
Accessible via CPRS GUI.
group.
clinical
1
Yes
CPRS:
Consult/Request
Tracking
Consult
Request
Tracking
3.0
GMRC,
GMRS
GMRC*3*71
Part of CPRS applications
Accessible via CPRS GUI.
group.
clinical
1
Yes
CPRS: Health
Summary
Health
Summary
2.7
GMTS,
GMT
GMTS*2.7*88
Part of CPRS applications
Accessible via CPRS GUI.
group.
clinical
1
Yes
CPRS: Problem List
Problem List
2.0
GMPL
GMPL*2*41
Part of CPRS applications
Accessible via CPRS GUI.
group.
clinical
1
Yes
CPRS: Text Integration
Utility (TIU)
Text
Integration
Utility
1.0
TIU
TIU*1*255
Part of CPRS applications
Accessible via CPRS GUI.
group.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-4
Module
Grouping
Class
Core
FOIA
Module Name
clinical
Vendor
No
Dental Record
Manager Plus (DRM
Plus)
clinical
1
Yes
Dentistry
clinical
1
Yes
clinical
1
clinical
1
www.oserha.org
FOIA
Package
Name
Version
Name
Space
1.2
DENTV
Dental
1.2
DENT
DENT*1.2*30
The FOIA release does not include the
Dental Record Manager (DRM), a vendor
SW by DSS, inc. DRM is installed in all
VA dental clinics.
Electronic Wait List
Scheduling
5.3
SD
SD*5.3*263
Scheduling 5.3 Enhancements. Software
to list and track patients waiting for clinic
appointments or primary care panel
assignments.
No
Emergency
Department Integration
Software (EDIS)
Emergency
Department
Integration
Software
1.0
EDP
Yes
Functional
Independence
Measurement (FIM)
Functional
Independence
1.0
RMIM
OSEHR System-Architecture, Product Definition and Roadmap
Latest Patch
Comment
Dental Record Manager Plus (DRM Plus)
is a GUI front end for data input into the
VistA Dental files as well as Patient Care
Encounter (PCE), Text Integration Utility
(TIU), CPRS Problem List, and Vitals
packages. The Dental Record Manager is
a nationally purchased software product
and is installed in all VA dental clinics.
DRM is a vendor SW by DSS, inc - not
included in FOIA release.
Contain web-based views (Weblogic
platform) that extend the current CPRS to
help clinicians track and manage the flow
of patient care in the emergencydepartment setting.
The web-based
application is not part of the FOIA
release.
RMIM*1*5
Page 4-5
Contains a Windows GUI component FIM.exe that uses RPC to communicate
with the M-Server component.
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
clinical
1
Yes
Group Notes
Order Entry
Results
Reporting
3.0
OR
OR*3.0*222
Designed to assist providers in
documenting group therapy sessions and
events such as immunization clinics.
clinical
1
Yes
Home Based Primary
Care (HBPC)
(Formally Hospital
Based Home Care)
Hospital
Based Home
Care
1.0
HBH
HBH*1*24
The Home Based Primary Care (HBPC)
is a VISTA application developed for use
by the HBPC Programs at the medical
centers. It uses MailMan to transmit
HBPC patient and visit data to a database
in Austin.
clinical
1
No
Home Telehealth
1.3
clinical
1
Yes
Immunology Case
Registry (ICR)
2.1
IMR
clinical
1
Yes
Incomplete Records
Tracking (IRT)
Incomplete
Records
Tracking
1.0
DGJ
clinical
1
Yes
Intake and Output
(Gen. Med. Rec. - I/O)
General
Medical
Record-IO
4.0
GMRY,
GMRD
www.oserha.org
Require vendor software, home devices,
and server. • The Home Telehealth data
in the HDR along with VistA data from
facility VistA systems is viewed using
VistAWeb, which is available through
the Computerized Patient Records
System (CPRS) by using the Remote
Data View (RDV) function.
OSEHR System-Architecture, Product Definition and Roadmap
Immunology Case Registry (ICR) version
2.1 was removed from service by patch
IMR*2.1*21 in October 2005. ICR and
the Hepatitis C Case Registry are now
supported by the Clinical Case Registries
(CCR) package. CCR version 1.5 was
released in February 2006.
Page 4-6
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
clinical
1
Yes
Laboratory
Lab Service,
Automated
Lab
Instruments
5.2
LR,
LA
clinical
1
Yes
Laboratory: Anatomic
Pathology
Lab Service
5.2
clinical
1
Yes
Laboratory: Blood
Bank
Lab Service
clinical
1
Yes
Laboratory: Electronic
Data Interchange
(LEDI)
Lab Service
www.oserha.org
Latest Patch
Comment
LR*5.2*410,
LA*5.2*68
The Automated Lab Instruments is a
separate package in the FOIA release;
however, it is documented together with
the Laboratory module and is considered
a part of the laboratory module.
LR
LR*5.2*529
Anatomic Pathology (AP) is divided into
four sections: Surgical Pathology,
Cytology (Cytopathology), Electron
Microscopy, and Autopsy Pathology.
5.2
LR
LR*5.2*72
The
national
release
of
patch
LR*5.2*408 on July 18, 2011 finalizes
the VHA transition from the VistA
Version 5.2 Blood Bank package to the
VistA Blood Establishment Computer
Software (VBECS) system. Sites with
VBECS have already disabled the VistA
v5.2 Blood Bank package when database
conversion was executed. With the
installation of this patch the Enter/Edit
options for VistA v5.2 Blood Bank are
permanently disabled.
5.2
LR
LA*5.2*46,
LR*5.2*222
Provides electronic messaging for Lab
Test Ordering and Lab Test Results
Reporting between VA Health Care
Facilities laboratories based on the
Health Level Seven (HL7) Version 2.3
Standard Specification and VISTA
Health Level Seven (HL7) Version 1.6
Standard Specification
OSEHR System-Architecture, Product Definition and Roadmap
LS,
Page 4-7
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
clinical
1
Yes
Laboratory: Emerging
Pathogens Initiative
(EPI)
Lab Service
5.2
LR
LR*5.2*132
Allow the Department of Veterans
Affairs (DVA) to track Emerging
Pathogens on the national level without
the necessity for additional local data
entry.
clinical
1
Yes
Laboratory: National
Laboratory Tests
(NLT) Documents and
LOINC Request Form
National
Laboratory
Test
5.2
NLT
LR*5.2*334
clinical
1
Yes
Laboratory: Point of
Care (POC)
Lab Service
5.2
LR
LA*5.2*67,
LR*5.2*290
Supports the Laboratory Health Level 7
(HL7) Point of Care (POC) interface
clinical
1
Yes
Laboratory: Universal
Interface
Lab Service
5.2
LR
LA*5.2*17,
LR*5.2*65
Designed to make the process of
interfacing automated instrument easier,
faster, and more reliable. Laboratory UI
uses the standard messaging protocol
Health
Level
Seven
(HL7)
to
communicate with all instruments.
clinical
1
Yes
Laboratory: VistA
Blood Establishment
Computer Software
(VBECS)
VBECS
1.0
VBECS
VBEC*1*24
The
national
release
of
patch
LR*5.2*408 on July 18, 2011 finalizes
the VHA transition from the VistA
Version 5.2 Blood Bank package to the
VistA Blood Establishment Computer
Software (VBECS) system. Sites with
VBECS have already disabled the VistA
v5.2 Blood Bank package when database
conversion was executed. With the
installation of this patch the Enter/Edit
options for VistA v5.2 Blood Bank are
permanently disabled.
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-8
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
clinical
1
Yes
Lexicon Utility
Lexicon
Utility
2.0
LEX,
GMPT
clinical
1
Yes
Medicine
Medicine
2.3
MC
MC*2.3*42
clinical
1
Yes
Mental Health
Mental Health
5.01
YS,
RUCL,
MR, YI,
PTX, YT
YS*5.01*104
clinical
1
Yes
Methicillin Resistant
Staph Aurerus
(MRSA)
Methicillin
Resistant
Staph Aurerus
Initiative
Reports
1.0
MMRS
MMRS*1*1
clinical
1
Yes
Mobile Electronic
Documentation (MED)
Text
Integration
Utility
1.0
TIU
TIU*1.0*244
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Latest Patch
Page 4-9
Comment
Contains a Windows GUI component YS_MHA.exe that uses RPC to
communicate
with
the
M-Server
component.
Mobile
Electronic
Documentation
(MED) is a Windows application MED.exe that allows the creation of
remote
documentation
without
connecting to VistA and then import of
that documentation into a note in
Computerized Patient Record System
(CPRS).
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
clinical
1
No
Nationwide Health
Information Network
Adapter (NHIN)
Nationwide
Health
Information
Network
1.0
NHIN
NHIN*1*1
The VA NHIN Gateway Adapter is a
HealtheVet-VistA application that acts as
a gateway between the VA and other
Health Information Exchanges (HIEs) to
share patient clinical records. The VA
NHIN Gateway Adapter is deployed as a
single, national instance at AITC (Austin
Information Technology Center). VistA
data is retrieved through the use of
VistALink-mediated RPC calls; HIE data
retrieved by the NHIN Adapter is
displayed by VistAWeb.
The FOIA
release contains only the M-Server
component and not the Gateway Adapter
software.
clinical
1
Yes
Nursing
Nursing
Service
4.0
NUR
NUR*4*42
clinical
1
Yes
Nutrition and Food
Service (NFS)
Dietetics
5.5
FH
FH*5.5*25
clinical
1
Yes
Oncology
Oncology
2.11
ONC
ONC*2.11*53
clinical
1
Yes
Patient Appointment
Info. Transmission
(PAIT)
Scheduling
5.3
SD
SD*5.3*290
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-10
Pursuant to Department of Veterans
Affairs
(VA)
Veterans
Health
Administration (VHA) Directive 10-95031, Nutrition and Food Service (NFS)
will be the official nomenclature used as
the new service name for Dietetic Service
in VHA central office and at VA
healthcare facilities.
Provide patient appointment wait time
statistics to the national database in
Austin, TX
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
clinical
1
Yes
Patient Care Encounter
(PCE)
PCE Patient
Care
Encounter
1.0
PX,
EFDP,
VSIT,
AUPN,
AUTN,
AUTT
PX*1*197
clinical
1
Yes
Patient Record Flags
Registration
5.3
DG
DG*5.3*650
clinical
1
Yes
Pharm: Automatic
Replenish / Ward
Stock (AR/WS)
Auto
Replenish
Ward Stock
2.3
PSGW,
PSI
PSGW*2.3*13
clinical
1
Yes
Pharm: Bar Code
Medication
Administration
(BCMA)
Bar Code
Medication
Administration
3.0
PSB,
ALPB
PSB*3*60
clinical
1
Yes
Pharm: Benefits
Management (PBM)
Pharmacy
Benefits
Management
4.0
PSU
PSU*4*18
clinical
1
Yes
Pharm: Consolidated
Mail Outpatient
Pharmacy (CMOP)
CMOP
2.0
PSX
PSX*2*71
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-11
Comment
Patient record flags are used to alert
VHA medical staff and employees of
patients
whose
behavior
and
characteristics may pose a threat either to
their safety, the safety of other patients,
or compromise the delivery of quality
health care. These flag assignments are
displayed during the patient look-up
process.
Contains a Windows GUI component BCMA.exe
that
uses
RPC
to
communicate
with
the
M-Server
component.
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
clinical
1
Yes
Pharm: Controlled
Substances
Controlled
Substances
3.0
PSD
PSD*3*71
clinical
1
Yes
Pharm: Data
Management (PDM)
Pharmacy
Data
Management
1.0
PSS
PSS*1*151
clinical
1
Yes
Pharm: Drug
Accountability
Drug
Accountability
3.0
PSA
PSA*3*71
clinical
1
Yes
Pharm: Inpatient
Medications
Inpatient
Medications
5.0
PSJ,
PSIV,
PSG
PSJ*5*223
clinical
1
Yes
Pharm: National Drug
File (NDF)
National Drug
File
4.0
PSN
PSN*4*263
clinical
1
Yes
Pharm: Outpatient
Pharmacy
Outpatient
Pharmacy
7.0
PSO,
APSP,
PSCST,
PSRX
PSO*7*381
clinical
1
Yes
Pharm: Prescription
Practices (PPP)
Pharmacy
Prescription
Practices
1.0
PPP
PPP*1*44
clinical
1
Yes
Primary Care
Management Module
(PCMM)
Registration &
Scheduling
5.3
SC
SD*5.3*41,
DG*5.3*84
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-12
Comment
Contains a Windows client GUI PCMM.exe
that
uses
RPC
to
communicate with the M server
component.
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
clinical
1
Yes
Prosthetics
Prosthetics
3.0
RMPR,
RMPO,
RMPS
RMPR*3*160
Contains a Windows GUI component ProsMenu.exe that uses RPC to
communicate
with
the
M-Server
component.
clinical
1
Yes
Quality Audiology and
Speech Analysis and
Reporting (QUASAR)
QUASAR
3.0
ACKQ,
ACK
ACKQ*3*18
clinical
1
Yes
Radiology / Nuclear
Medicine
Radiology
Nuclear
Medicine
5.0
RA
RA*5*47
clinical
1
No
RAI/MDS Electronic
Transmission
clinical
1
No
Remote Order Entry
System (ROES)
www.oserha.org
A web application for the transmission of
MDS data set from VAMCs to the Austin
Automation Center.
The MDS 2.0
records is retrieve from the Accu-Med
Services (AMS) Clinical Software suite,
a vendor SW which has been
implemented nationally, with a gateway
interface to import patient data from
VistA using standard HL7 messaging.
The RAI/MDS module does not have Msever components.
Remote Order
Entry System
(ROES)
3.0
RMPF,
RMPJ
OSEHR System-Architecture, Product Definition and Roadmap
The ROES 3.0 is a Web-based order
entry application hosted at the Denver
Distribution Center (DDC). It also has a
Windows component - ROES3.exe that
uses RPC to communicate with the M
server component to gather information
and initiate an interactive session to the
web application. The FOIA release
contains the M-server component of the
ROES.
Page 4-13
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
clinical
1
Yes
Scheduling
Scheduling
5.3
SD, SC
SD*5.3*504
clinical
1
Yes
Shift Handoff Tool
Shift Handoff
Tool
1.0
CRHD
CRHD*1*2
clinical
1
Yes
Social Work
Social Work
3.0
SOW,
SWBH,
SWFG
clinical
1
Yes
Spinal Cord
Dysfunction
Spinal Cord
Dysfunction
3.0
SPN
clinical
1
No
Standards &
Terminology Services
(STS)
clinical
1
Yes
Surgery
clinical
1
No
TBI-Traumatic Brain
Injury
www.oserha.org
Comment
Contains a Windows client GUI ShiftHandoffTool.exe initiated from the
CPRS Tools Menu.
SPN*2*26
Standards & Terminology Services (STS)
is
responsible
for
organizing,
formalizing, and maintaining the
terminology of the Veterans Health
Administration (VHA). Deployed on
Oracle Weblogic 11g platform.
Surgery
3.0
SR
SR*3*175
2.0
OSEHR System-Architecture, Product Definition and Roadmap
The Traumatic Brain Injury Registry
application (TBI Registry) supports the
maintenance of local and national
registries for clinical and resource
tracking of care for such Veterans. The
TBI web application is developed under
the MS .net platform.
Page 4-14
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
clinical
1
No
VistA Imaging System
Imaging
3.0
MAG,
ZMAG
MAG*3.0*104
VistA Imaging System includes several
components:
• Windows-based servers for image
storage
• VistA Hospital Information System
(HIS) Image Management Software
• Background Processor system and
software
• VistA Imaging workstation software
• DiskXtender Jukebox Software
•
Dicom
Gateway
The FOIA release contains the VistA HIS
Image Management component. The
Vista Imaging System uses the RPC to
communicate
with
the
M-server
component.
clinical
1
No
VistAWeb
13.0
WEBV
WEBV*1*22
VistAWeb, ASP.NET based, is an
intranet web application used to review
remote patient information found in
VistA, FHIE, HDR II, and NHIN.
Mirrors the reports behavior of the
CPRS.
VistAWeb uses RCP to
communicate with M-Server. It can be
accessed as a standalone app or initiated
via the CPRS GUI.
clinical
1
Yes
Vitals / Measurements
(GEN. MED. REC. VITALS)
General
Medical
Record Vitals
4.0
GMRV,
GMV
GMRV*5*26
Contain a Windows client - Vitals.exe
that uses RPC to communication to the
server.
clinical
1
Yes
Womens’ Health
Womens
Health
1.0
WV
WV*1*23
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-15
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Financial
Administrative
1
Yes
Accounts Receivable
(AR)
Accounts
Receivable
4.5
PRCA,
PRY, RC
PRCA*4.5*279
Financial
Administrative
1
Yes
Auto Safety Incident
Surv Track System
(ASISTS)
ASISTS
2.0
OOPS
OOPS*2*21
Financial
Administrative
1
Yes
Automated Information
Collection System
(AICS)
Automated
Information
Collection
System
3.0
IBD
IBD*3*62
Financial
Administrative
1
Yes
Automated Medical
Information Exchange
(AMIE)
Automated
Medical
Information
Exchange
2.7
DVBA
DVBA*2.7*175
Financial
Administrative
1
Yes
Clinical Monitoring
System
Clinical
Monitoring
System
1.0
QAM
Financial
Administrative
1
Yes
Compensation Pension
Records Interchange
(CAPRI)
Automated
Medical
Information
Exchange
2.7
DVBA
DVBA*2.7*35
Financial
Administrative
1
Yes
Current Procedural
Terminology (CPT)
CPT HCPCS
Codes
6.0
ICPT,
DGYA
ICPT*6*57
Financial
Administrative
1
Yes
Decision Support
System (DSS) Extracts
DSS Extracts
3.0
ECX
ECX*3*132
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-16
Comment
Contains a Windows GUI component ASISTS.exe that uses RPC to
communicate
with
the
M-Server
component.
The M-server component of CAPRI is
include in the AMIE package. The
Capri.exe (CAPRI GUI) is the main
Windows client component that uses
RPC to communication to the server
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Financial
Administrative
1
Yes
Diagnostic Related
Group (DRG) Grouper
DRG Grouper
18.0
ICD, IC
ICD*18*54
Financial
Administrative
1
Yes
EEO Complaint
Tracking
EEO
Complaint
Tracking
2.0
EEO
Financial
Administrative
1
Yes
Electronic Claims
Management Engine
(ECME)
E Claims
Management
Engine
1.0
BPS
BPS*1*10
Financial
Administrative
1
Yes
Engineering (AEMS /
MERS)
Engineering
7.0
EN, OFM
EN*7*90
Financial
Administrative
1
Yes
Enrollment Application
System
Enrollment
Application
System
1.0
EAS
EAS*1*103
Financial
Administrative
1
Yes
Equipment / Turn-In
Request
Equipment
Turn-In
Request
1.0
PRCN
Financial
Administrative
1
Yes
Event Capture
Event Capture
2.0
EC
EC*2*110
Financial
Administrative
1
Yes
Fee Basis
Fee Basis
3.5
FB
FB*3.5*121
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-17
Comment
Contain a Windows client - ECS GUI.exe
that uses RPC to communication to the
server.
Module
Grouping
Class
Core
FOIA
Module Name
Financial
Administrative
1
No
Fee Basis Claims
System (FBCS)
Financial
Administrative
1
Yes
Fugitive Felon
Program (FFP)
Financial
Administrative
1
Yes
Generic Code Sheet
(GCS)
Financial
Administrative
1
No
Health Eligibility
Center (HEC)
Financial
Administrative
1
Yes
Hospital Inquiry
(HINQ)
www.oserha.org
FOIA
Package
Name
Version
Name
Space
3.2
FBAA
Registration
5.3
DG
Generic Code
Sheet
2.0
GEC
2.0
IVMB
4.0
DVB
HINQ
OSEHR System-Architecture, Product Definition and Roadmap
Latest Patch
Comment
The Fee Basis Claims System (FBCS) is
a claims management system developed
by Complete Medical Systems (CMS) in
cooperation with DSS (Document
Storage Systems) and VR$ (VistA
Revenue Solutions). FBCS is designed to
be used in the Fee Basis Departments of
the Veteran Affairs Medical Centers
(VAMCs). It's a vendor SW by DSS, inc
- not included in FOIA release.
DG*5.3*485
Provide the functionality in support of PL
107-103, Section 505, which prohibits
provision of certain benefits to veterans
or their dependents that are classified as
fugitive felons
The Health Eligibility Center (HEC)
system sends eligibility data, enrollment
data, income data, and means test data to
the local VA Medical Centers (VAMCs)
using HL7 messaging. It is not part of
the FOIA release.
DVB*4*65
Page 4-18
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
Financial
Administrative
1
Yes
ICD-9-CM
Drg Grouper
18.0
ICD, IC
ICD*18*59
The International Classification of
Diseases, Clinical Modification (ICD-9CM) is a clinically modified statistical
classification system that arranges
diseases and injuries into groups
according to established criteria
Financial
Administrative
1
Yes
IFCAP
IFCAP
5.1
PRC, PRX
PRC*5.1*163
Financial
Administrative
1
Yes
Incident Reporting
Incident
Reporting
2.0
QAN
Financial
Administrative
1
Yes
Income Verification
Match (IVM)
Income
Verification
Match
2.0
IVM
Financial
Administrative
1
No
Insurance Capture
Buffer (ICB)
2.2
DSIV
Financial
Administrative
1
Yes
Integrated Billing (IB)
Integrated
Billing
2.0
IB, PRQ
IB*2*435
Financial
Administrative
1
Yes
Integrated Patient
Funds
Integrated
Patient Funds
4.0
PRPF
PRPF*4*3
Financial
Administrative
1
Yes
Library
Library
2.5
LBR,
LBRS
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
IVM*2*147
The Insurance Capture Buffer module is
an insurance card scanning and VistA
Buffer File update management system
designed to enhance the insurance data
collection and verification processes for
Veterans Affairs Medical Centers. It's a
vendor SW by DSS, inc - not included in
FOIA release.
Page 4-19
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Financial
Administrative
1
Yes
Occurrence Screen
Occurrence
Screen
3.0
QAO
QAO*3*8
Financial
Administrative
1
Yes
Patient Representative
Patient
Representative
2.0
QAC
Financial
Administrative
1
Yes
Personnel and
Accounting Integrated
Data (PAID)
PAID
4.0
PRS
PRS*4*110
Financial
Administrative
1
Yes
Police and Security
Police and
Security
1.0
ES
ES*1*46
Financial
Administrative
1
Yes
Quality Management
Integration Module
Quality
Assurance
Integration
1.7
QAQ
Financial
Administrative
1
Yes
Record Tracking
Record
Tracking
2.0
RT
Financial
Administrative
Vendor
No
Release of Information
(ROI) Manager
7.2
DSIR
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Comment
RT*2*46
The Release Of Information System
(ROI) is a Document Storage Systems,
Inc. (GUI) application that is designed to
provide health care facilities with an
intuitive, userfriendly Windows interface
for end-users to use to request patient
medical record information. The ROI
Manager is an application that uses "RPC
Broker" technology that permits the
facility users to retrieve clinical data
within the VistA System. It's a vendor
SW by DSS, inc - not included in FOIA
release.
Page 4-20
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
Financial
Administrative
1
Yes
Veterans Identification
Card (VIC/PICS)
Registration
5.3
DG
DG*5.3*679
The Veteran Identification Card (VIC)
replaces the embossed data card as a
means of identifying veteran patients
entitled to care and services at
Department of Veterans Affairs (DVA)
health care facilities.
Financial
Administrative
1
Yes
Voluntary Service
System (VSS)
Voluntary
Timekeeping
4.0
ABSV,
ABS
ABSV*4*21
Financial
Administrative
1
Yes
Wounded Injured and
Ill Warriors
Wounded
Injured and Ill
Warriors
1.0
WII
WII*1*1
HealtheVet
1
No
Clinical Information
Support System (CISS)
HealtheVet
1
Yes
Electronic Signature
(ESig)
Electronic
Signature
1.0
XOBE
HealtheVet
1
Yes
HealtheVet Web
Services Client
(HWSC)
Web Service
Client
1.0
XOBW
www.oserha.org
A Web-based portal application that
provides a central interface for users to
access information and applications
necessary for their roles. It is not part of
the FOIA release.
OSEHR System-Architecture, Product Definition and Roadmap
M-Server component of eSig
XOBW*1*2
Page 4-21
HWSC uses Caché’s Web Services
Client to invoke web service methods on
external servers and retrieve results. It
allows VistA to communicate with
Healthevet applications via web services.
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
HealtheVet
1
No
My HealtheVet
My
HealtheVet
1.0
MHV
MHV*1*6
MHV is an enterprise system, housed at
the Austin Automation Center (AAC).
The MHV Portal supports several portlets
or portal applications, some of which
integrate with VistA applications. The
My HealtheVet (MHV) VistA package
provides HL7 interfaces and integration
with various VistA applications in
support of these portlets. Users access
the MHV system via a web browser.
HealtheVet
1
No
National Utilization
Management
Integration (NUMI)
1'0
The National Utilization Management
Integration (NUMI) application is a webbased solution that automates utilization
review assessment and outcomes. It does
not have M-server components.
HealtheVet
1
No
Occupational Health
Record-keeping
System (OHRS)
1.2
The initial CISS partner system is the
Occupational Health Record-keeping
System
(OHRS),
a
Web-based
application that enables occupational
health staff to create, maintain, and
monitor medical records for VA
employees and generate national, VISN,
and site-specific reports. It does not have
M-server components.
HealtheVet
1
No
Patient Advocate
Tracking System
(PATS)
www.oserha.org
Patient
Representative
2.0
QAC
OSEHR System-Architecture, Product Definition and Roadmap
QAC*2.0*19
Page 4-22
The Patient Advocate Tracking System
(PATS) is a web-based application with a
centralized database and notification
function (email) for tracking patientrelated issues. The M-server component
is included in the FOIA Patient
Representative Package.
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
HealtheVet
1
No
Patient Service
Construct
Registration
2.0.0.8
DG
DG*5.3*557
Patient Service Construct (PSC) is a
composite service based on J2EE EJB
technology that provides a programmatic
interface for read-only access to patient
IDs, patient demographics, and eligibility
& enrollment information. PSC uses Mserver as its data store (files #2 and
#200).
HealtheVet
1
No
Person Service Lookup
Kernel,
Registration
4.0.4.4
XU, DG
XU*8.0*325,
DB*5.3*538
Person Service Lookup (PSL) provides a
graphical interface for patient and
provider searches and a service
component that connects to VistA via
VistALink 1.5. PSL uses M-server as its
data store (files #2 and #200).
HealtheVet
1
No
Person Services
Identity Management
www.oserha.org
2.2.1
OSEHR System-Architecture, Product Definition and Roadmap
Person Services (PS) is part of the
common business services layer as
prescribed by the HealtheVet logical
model. It acts as the authoritative source
of person administrative data and
formulates an abstraction layer between
applications and databases. It is
comprised of sub-services which support
the input/retrieval of data and personspecific functionality such as identity
management, demographics, lookup and
enumeration. PS also broadcasts person
data changes to subscribers and
synchronizes traits across systems of
interest and with VistA during transition
from Legacy VistA to HealtheVet VistA.
It is a J2EE web application on a
Weblogic platform. It does not have Mserver components.
Page 4-23
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
HealtheVet
1
No
Spinal Cord Injury and
Disorders Outcomes
(SCIDO)
Spinal Cord
Dysfunction
3.0
SPN
HealtheVet
1
No
VA Enrollment System
(VES)
Enrollment
Application
System
1.0
EAS
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Latest Patch
Comment
The Spinal Cord Injury and Disorders
Outcomes
(SCIDO)
3.0
Interim
application is part of the HealtheVet
platform, which converts the current
Spinal Cord Dysfunction (SCD) Registry
from a legacy command line system to a
client server platform with a graphical
user interface (GUI) and enhanced
capabilities. The new system is built on
the new Oracle/J2EE HealtheVet
architecture. The M-server component is
included in the FOIA Spinal Cord
Dysfunction Package.
EAS*1*71
Page 4-24
Enrollment System Redesign (ESR) V3.4
(a.k.a. HECMS) is the HealtheVet
replacement
system
for
the
decommissioned product known as HEC
(Health Eligibility Center, Atlanta)
Legacy. It is both a re-host of HEC
Legacy and in some instances (use
cases/features),
a
re-engineering.
HECMS allows staff at the HEC to work
more efficiently and determine patient
eligibility in a more timely manner.
Messaging with the VAMC (Department
of Veterans Affairs Medical Center)
allows updates to the enterprise
enrollment system to be shared with the
field. It is a J2EE web app deployed on
Weblogic. The M-server component is
included in the FOIA Enrollment
Application System Package.
Module
Grouping
Class
Core
FOIA
Module Name
HealtheVet
1
No
Veterans Personal
Finance System
(VPFS)
infrastructure
1
Yes
Capacity Management
Tools
Capacity
Management
Tools
2.0
KMPD
infrastructure
1
Yes
Duplicate Record
Merge: Patient Merge
Toolkit
7.3
XDR
infrastructure
1
No
FatKAAT
infrastructure
1
Yes
FileMan
infrastructure
1
No
FileMan Delphi
Components (FMDC)
www.oserha.org
FOIA
Package
Name
Version
Name
Space
Latest Patch
1.1.2
Comment
Veterans Personal Finance System
(VPFS) is the mini-banking system used
by the Veterans Health Administration
(VHA) to manage the accounts of VHA
patients in the VHA hospital system.
VPFS replaces the Personal Funds of
Patients (PFOP) system that was used
previously.
It is a J2EE web app
deployed on Weblogic and Oracle
Database 10g. It does not have M-server
components.
XT*7.3*23
Patient Merge provides an automated
method to eliminate duplicate patient
records within the VISTA database
Fat Client Kernel Authentication and
Authorization
-Stateless
session
Enterprise JavaBeans. It is not part of the
FOIA release.
VA FileMan
22.0
DI,
DM
1.0
FMDC
OSEHR System-Architecture, Product Definition and Roadmap
DD,
DI*22*165
The components encapsulate the details
of retrieving, validating and updating VA
FileMan data within a Delphi application.
The
Windows
FileMan
Dephi
components are not part of FOIA release.
Page 4-25
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
infrastructure
1
Yes
Health Data
Informatics
Health Data
Informatics
1.0
HDI
HDI*1*8
infrastructure
1
Yes
HL7 (VistA
Messaging)
Health Level
Seven
1.6
HL
HL*1.6*152
infrastructure
1
Yes
Institution File
Redesign (IFR)
Kernel
8.0
XU
XU*8.0*206
The Institution File Redesign (IFR)related software (i.e., Kernel Patch
XU*8.0*206) provides the mechanism to
standardize national entries in VistA's
INSTITUTION (#4) and FACILITY
TYPE
(#4.1)
master
files
and
automatically update and maintain
synchronization of these files at all sites
VHA-wide.
infrastructure
1
Yes
KAAJEE
Kernel, RPC
Broker
8.0, 1.1
XU
XU*8.0*265,
329, 337, 361,
430,
451,
XWB*1/1*35
Kernel Authentication and Authorization
for Java (2) Enterprise Edition
(KAAJEE) M Server Components
infrastructure
1
Yes
Kernel
Kernel
8.0
XU,A4A7,
USC, XG,
XIP, XLF,
XNOA,
XPD, XQ,
XVIR, ZI,
ZOSF,
ZOSV,
ZT,
ZU, %Z
XU*8*570
infrastructure
1
Yes
Kernel Delphi
Components (KDC)
Kernel
8.0
XU
XU*8*207
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-26
Comment
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
infrastructure
1
Yes
Kernel Toolkit
Toolkit
7.3
XT,
AWCM,
AWC,
XD, XIN,
XPAR,
XQAB,
XUC,
XUR,
ZIN,
ZTED
XT*7.3*123
infrastructure
1
Yes
Kernel Unwinder
Kernel
8.0
XQ
infrastructure
1
Yes
List Manager
List Manager
1.0
VALM
VALM*1*9
infrastructure
1
Yes
MailMan
MailMan
8.0
XM
XM*8*41
infrastructure
1
Yes
Master Patient
Index/Patient
Demographics
(MPI/PD)
Master Patient
Index VistA,
Clinical
Information
Resorce
Network
1.0
MPIF,
RG, MRF
MPIF*1*55,
RG*1*58
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Comment
The Unwinder is a utility that is used in
conjunction with the Protocol file (#101)
to create modular building blocks for
applications.
Page 4-27
The functionality in Master Patient Index
VistA and Patient Demographics
(PD)/CIRN have been merged in the
MPI/PD module.
Module
Grouping
Class
Core
FOIA
Module Name
infrastructure
3
No
Medical Domain Web
Services (MDWS)
infrastructure
1
Yes
M-to-M Broker
RPC Broker
1.1
XW B
XWB*1.1*28
The VistA M-to-M Broker is a new
implementation of the RPC Broker
offering Client/ Server functionality
resident solely within a VistA nonGraphical
User
Interface
(GUI)
environment. It enables the exchange of
VistA M-based data and business rules
between two VistA M servers, where
both servers reside on local and/or remote
VistA systems. Use the XWBM2MC
routine
infrastructure
1
Yes
Name Standardization
Kernel
8.0
XU
XU*8.0*134
Provides utilities that enable VISTA
applications to standardize the way
person names are entered and stored in
Veterans Health Administration (VHA)
databases.
www.oserha.org
FOIA
Package
Name
Version
Name
Space
Latest Patch
2.0
Comment
Medical Domain Web Services (MDWS)
is a suite of SOA middle-tier web
services that exposes medical domain
functionality, Medical Domain Objects
(MDO). MDWS will virtualize any
legacy Veterans Health Information
Systems and Technology Architecture
(VistA) Remote Procedure Call (RPC) as
a web service. The MDWS 2.0 is written
in C#, uses the Microsoft 2.0 .NET
Framework, and runs on Microsoft
Internet Information Services 6.0.
Although MDWS is not yet certified as
C1 software, MDWS received a waiver
from Systems Engineering for the C1
deployment of Suicide Hotline.
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-28
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
infrastructure
1
Yes
National Online
Information Sharing
(NOIS)
National
Online
Information
Sharing
1.1
FSC
infrastructure
1
No
National Patch Module
infrastructure
1
Yes
Network Health
Exchange (NHE)
Network
Health
Exchange
5.1
AFJX,
AFJ
infrastructure
1
Yes
Patient Data Exchange
(PDX)
Patient Data
Exchange
1.5
VAQ
infrastructure
1
Yes
Remote Procedure Call
(RPC) Broker
RPC Broker
1.1
XW B
infrastructure
1
Yes
Resource Usage
Monitor
Capacity
Management RUM
2.0
KMPR
infrastructure
1
Yes
Run-Time Library
Run Time
Library
2.1
RGUT
www.oserha.org
Latest Patch
A1AE
OSEHR System-Architecture, Product Definition and Roadmap
Comment
The National Patch Module (NPM) is a
software package that provides a
database for the distribution of software
patches and updates for the Department
of Veterans Affairs' Decentralized
Hospital Computer Program (DHCP).
Options are provided for systematic entry
and review of patches by developers,
review and release of patches by
verifiers, and display and distribution of
the released verified patches to the users.
ANRV*5*3
XWB*1.1*53
Page 4-29
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
Comment
infrastructure
1
Yes
Single Signon/User
Context (SSO/UC)
Kernel, RPC
Broker
8.0
XU
XU*8.0*265,
337,
361,
XWB*1.1*35,
40
SSO/UC provides a secure signon
architecture for Vista client/ server-based
applications.
For
example:
Care
Management, CPRS, Vitals
infrastructure
1
No
SlotMaster (Kernel
ZSLOT)
infrastructure
1
Yes
SQL Interface (SQLI)
infrastructure
1
Yes
Standard Files and
Tables
infrastructure
1
Yes
Statistical Analysis of
Global Growth
(SAGG)
SAGG Project
2.0
KMPS,
A1B5
infrastructure
1
Yes
Survey Generator
Survey
Generator
2.0
QAP
www.oserha.org
Slotmaster is a quick login utility for
VMS systems. SlotMaster is a
combination of items which include DCL
procedures and MUMPS routines. It is
not included in the FOIA release.
VA FileMan
22.0
DI
OSEHR System-Architecture, Product Definition and Roadmap
DI*21*38
VistA's SQLI software product (part of
VA FileMan), along with an M-to-SQL
Product purchased from a vendor (see
below), provides SQL access to your VA
FileMan data.
XU*999*3,
XU*8*105
Patche XU*999*3 provide instructions
for synchronizing the VISTA STATE file
(#5) and the AAC edit table. Patch
XU*8*105 designed to identify and
correct two data problems associated
with the following files: Patient (File #2),
Fee Basis Vendor (File #161.2), Person
(File #16), and HBHC Patient (File #631)
KMPS 2
Page 4-30
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Latest Patch
infrastructure
1
Yes
VistA Data Extraction
Framework (VDEF)
VDEF
1.0
VDEF
VDEF*1*3
infrastructure
1
Yes
VistALink
Foundations,
VistaLink,
VistaLink
Security
1.6
XOBU,
XOBV,
XOBS
XOBU
1.6,
XOBV*1.5*2,
XOBS 1.6
infrastructure
1
Yes
XML Parser (VistA)
M XML
Parser
1.1
MXML
XT*7.3*58
Unknown
1
Yes
Event Driven
Reporting
Event Driven
Reporting
Unknown
1
Yes
Interim Management
Support
Interim
Management
Support
Unknown
1
Yes
National VistA
Support
Unknown
1
Yes
Unknown
1
Yes
www.oserha.org
Comment
The FOIA release Foundataion package
contains common files and libraries used
by all the XOB* packages and menu
options
to
manage
site
parameters/operations.
VistALink
package handles system and RPC
requests. VistALink Security package
contains M-side security module.
EDR
Part of FOIA release,
documentation found in VDL.
1.05
ECT
Information for VAMC's management.
Part of FOIA release, but no
documentation found in VDL.
National
VistA Support
2.00
NVS
VHA national IT customer support
organization. Part of FOIA release, but
no documentation found in VDL.
NDBI
NDBI
1.0
A7R
National Database Integration. Part of
FOIA release, but no documentation
found in VDL.
Text Generator
(General Medical
Record-Generator)
General
Medical
RecordGenerator
3.0
GMRG
No documentation from VDL. It is used
by the Nursing Package.
OSEHR System-Architecture, Product Definition and Roadmap
Page 4-31
but
no
Module
Grouping
Class
Core
FOIA
Module Name
FOIA
Package
Name
Version
Name
Space
Unknown
1
Yes
Utilization
Management Rollup
Utilization
Management
Rollup
1.0
IBQ
Latest Patch
Part of FOIA release,
documentation found in VDL.
8192
8193
www.oserha.org
OSEHR System-Architecture, Product Definition and Roadmap
Comment
Page 4-32
but
no