Docstoc

OSEHRA System Architecture_ Product Description and Roadmap

Document Sample
OSEHRA System Architecture_ Product Description and Roadmap Powered By Docstoc
					Document Title:            Open-Source EHR System Architecture,
                           Product Definition and Roadmap




Date Submitted:     17 Sep 11 – Initial-Baseline 2011 System Architecture
Last Updated:       30 Oct 11 – Working-Draft     2011 System Architecture
Next Milestone:     17 Dec 11 – Verified-Baseline 2011 System Architecture


Requested Action:                 Please send suggestions for improvement to
                                  HufnagelS@OSEHRA.ORG , document editor


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 government-
developed 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
   28 Sep 11 – Add “Section 1.4 Anacronyms” and “Section 2.2 VistA Subsystems”
    3 Oct 11 – Start “Section Error! Reference source not found.4 Software Development Kit (SDK) for Future-
    State iEHR Architecture”
   30 Oct 30 – 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   References                                                                          10

1.3 Contract Deliverables                                                                 13
   1.3.1 System Architecture Approach (Task 5.9)                                          13
   1.3.2 Product Definition Approach (Task 5.11)                                          13

1.4   Acronyms                                                                            15

1.5 Legend, Meta-Model and Glossary                                                       18
   1.5.1 Color Conventions for System Architecture Model                                  18
   1.5.2 Glossary for System Architecture Model Elements and Constructs                   19


2     PRODUCT DEFINITION AND ROADMAP                                                     23

2.1 OSEHR Components                                                                      23
   2.1.1 Clinical                                                                         26
   2.1.2 Infrastructure                                                                   27
   2.1.3 Financial-Administrative                                                         27
   2.1.4 HealtheVet                                                                       27

2.2 VistA Subsystems                                                                     2-1
   2.2.1  Vista 1.0                                                                      2-1
   2.2.2  Vista 1.5 (aka HealtheVet)                                                     2-4
   2.2.3  Master Patient Index (MPI)                                                     2-7
   2.2.4  Health Eligibility Center (HEC)                                               2-11
   2.2.5  External Entities                                                             2-14
   2.2.6  DoD Information Sharing                                                       2-16
   2.2.7  Corporate Databases                                                           2-19
   2.2.8  Centralized Data Repositories                                                 2-21
   2.2.9  Health Data Repository (HDR)                                                  2-23
   2.2.10    Corporate Data Warehouse (CDW)                                             2-34

2.3 GT.M Subsystems                                                                     2-36
   2.3.1 GT.M Language Subsystem                                                        2-37
   2.3.2 GT.M Database Subsystem                                                        2-37
   2.3.3 GT.M Tools and Utility Subsystem                                               2-38
   2.3.4 GT.M-LINUX Operating System                                                    2-39
   2.3.5 Other (Optional) GT.M/LINUX Components                                         2-39

2.4   Caché Subsystems                                                                  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.1   Caché Development Environment                                              2-40
    2.4.2   Caché Database Subsystem                                                   2-40
    2.4.3   Caché Tools and Utilities Subsystem                                        2-41
    2.4.4   Caché-Windows Operating System                                             2-42
    2.4.5   Other (Optional) Caché/Windows Components                                  2-43

2.5 Product Roadmap                                                                    2-43
   2.5.1 2011 System Architecture (Conceptual View)                                    2-44
   2.5.2 Future-State Architecture (Conceptual View)                                   2-45
   2.5.3 Plan of Actions and Milestones (POA&M)                                        2-47


3     SYSTEM ARCHITECTURE (SA)                                                        3-50

3.1 Clinical                                                                           3-51
   3.1.1  ADT-Admission, Discharge, Transfer/Registration                              3-52
   3.1.2  Ambulatory Care Reporting                                                    3-55
   3.1.3  AMT-Anticoagulation Management Tool                                          3-59
   3.1.4  ASCD-Automated Service Connected Designation                                 3-59
   3.1.5  Beneficiary Travel                                                           3-60
   3.1.6  Blind Rehabilitation                                                         3-61
   3.1.7  Care Management                                                              3-62
   3.1.8  Clinical Case Registries                                                     3-63
   3.1.9  Clinical Procedures                                                          3-66
   3.1.10    CHDR-Clinical/ Health Data Repository                                     3-68
   3.1.11    CPRS-Computerized Patient Record System                                   3-70
   3.1.12    CPRS: ART-Adverse Reaction Tracking                                       3-72
   3.1.13    CPRS: ASU-Authorization Subscription Utility                              3-73
   3.1.14    CPRS: Clinical Reminders                                                  3-74
   3.1.15    CPRS: Consult/ Request Tracking                                           3-77
   3.1.16    CPRS: Health Summary                                                      3-77
   3.1.17    Electronic Wait List                                                      3-79
   3.1.18    CPRS: Problem List                                                        3-82
   3.1.19    CPRS: TIU-Text Integration Utility                                        3-82
   3.1.20    Dentistry                                                                 3-84
   3.1.21    EDIS-Emergency Department Integration Software                            3-85
   3.1.22    FIM-Functional Independence Measurement                                   3-86
   3.1.23    Group Notes                                                               3-88
   3.1.24    HDR-Hx - HDR-Historical                                                   3-89
   3.1.25    HBPC-Home Based Primary Care                                              3-91
   3.1.26    Home Telehealth                                                           3-93
   3.1.27    ICR-Immunology Case Registry                                              3-94
   3.1.28    IRT-Incomplete Records Tracking                                           3-95
   3.1.29    Intake and Output                                                         3-96
   3.1.30    Laboratory                                                                3-97
   3.1.31    Laboratory: Anatomic Pathology                                            3-98
   3.1.32    Laboratory: Blood Bank                                                   3-100
   3.1.33    Laboratory: Blood Bank Workarounds                                       3-100
   3.1.34    LEDI-Laboratory: Electronic Data Interchange                             3-101
   3.1.35    EPI-Laboratory: Emerging Pathogens Initiative                            3-102
   3.1.36    Laboratory: Howdy Computerized Phlebotomy Login Process                  3-103
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap   Page v
  3.1.37     Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form    3-104
  3.1.38     POC-Laboratory: Point of Care                                                   3-105
  3.1.39     Laboratory: Universal Interface                                                 3-106
  3.1.40     VBECS-Laboratory: VistA Blood Establishment Computer Software                   3-109
  3.1.41     Lexicon Utility                                                                 3-110
  3.1.42     Medicine                                                                        3-113
  3.1.43     Mental Health                                                                   3-115
  3.1.44     MH: Addiction Severity Index                                                    3-118
  3.1.45     MRSA-Methicillin Resistant Staph Aurerus                                        3-120
  3.1.46     MED-Mobile Electronic Documentation                                             3-120
  3.1.47     NHIN-Nationwide Health Information Network Adapter                              3-121
  3.1.48     Nursing                                                                         3-122
  3.1.49     NFS-Nutrition and Food Service                                                  3-123
  3.1.50     Oncology                                                                        3-125
  3.1.51     PAIT-Patient Appointment Information Transmission                               3-126
  3.1.52     PADP-Patient Assessment Documentation Package                                   3-128
  3.1.53     PCE-Patient Care Encounter                                                      3-128
  3.1.54     Visit Tracking                                                                  3-130
  3.1.55     Patient Record Flags                                                            3-131
  3.1.56     AR/WS-Pharmacy: Automatic Replenishment/ Ward Stock                             3-132
  3.1.57     BCMA-Pharmacy: Bar Code Medication Administration                               3-133
  3.1.58     PBM-Pharmacy: Benefits Management                                               3-135
  3.1.59     Pharmacy: Consolidated Mail Outpatient Pharmacy                                 3-137
  3.1.60     Pharmacy: Controlled Substances                                                 3-138
  3.1.61     Pharmacy: Data Management                                                       3-140
  3.1.62     Pharmacy: Drug Accountability                                                   3-142
  3.1.63     Pharmacy: Inpatient Medications                                                 3-143
  3.1.64     Pharmacy: National Drug File                                                    3-147
  3.1.65     Pharmacy: Outpatient Pharmacy                                                   3-149
  3.1.66     PPP-Pharmacy: Pharmacy Prescription Practices                                   3-155
  3.1.67     PCMM-Primary Care Management Module                                             3-156
  3.1.68     Prosthetics                                                                     3-158
  3.1.69     QUASAR-Quality: Audiology And Speech Analysis And Reporting                     3-161
  3.1.70     Radiology/ Nuclear Medicine                                                     3-162
  3.1.71     RAI/MDS-Resident Assessment Instrument/ Minimum Data Set                        3-164
  3.1.72     ROES-Remote Order Entry System                                                  3-165
  3.1.73     Scheduling                                                                      3-166
  3.1.74     Shift Handoff Tool                                                              3-168
  3.1.75     Social Work                                                                     3-169
  3.1.76     Spinal Cord Dysfunction                                                         3-171
  3.1.77     STS-Standards & Terminology Services                                            3-172
  3.1.78     Data Standardization                                                            3-174
  3.1.79     Terminology Services                                                            3-175
  3.1.80     Surgery                                                                         3-176
  3.1.81     TBI-Traumatic Brain Injury                                                      3-179
  3.1.82     Virtual Patient Record                                                          3-179
  3.1.83     VistA Imaging System                                                            3-180
  3.1.84     VistAWeb                                                                        3-183
  3.1.85     VIST-Visual Impairment Service Team                                             3-184
  3.1.86     Vitals/ Measurements                                                            3-185

Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap         Page vi
  3.1.87      Womens Health                                                                                 3-187

3.2      Financial-Administrative                                                                           3-191
   3.2.1    AR-Accounts Receivable                                                                          3-194
   3.2.2    ASISTS-Automated Safety Incident Surveillance Tracking System                                   3-197
   3.2.3    AICS-Automated Information Collection System                                                    3-199
   3.2.4    AMIE-Automated Medical Information Exchange                                                     3-200
   3.2.5    Clinical Monitoring System                                                                      3-201
   3.2.6    CAPRI-Compensation and Pension Records Interchange                                              3-202
   3.2.7    CPT-Current Procedural Terminology                                                              3-204
   3.2.8    DSS-Decision Support System Extracts                                                            3-205
   3.2.9    DRG-Diagnostic Related Group Grouper                                                            3-206
   3.2.10      ECME-Electronic Claims Management Engine                                                     3-208
   3.2.11      AEMS/MERS-Engineering                                                                        3-210
   3.2.12      EAS-Enrollment Application System                                                            3-213
   3.2.13      Equipment/ Turn-In Request                                                                   3-214
   3.2.14      Event Capture                                                                                3-215
   3.2.15      Fee Basis                                                                                    3-217
   3.2.16      FFP-Fugitive Felon Program                                                                   3-219
   3.2.17      GCS-Generic Code Sheet                                                                       3-220
   3.2.18      HEC-Health Eligibility Center                                                                3-222
   3.2.19      HINQ-Hospital Inquiry                                                                        3-225
   3.2.20      ICD-9-CM                                                                                     3-227
   3.2.21      IFCAP-Integrated Funds Distribution, Control Point Activity, Accounting, and Procurement     3-228
   3.2.22      Incident Reporting                                                                           3-231
   3.2.23      IVM-Income Verification Match                                                                3-232
   3.2.24      IB-Integrated Billing                                                                        3-234
   3.2.25      Integrated Patient Funds                                                                     3-239
   3.2.26      Library                                                                                      3-240
   3.2.27      Occurrence Screen                                                                            3-242
   3.2.28      Patient Representative                                                                       3-245
   3.2.29      PAID-Personnel and Accounting Integrated Data                                                3-249
   3.2.30      Police and Security                                                                          3-250
   3.2.31      Quality Management Integration Module                                                        3-253
   3.2.32      Record Tracking                                                                              3-254
   3.2.33      ROI-Release of Information Manager                                                           3-255
   3.2.34      VIC/PICS-Veteran Identification Card                                                         3-256
   3.2.35      VSS-Voluntary Service System                                                                 3-258
   3.2.36      Wounded Injured and Ill Warriors                                                             3-259

3.3 Infrastructure                                                                                          3-260
   3.3.1  CMT-Capacity Management Tools                                                                     3-262
   3.3.2  Duplicate Record Merge                                                                            3-262
   3.3.3  E3R-Electronic Error and Enhancement Reporting                                                    3-265
   3.3.4  EELS-Enterprise Exception Log Service                                                             3-265
   3.3.5  FatKAAT                                                                                           3-265
   3.3.6  VA FileMan                                                                                        3-266
   3.3.7  FMDC-FileMan Delphi Components                                                                    3-269
   3.3.8  Health Data Informatics                                                                           3-270
   3.3.9  Health Level Seven (HL7) (VistA Messaging)                                                        3-272
   3.3.10    IFR-Institution File Redesign                                                                  3-275
Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap                       Page vii
  3.3.11     KAAJEE-Kernel Authentication & Authorization for Java 2 Enterprise Edition     3-278
  3.3.12     Kernel                                                                         3-283
  3.3.13     KDC-Kernel Delphi Components                                                   3-285
  3.3.14     Kernel Toolkit                                                                 3-285
  3.3.15     Kernel Unwinder                                                                3-287
  3.3.16     List Manager                                                                   3-288
  3.3.17     M-to-M Broker                                                                  3-289
  3.3.18     MailMan                                                                        3-291
  3.3.19     MPI-Master Patient Index                                                       3-293
  3.3.20     MDWS-Medical Domain Web Services                                               3-297
  3.3.21     Name Standardization                                                           3-298
  3.3.22     NOIS-National Online Information Sharing                                       3-300
  3.3.23     National Patch Module                                                          3-300
  3.3.24     NHE-Network Health Exchange                                                    3-301
  3.3.25     PDX-Patient Data Exchange                                                      3-302
  3.3.26     RPC-Remote Procedure Call Broker                                               3-304
  3.3.27     Resource Usage Monitor                                                         3-305
  3.3.28     SSO/UC-Single Signon/User Context                                              3-306
  3.3.29     SlotMaster (Kernel ZSLOT)                                                      3-307
  3.3.30     SQLI-SQL Interface                                                             3-308
  3.3.31     Standard Files and Tables                                                      3-311
  3.3.32     SAGG-Statistical Analysis of Global Growth                                     3-312
  3.3.33     Survey Generator                                                               3-313
  3.3.34     STK-System Toolkit                                                             3-315
  3.3.35     VDEF-VistA Data Extraction Framework                                           3-316
  3.3.36     VistALink                                                                      3-316
  3.3.37     XML Parser (VistA)                                                             3-318

3.4 HealtheVet                                                                              3-320
   3.4.1  CISS-Clinical Information Support System                                          3-322
   3.4.2  ESig-Electronic Signature                                                         3-323
   3.4.3  HWSC-HealtheVet Web Services Client                                               3-324
   3.4.4  My HealtheVet                                                                     3-326
   3.4.5  NUMI-National Utilization Management Integration                                  3-328
   3.4.6  OHRS-Occupational Health Record-keeping System                                    3-330
   3.4.7  PATS-Patient Advocate Tracking System                                             3-331
   3.4.8  Person Services                                                                   3-333
   3.4.9  Registries                                                                        3-334
   3.4.10    SCIDO-Spinal Cord Injury and Disorders Outcomes                                3-335
   3.4.11    VES-VA Enrollment System                                                       3-337
   3.4.12    VPFS-Veterans Personal Finance System                                          3-340




Open Source Electronic Health Record Custodial Agent (OSEHRA)
Document Title: Open Source EHR System Architecture, Product Definition and Roadmap       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 Meta-
  Model 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
              17-Dec-11 OSEHR Verified-2011-Baseline System-Architecture
              17-Mar-12 “Strawman” OSEHR Product Definition & Roadmap
              17-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., weekly) working draft updates are published at
  www.OSEHRA.org , under the Architecture Working Group; also see
  http://architecture.OSEHRA.org. 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 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.
  www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap   Page 10
   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
    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:
    - VA Software Development Standards for VistA
    - VA Interface Control Registrations (ICRs)
   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.

Internal VA web site links:
 See, for test services web site: http://vaww.oed.portal.va.gov/engineering/testing/default.aspx


www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap              Page 11
   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.3 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
           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.3.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.3.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
                                                                  CIS       Clinical Information Systems
1.4 Acronyms
                                                                  CMOP      Consolidated Mail Outpatient Pharmacy
AA       Authentication and Authorization
                                                                  CMS       Centers for Medicare and Medicaid Services
ACOS     American College of Surgeons
                                                                  COC       Commission on Cancer
ACOS     Associate Chief of Staff
                                                                  COTS      Commercial-off-the-Shelf
ACRP     Ambulatory Care Reporting Program
                                                                  CP        Clinical Procedures
ADC      Active Dual Consumers
                                                                  CPM       Critical Path Method
ADR      Administrative Data Repository
                                                                  CPRS      Computerized Patient Record System
ADR      Adverse Drug Reactions
                                                                  CPT       Current Procedural Terminology
ADT      Admission/Discharge/Transfer
                                                                  CPWM      Compensation and Pension Worksheet Module
AEMS/M ERS Automated Engineering Management
                                                                  CRUD      Create, Read, Update and Deactivate
         System/Medical Equipment Reporting Systems
                                                                  CSAR      Controlled Substance Administration Record
AICS     Automated Information Capture System
                                                                  CS idM    Common Services Identity Management
AICS     Automated Information Collection System
                                                                  CS/OS     Common Services/Organization Service
AITS     Austin Information Technology Center
                                                                  CS/PS     Common Services/Person Service
AJCC     American Joint Commission on Cancer
                                                                  D&PPM     Drug and Pharmaceutical Products Management
AMIE     Automated Medical Information Exchange
                                                                  DBIAs     Data Base Integration Agreements
AMS      Acc-Med Services
                                                                  DCHP      Decentralized Hospital Computer Program
ANSI     American National Standards Institute
                                                                  DDC       Denver Distribution Center
API      Application Program Interface
                                                                  DHCP      Decentralized Hospital Computer Program
APs      Associate Primary Providers
                                                                  DICOM     Digital Imaging and Communications in Medicine
API      Application Programmers Interface
                                                                  DUSOI     Duke University Severity of Illness Index
AR       Accounts Receivable
                                                                  DLL       Dynamic Link Library
ARAMIS American Rheumatology Associations Medical
                                                                  DMC       Debt Management Center
         Information System
                                                                  DMI       Data Migration Initiative
ART      Adverse Reaction Tracking
                                                                  DNR       Do Not Resuscitate
ART      Allergy/Adverse Reaction Tracking
                                                                  DNS       Domain Name Service
AR/WS    Automatic Replenishment/Ward Stock
                                                                  DoD       Department of Defense
ASCII    American Standard Code for Information Interchange
                                                                  DRG       Diagnostic Related Group
ASIA     American Spinal Injury Association
                                                                  DRG       Inpatient Care Grouping
ASI-MV   Addiction Severity Index Multimedia Version
                                                                  DSD       Delivery Service Delegate
ASISTS   Automated Safety Incident Surveillance Tracking
                                                                  DSM       Diagnostic and Statistical Manual of Mental Disorders
         System
                                                                  DSM-IV    Diagnostic and Statistical Manual of Metal Disorders
ASU      Authorization/Subscription Utility
                                                                  DSS       Decision Support Decision
BMA      Bone Marrow Aspirates
                                                                  DUE       Drug Use Evaluation
BMB      Bone Marrow Biopsies
                                                                  DUR       Drug Utilization Review
BCMA     Bar Code Medication Administration
                                                                  DVA       Department of Veterans Affairs
BDK      Broker Developer Kit
                                                                  EAS       Enrollment Application System
BHIE     Bi-Directional Health Information Exchange
                                                                  ECG       Electrocardiogram
BRC      Blind Rehabilitation Centers
                                                                  ECME      Electronic Claims Management Engine
BROS     Blind Rehabilitation Outpatient Specialist
                                                                  EDI       Expanded Disability Status Scales
BSE      Broker Security Enhancement
                                                                  EDSS      Electronic Data Interchange
C&P      Compensation &Pension
                                                                  EEOB      Electronic Explanation of Benefits
CAIP     Cross-Application Integration Protocol
                                                                  EGD       Esophageal Gastrodoudenoscopy
CAPRI    Compensation and Pension Records Interchange
                                                                  EIS       Enterprise Information System
CBO      Chief Business Office
                                                                  EM        Electron Microscopy
CCOW     Clinical Context Object Workgroup
                                                                  ERCP      Endoscopic Retrograde Cholangiogram and
CCPC     Consolidated Copayment Processing Center
                                                                            Pancreatogram
CCSHS    Center for Cooperative Studies in Health Services
                                                                  ESN       Enterprise Service Network
CCR      Clinical Case Registries
                                                                  FAM       Functional Assessment Measure
CDC      Center for Disease Control
                                                                  FatKAAT   Fat-Client Kernel Authentication
CDR      Cost Distribution Report
                                                                  FDA       Food and Drug Administration
CHART    Craig Handicap Assessment and Reporting
                                                                  FHIE      Federal Health Information Exchange
         Technique
                                                                  FIM       Functional Independence Measure
CHDR     Clinical/Health Data Repository

www.oserha.org                                          OSEHR System-Architecture, Product Definition and Roadmap                   Page 15
FIPS     Federal Information Processing Standards                     JMS       Java Messaging Service
FMS      Financial Management System                                  JPTA      Joint Patient Tracking Application
FOIA     Freedom of Information Act                                   J2EE      Java 2 Enterprise Edition
FORDS    Facility Oncology Registry Data Standards                    KAAJEE    Kernel Authentication and Authorization for J2EE
FPDS     Federal Procurement Data System                              KDC       Kernel Delphi Components
FTEE     Full-Time Employee Equivalent                                KIDS      Kernel Installation and Distribution System
GAF      Global Assessment of Functioning                             LDSI      Laboratory Data Sharing Initiative
GEC      Geriatric Care Referral                                      LDSI      Lab Data Sharing Interoperability
GUI      Graphical User Interface                                     LEDI      Laboratory Electronic Data Interchange
GWOT     Global War on Terror                                         LIS       Laboratory Information Systems
HAIISS   Healthcare Associated Infection and Influenza                LM        List Manager
         Surveillance System                                          MAS       Medical Administration Service
HBHC     Home Based Health Care                                       MCCF      Medical Care Collections Fund
HCPCS    Healthcare Common Procedure Coding System                    MDD       Major Mood Disorder
HDR      Health Data Repository                                       MEM       Message Exception Manager
HDR DW Data Warehouse                                                 MHA       VistA Mental Health Assistant
HDR Hx   Historical Data                                              MHV       My HealtheVet
HDR IMS Interim Messaging Service                                     MLLP      Minimum Lower Level Protocol
HDR II   Definitive HDR                                               MPI       Master Patient Index
HDS      Health Data Systems                                          MPI/PD    Master Patient Index/Patient Demographics
HEC      Health Eligibility Center                                    MSADBAA   Microsoft Active Directory-based Authentication and
HINQ     Hospital Inquiry                                                       Authorization
HIPAA    Health Insurance Portability and Accountability Act          MSH       Message Header
HISA     Home Improvement Structural Alterations                      MUMPS     Massachusetts General Hospital Utility Multi-
HITS     Health IT Sharing                                                      Programming System
HIV      Human Immunodeficiency Virus                                 N&FS      Nutrition and Food Service
HLLP     Hybrid Lower Level Protocol                                  NANDA     North American Nursing Diagnosis Association
HLO      Health Level Seven Optimized                                 NDC       National Drug Code
HL7      Health Level Seven                                           NDS       Naming Directory Service
HOST     Hybrid Open System Technology                                NHE       Network Health Exchange
HSR&D    Health Services Research and Development                     NPCD      National Patient Care Database
HWSC     HealtheVet Web Services Client                               NCPDP     National Council for Prescription Drug Programs
ICN      Integration Control Number                                   NPI       National Provider Identifier
IMDQ     Identity Management Data Quality                             NSQIP     National Surgical Quality Improvement Program
I&O      Intake and Output                                            NTE       Network Health Exchange
IB       Integrated Billing                                           NTRT      New Term Rapid Turnaround
ICD-9    International Classification of Diseases                     O/E       Observed –to-Expected
ICD-9-CM International Classification of Diseases – 9th Edition       OIF/OEF   Operation Iraqi Freedom/Operation Enduring
         – Clinical Modification                                                Freedom
ICR      Immunology Case Registry                                     OS        Organization Service
IDMC     Information Data Management Committee                        OSHA      Occupational Safety & Health Administration
IFCAP    Integrated Funds Control, Accounting and                     OTC       Over The Counter
         Procurement                                                  PACS      Picture Archiving Communication Systems
IHD      Ischemic Heart Disease                                       PAID      Personnel and Accounting Integrated Data
IMDQ TK Identity Management Data Quality Toolkit                      PATS      Patient Advocate Tracking System
IP       Internet Protocol                                            PBM       Pharmacy Benefits Management
IRM      Information Resources Management                             PBM       Pharmacy Benefits Management Strategic Health
IRS      Internal Revenue Service                                               Group
IRT      Incomplete Records Tracking                                  PCE       Patient Care Encounter
IT       Information Technology                                       PCE       Patient Care Evaluations
IV       Intravenous                                                  PCMM      Primary Care Management Module
IVM      Income Verification Match                                    PCP       Primary Care Provider
JCAHO    Joint Commission on Accreditation of Healthcare              PDHRA     Post Deployment Health Reassessments
         Organizations                                                PDM       Pharmacy Data Management


www.oserha.org                                              OSEHR System-Architecture, Product Definition and Roadmap                 Page 16
PDTS    Pharmacy Data Transaction Service                     SSA      Social Security Administration
PDX     Patient Data Exchange                                 SSD      Secure Software Development
PICS    Patient Image Capture Software                        SSO/UC   Single Sign-On/User Context
PIMS    Patient Information Management System                 SSPIs    Security Service Provider Interfaces
PPDHA   Pre and Post Deployment Health Assessments            STS      Standards & Terminology Services
PPP     Pharmacy Prescription Practices                       T&L      Time and Leave
PS      Person Service                                        TBI      Traumatic Brain Injury
PSC     Person Service Construct                              TCP      Transmission Control Protocol
PSD     Person Service Demographics                           TCP/IP   Transmission Control Protocol/Internet Protocol
PSL     Person Service Lookup                                 TF       Treating Facilities
PTF     Patient Treatment File                                TIU      Text Integration Utility
QUASAR  Quality: Audiology and Speech Analysis and            TMDS     Theatre Medical Data System
        Reporting                                             UD       Unit Dose
QUERI   Quality Enhancement Research Initiative               UI       User Interface
RAID    Rapid Application Interface Development               VA       Department of Veterans Affairs
RAI/MDS Resident Assessment Instrument/Minimum Data Set       VACIB    VA Capital Investment Board
RAPs    Resident Assessment Protocols                         VALNET   VA Library Network
RDI     Remote Data Operability                               VAMC     Veterans Administration Medical Centers
ROs     Regional Offices                                      VBA      Veterans Benefits Administration
ROES    Remote Order Entry System                             VDEF     VistA Data Extraction Framework
RPC     Remote Procedure Call                                 VDL      Virtual Due List
RUG-III Resource Utilization Groups                           VERA     Veterans Equitable Resource Allocation
RUG     Long Term Care Grouping                               VETS     VHA Enterprise Terminology Services
SADR    Standard Ambulatory Data Record                       VHA      Veterans Health Administration
S-BAR   Situation, Background, Assessment,                    VIC      Veteran Identification Card
        Recommendations                                       VIE      VistA Interface Engine
SCD     Spinal Cord Dysfunction                               VISN     Veterans Integrated Services Network
SCS     Subscription Control Service                          VistA    Veterans Health Information Systems and
SD&D    System Design & Development                                    Technology Architecture
SDDM    Site Demographic Data Migration                       VPFS     Veterans Personal Finance System
SDOs    Standards Development Organizations                   VPID     VA-wide Person Identifier
SEER    Surveillance, Epidemiology, and End Results           VSS      Voluntary Service System
        Reporting                                             VTA      Veterans Tracking Application
SNOMED CT Systematized Nomenclature of Medicine –             VTK      Voluntary Timekeeping System
        Clinical Terminology                                  VUID     Veteran’s Health Administration Unique Identifier
SOA     Service Oriented Architecture                         WHO      World Health Organization
SOCS    Security and Other Common Services                    XML      Extensible Markup Language
SP      Surgical Pathology




www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 17
1.5 Legend, Meta-Model and Glossary
Figure 1-1 shows the OSEHRA-VistA meta-model; its coloring conventions are described in Section
1.5.1 and its elements and constructs are defined in Section 1.5.2.




                  Figure 1-1 OSEHR System Architecture (SA) Meta-Model

1.5.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 “UML-
Node” 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.5.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
         5. Print Active by Subscriber Package Option
         6. Start with subscriber package: QAM to QAMZ


www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap               Page 20
   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 following:
     XU, A4A7, USC, XG, XIP, XLF, XNOA, XPD, XQ, XVIR, ZI, ZOSF, ZOSV, ZT, ZU, %Z, -XQAB, -XUC, -XUR, -



www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 21
    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
    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.

www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 22
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.

2.1 OSEHR Components
 class OSEHR Product Definition


      VistA 1.0:                                                          OSEHR                                                             VistA 1.0:
       Clinical                            has-a                                                          has-a                           Infrastructure
                   81                                                                                                                37


                                                                          1   1
                                           has-a                                                          has-a




      VistA 1.5:   12                                     runs with                                                                  36     VistA 1.0:
                                                                                   runs with
      HealtheVet                                                                                                                          Administrativ e-
                                                                                                                                            Financial




                                      Cache        0..1                                        0..1
      Database                                                                                             GT.M                             Database
      Subsystem      has-a                                                                                                   has-a          Subsystem




                             has-a              has-a                                            has-a               has-a


                   Language                          Utility                        Language                              Utility
                   Subsystem                       Subsystem                        Subsystem                           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 enterprise-
wide information system built around an Electronic Health Record (EHR), used

www.oserha.org                                                    OSEHR System-Architecture, Product Definition and Roadmap                                  Page 23
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.

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.



www.oserha.org                         OSEHR System-Architecture, Product Definition and Roadmap   Page 24
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,
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-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.




www.oserha.org                        OSEHR System-Architecture, Product Definition and Roadmap   Page 25
Packages/Modules
This section lists the 168 OSEHRA packages/modules,          39. Laboratory: Universal Interface
which comprise the system codebase, documented at the        40. Laboratory: VistA Blood Establishment Computer
VistA Documentation Library (VDL) at                             Software (VBECS)
http://www.va.gov/vdl/                                       41. Lexicon Utility
                                                             42. Medicine
2.1.1    Clinical                                            43. Mental Health
1.  Admission Discharge Transfer (ADT)                       44. Methicillin Resistant Staph Aurerus (MRSA)
2.  Ambulatory Care Reporting                                45. Mobile Electronic Documentation (MED)
3.  Anticoagulation Management Tool (AMT)                    46. Nationwide Health Information Network Adapter
4.  Automated Service Connected Designation (ASCD)               (NHIN)
5.  Beneficiary Travel                                       47. Nursing
6.  Blind Rehabilitation                                     48. Nutrition and Food Service (NFS)
7.  Care Management                                          49. Oncology
8.  Clinical Case Registries                                 50. Patient Appointment Info. Transmission (PAIT)
9.  Clinical Procedures                                      51. Patient Assessment Documentation Package (PADP)
10. Clinical/Health Data Repository (CHDR)                   52. Patient Care Encounter (PCE)
11. Computerized Patient Record System (CPRS)                53. Patient Record Flags
12. CPRS: Adverse Reaction Tracking (ART)                    54. Pharm: Automatic Replenish / Ward Stock (AR/WS)
13. CPRS: Authorization Subscription Utility (ASU)           55. Pharm: Bar Code Medication Administration (BCMA)
14. CPRS: Clinical Reminders                                 56. Pharm: Benefits Management (PBM)
15. CPRS: Consult/Request Tracking                           57. Pharm: Consolidated Mail Outpatient Pharmacy
16. CPRS: Health Summary                                     58. Pharm: Controlled Substances
17. CPRS: Problem List                                       59. Pharm: Data Management (PDM)
18. CPRS: Text Integration Utility (TIU)                     60. Pharm: Drug Accountability
19. Dentistry                                                61. Pharm: Inpatient Medications
20. Electronic Wait List                                     62. Pharm: National Drug File (NDF)
21. Emergency Department Integration Software (EDIS)         63. Pharm: Outpatient Pharmacy
22. Functional Independence Measurement (FIM)                64. Pharm: Prescription Practices (PPP)
23. Group Notes                                              65. Primary Care Management Module (PCMM)
24. HDR - Historical (HDR-Hx)                                66. Prosthetics
25. Home Based Primary Care (HBPC)                           67. Quality Audiology and Speech Analysis and Reporting
26. Home Telehealth                                              (QUASAR)
27. Immunology Case Registry (ICR)                           68. Radiology / Nuclear Medicine
28. Incomplete Records Tracking (IRT)                        69. RAI/MDS
29. Intake and Output                                        70. Remote Order Entry System (ROES)
30. Laboratory                                               71. Scheduling
31. Laboratory: Anatomic Pathology                           72. Shift Handoff Tool
32. Laboratory: Blood Bank                                   73. Social Work
33. Laboratory: Blood Bank Workarounds                       74. Spinal Cord Dysfunction
34. Laboratory: Electronic Data Interchange (LEDI)           75. Standards & Terminology Services (STS)
35. Laboratory: Emerging Pathogens Initiative (EPI)          76. Surgery
36. Laboratory: Howdy Computerized Phlebotomy Login          77. VistA Imaging System
    Process                                                  78. VistAWeb
37. Laboratory: National Laboratory Tests (NLT)              79. Visual Impairment Service Team (VIST)
    Documents and LOINC Request Form                         80. Vitals / Measurements
38. Laboratory: Point of Care (POC)                          81. Womens’ Health


www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap           Page 26
                                                               9.    Diagnostic Related Group (DRG) Grouper
2.1.2     Infrastructure                                       10.   Electronic Claims Management Engine (ECME)
1.    Capacity Management Tools                                11.   Engineering (AEMS / MERS)
2.    Duplicate Record Merge: Patient Merge                    12.   Enrollment Application System
3.    Electronic Error and Enhancement Reporting (E3R)         13.   Equipment / Turn-In Request
4.    Enterprise Exception Log Service (EELS)                  14.   Event Capture
5.    FatKAAT                                                  15.   Fee Basis
6.    FileMan                                                  16.   Fugitive Felon Program (FFP)
7.    FileMan Delphi Components (FMDC)                         17.   Generic Code Sheet (GCS)
8.    Health Data Informatics                                  18.   Health Eligibility Center (HEC)
9.    HL7 (VistA Messaging)                                    19.   Hospital Inquiry (HINQ)
10.   Institution File Redesign (IFR)                          20.   ICD-9-CM
11.   KAAJEE                                                   21.   IFCAP
12.   Kernel                                                   22.   Incident Reporting
13.   Kernel Delphi Components (KDC)                           23.   Income Verification Match (IVM)
14.   Kernel Toolkit                                           24.   Integrated Billing (IB)
15.   Kernel Unwinder                                          25.   Integrated Patient Funds
16.   List Manager                                             26.   Library
17.   MailMan                                                  27.   Occurrence Screen
18.   Master Patient Index (MPI)                               28.   Patient Representative
19.   Medical Domain Web Services (MDWS)                       29.   Personnel and Accounting Integrated Data (PAID)
20.   M-to-M Broker                                            30.   Police and Security
21.   Name Standardization                                     31.   Quality Management Integration Module
22.   National Online Information Sharing (NOIS)               32.   Record Tracking
23.   National Patch Module                                    33.   Release of Information (ROI) Manager
24.   Network Health Exchange (NHE)                            34.   Veterans Identification Card (VIC/PICS)
25.   Patient Data Exchange (PDX)                              35.   Voluntary Service System (VSS)
26.   Remote Procedure Call (RPC) Broker                       36.   Wounded Injured and Ill Warriors
27.   Resource Usage Monitor
28.   Single Signon/User Context (SSO/UC)                      2.1.4     HealtheVet
29.   SlotMaster (Kernel ZSLOT)                                1.    Clinical Information Support System (CISS)
30.   SQL Interface (SQLI)                                     2.    Electronic Signature (ESig)
31.   Standard Files and Tables                                3.    HealtheVet Web Services Client (HWSC)
32.   Statistical Analysis of Global Growth (SAGG)             4.    My HealtheVet
33.   Survey Generator                                         5.    National Utilization Management Integration (NUMI)
34.   System Toolkit (STK)                                     6.    Occupational Health Record-keeping System (OHRS)
35.   VistA Data Extraction Framework (VDEF)                   7.    Patient Advocate Tracking System (PATS)
36.   VistALink                                                8.    Person Services
37.   XML Parser (VistA)                                       9.    Registries
                                                               10.   Spinal Cord Injury and Disorders Outcomes (SCIDO)
2.1.3     Financial-Administrative                             11.   VA Enrollment System (VES)
1.    Accounts Receivable (AR)                                 12.   Veterans Personal Finance System (VPFS)
2.    Auto Safety Incident Surv Track System (ASISTS)
3.    Automated Information Collection System (AICS)
4.    Automated Medical Information Exchange (AMIE)
5.    Clinical Monitoring System
6.    Compensation Pension Records Interchange (CAPRI)
7.    Current Procedural Terminology (CPT)
8.    Decision Support System (DSS) Extracts

www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap            Page 27
 1
 2   2.2 VistA Subsystems
 3   This section is being provided for context. OSEHR is composed of the VistA 1.0 and VistA 1.5 (also known
 4   as HealtheVet). Section 3 documents VistA 1.0 and VistA 1.5 subsystems in detail; but, Section 3 does not
 5   include the other subsystems overviewed in Section 2.
 6
      class VistA Subsystems

              Name:      VistA Subsystems
              Package:   VistA Subsystems
              Version:   Oct 2011
              Author:    OSEHRA


               Centralized Data Repositories                  VistA 1.5
                                                                                                  Master Patient Index (MPI)




              DoD Information Sharing                         External Entities
                                                                                                    VistA 1.0




               Corporate Data Warehouse (CDW)             Health Eligibility Center (HEC)           Corporate Databases




 7
 8                                                          Figure 2-2
 9   2.2.1 Vista 1.0
10   Description: Veterans Health Information Systems and Technology Architecture (VistA) v. 1.0, formerly known as
11   DHCP (Decentralized Hospital Computer Program), is a mature, highly integrated framework of shared services that
12   support user applications consistently and robustly. VistA includes clinical, administrative, financial, and infrastructure
13   applications.
14
15   VistA 1.0 is built on a client-server architecture that links both workstations and personal computers with graphical
16   user interfaces at Veterans Health Administration (VHA) facilities, as well as software developed by local medical
17   facility staff. VistA also provides the links that allow commercial off-the-shelf software and products to be used with
18   existing and future VistA technologies. The Decision Support System (DSS) and other national databases that might
19   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   Development Language:
22   • MUMPS
23   • Delphi
24
25   Deployment Infrastructure:
26   • Varies by location
27   • 128 field Instances currently deployed
28
29   Depends On:
30   Health Eligibility Center
31   Master Patient Index (MPI)
32   Department of Defense (DoD) Information Sharing
33   • Bidirectional Health Information Exchange (BHIE)
34   • Clinical Data Repository/Health Data Repository (CHDR)
35   • Federal Health Information Exchange (FHIE)
36   VistA 1.5
37   • VA Enrollment System (VES)
38   • VistA Blood Establishment Computer Software (VBECS)
39   External Entities
40   • Third Party Insurance
41   • Veterans Benefits Administration (VBA)
42   Centralized Data Repositories
43   • HDR Historical (HDR Hx)
44   • HDR Interim Messaging Solution (HDR IMS)
45   • HDR National (HDR II)
46   • Health Data Repository (HDR)
47
48   The following entities depend on VistA 1.0:
49   VistA 1.5
50   • Blind Rehabilitation
51   • Clinical Information Support System (CISS)
52   • Electronic Signature (ESig)
53   • Kernel Authentication & Authorization for J2EE (KAAJEE)
54   • My HealtheVet
55   • National Utilization Management Integration (NUMI)
56   • Patient Advocate Tracking System (PATS)
57   • Patient Service Construct (PSC)
58   • Person Service Lookup (PSL)
59   • VistA Blood Establishment Computer Software (VBECS)
60   Master Patient Index (MPI)
61   External Entities
62   • Defense Finance and Accounting Service (DFAS)
63   • VA Nationwide Health Information Network (NHIN)



     www.oserha.org                                OSEHR System-Architecture, Product Definition and Roadmap   Page 2-2
64   • Veterans Benefits Administration (VBA) Master Veteran Record (MVR)
65   Corporate Databases
66   Health Eligibility Center (HEC)
67   Corporate Data Warehouse
68   Department of Defense (DoD) Information Sharing
69   • Bidirectional Health Information Exchange (BHIE)
70   • Clinical Data Repository/Health Data Repository (CHDR)
71   • Federal Health Information Exchange (FHIE)
72   • Laboratory Data Sharing Interoperability (LDSI)
73   Centralized Data Repositories
74   • HDR Historical (HDR Hx)
75   • HDR Interim Messaging Solution (HDR IMS)
76   • HDR National (HDR II)




     www.oserha.org                                OSEHR System-Architecture, Product Definition and Roadmap   Page 2-3
77
      class VistA 1.0

            Name:       VistA 1.0
            Package:    VistA 1.0
            Version:    Oct 2011
            Author:     OSEHRA


                  Health Eligibility Center (HEC)     Master Patient Index (MPI)                 VistA 1.5




                                                       Clinical




                                                                                                 Corporate Databases
                                                       Financial-Administrativ e
                        External Entities



                                                                                     A




                                                       Infrastructure




                                                                                           Corporate Data Warehouse (CDW)
                                                     Centralized Data Repositories
                  DoD Information Sharing




78
79                                                           Figure 2-3
80
81   2.2.2 Vista 1.5 (aka HealtheVet)
82   Description: Veterans Health Information Systems and Technology Architecture (VistA) v. 1.5 (formerly known as
83   HealtheVet) is a strategy developed to move VistA 1.0 toward an ideal health information system to support the
84   veterans, VistA 2.0. A proposed strategy has been developed for both VA and Veterans Health Administration (VHA)
85   needs.
86
87   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   1. The Health Data System [health data repository (HDR)] will create a true longitudinal health care record including
 90   data from VA and non-VA sources. The health data system will support research and population analyses, facilitate
 91   patient access to data and sharing of information across VHA, and improve data quality and data security.
 92
 93   2. Provider Systems support healthcare providers' care for veterans and feed information to VistA today and the HDR
 94   in the future. These include CPRS, VistA Imaging, Blood Bank, Pharmacy, Laboratory, Federal Health Information
 95   Exchange (FHIE), and Scheduling.
 96
 97   3. Management/Financial Systems include four applications that are each ten or more years old and will be replaced:
 98   the Financial Management System, Billing and Accounts Receivable (AR), and Fee Basis (paying providers).
 99
100   4. Information and Education Systems with an emphasis on “eHealth” include prescription refills, appointments,
101   fillable forms online, and My HealtheVet (access to health record, online health assessment tools and high quality
102   health information).
103
104   5. Registration, Enrollment, and Eligibility Systems will be developed as a single, department-wide data system and
105   demographic database that supports registration and eligibility for the three Administrations and makes this
106   information more accessible and consistent.
107
108   6. Cross-Cutting Issues include the VA and VHA architectures, information security, data quality, and leadership and
109   management. These issues cut across all systems and ensure effective implementation and operations of the major
110   systems.
111
112   VistA 1.5 comprises those systems that are currently being reengineered, for which the target architecture has not
113   yet been defined. These systems will be in operation for some time in the future and are considered temporary
114   solutions.
115
116   The VistA 1.5 applications have the following characteristics:
117   • When implemented, each VistA 1.5 application will replace the equivalent VistA 1.0 application from which it was
118       transitioned.
119   • Some of the VistA 1.5 applications may be new applications which do not exist in VistA 1.0.
120   • When a Vista 1.5 application is made fully operational, the corresponding VistA 1.0 application is retired.
121
122   Programming Language:
123   • J2EE
124   • .NET
125   • MUMPS
126
127   Deployment Infrastructure:
128   • BEA WebLogic 8.1
129   • Oracle 10g
130   • Crystal Reports XI
131   • Crystal Enterprise 10



      www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap            Page 2-5
132   •   Business Objects Repository
133   •   IIS Server
134   •   SQL Server
135
136   Depends On:
137   VistA 1.0
138   • Admission Discharge Transfer (ADT)/Registration
139   • Computerized Patient Record System (CPRS)
140   • CPRS: Text Integration Utility (TIU)
141   • FileMan
142   • HL7 (VistA Messaging)
143   • Kernel
144   • Kernel Alerts
145   • Kernel Authentication & Authorization for J2EE (KAAJEE)
146   • Kernel Toolkit
147   • MailMan
148   • Personnel and Accounting Integrated Data (PAID)
149   • Remote Procedure Call (RPC) Broker
150   • Scheduling
151   • VistALink
152   Master Patient Index (MPI)
153   Health Eligibility Center (HEC)
154   Centralized Data Repositories
155   • Administrative Data Repository (ADR)
156   Corporate Databases
157   • National Patient Care Database (NPCD)
158   External Entities
159   • Internal Revenue Service (IRS)
160   • Social Security Administration (SSA)
161
162   The following entities depend on VistA 1.5:
163   VistA 1.0
164   • Integrated Billing (IB)
165   • Scheduling
166   Master Patient Index (MPI)
167   Health Eligibility Center (HEC)
168   Department of Defense (DoD) Information Sharing
169   • Laboratory Data Sharing Interoperability (LDSI)
170   Centralized Data Repositories
171   • Administrative Data Repository (ADR)
172   Corporate Databases
173   • National Patient Care Database (NPCD)
174   • Patient Advocate Database
175



      www.oserha.org                                OSEHR System-Architecture, Product Definition and Roadmap   Page 2-6
176   For more information, reference:
177   • VA Software Document Library: http://www.va.gov/vdl/section.asp?secid=4 VA Office of Enterprise Development
178       (OED) Project Repository:
179   • Active/On-Hold/Parked Project Notebook List for HealtheVet:
180       http://tspr.vista.med.va.gov/warboard/HealtheVet.asp
181   • VistA Monograph (2009): N/A
182
       class VistA v . 1.5

           Name:       VistA v. 1.5
           Package:    VistA 1.5
           Version:    Oct 2011
           Author:     OSEHRA




                                          CISS-Clinical                              HWSC-HealtheVet       KAAJEE-Kernel
            Blind Rehabilitation                                  ESig-Electronic     Web Serv ices       Authentication &
                                      Information Support
                                                                     Signature           Client        Authorization for Jav a 2
                                             System
                                                                                                          Enterprise Edition


                                        NUMI-National
                                         Utilization         OHRS-Occupational         PATS-Patient             PSIM-Person
              My HealtheVet             Management          Health Record-keeping       Adv ocate               Serv ice-Identy
                                         Integration                System           Tracking System             Management



                                                                   SCIDO-Spinal
                                                                                                            VBECS-Laboratory:
                                       Patient Serv ice           Cord Inj ury and    SDS-Standard             VistA Blood
                                            Lookup                  Disorders          Data Serv ice          Establishment
                                                                    Outcomes
                                                                                                            Computer Softw are




                 VES-VA                VPFS-Veterans
                                                                  VSS-Voluntary
                Enrollment            Personal Finance
                                                                  Serv ice System
                  System                   System




183
184                                                                 Figure 2-4
185
186   2.2.3       Master Patient Index (MPI)
187                               THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
188                                 NO DETAILED DOCUMENTATION WILL BE PROVIDED.
189
190   Description: The Master Patient Index (MPI) database is the primary vehicle for assigning and maintaining unique
191   patient identifiers. A gateway in VistA establishes connectivity between VA Medical Center (VAMC) systems and
192   patient registration processes and links to the MPI for message processing and patient identification. The MPI has
193   been created to support maintenance of a unique patient identifier and a single master index of all Veterans Health
194   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   VHA, Veterans Benefits Administration (VBA), Board of Veterans Appeals (BVA), National Cemetery Service (NCS),
196   and Department of Defense (DoD).
197
198   The MPI maintains a central index to correctly identify each patient and track the sites of interest. MPI data is
199   maintained in a centralized, dynamic database that is available to meet multiple information needs across many
200   applications and systems. The MPI central database, located at VA Austin Information Technology Center, is
201   composed of a unique list of patients and a current list of systems to which each patient entry is correlated. This
202   enables the sharing of patient data between operationally diverse systems. Each record (or index entry) in the MPI
203   contains a small amount of identity/demographic data used to identify individual entries. It is primarily used by VistA
204   applications requiring the need to enumerate unique patients at their facilities.
205
206   The MPI assigns each patient (1) a unique patient identifier (Integration Control Number, or ICN) and (2) initially
207   assigns the requesting site as the Coordinating Master Of Record (CMOR), which represents the system that is
208   presently the authoritative source for the patient's identity data. Each index entry in the MPI also contains the
209   patient's identifying information (e.g., name, SSN, date of birth, gender) and a current list of facilities where the
210   patient has been seen. The MPI is updated as new patients are added or demographic information is updated at the
211   correlated system. Once a CMOR has been assigned to a patient, the MPI will only accept changes and/or updates
212   to patient identity information from the CMOR site. The CMOR can be changed at any time, when necessary, to
213   reflect the authoritative source for this data.
214
215   The Master Patient Index/Patient Demographics (MPI/PD) software enables sites to:
216   • Request an ICN assignment
217   • Query the MPI for known data
218   • Update the MPI when changes occur to demographic fields stored on the index itself or to other facilities and
219       systems of interest.
220
221   Development Language:
222   • MUMPS
223
224   Deployment Infrastructure:
225   • Research pending
226
227   Depends On:
228   VistA 1.0
229   • Admission Discharge Transfer (ADT)/Registration
230   • Clinical Information Resource Network (CIRN)
231   • FileMan
232   • HL7 (VistA Messaging)
233   • Kernel
234   • Kernel TaskMan
235   • Kernel Toolkit
236   • List Manager
237   • MailMan
238   • Remote Procedure Call (RPC) Broker



      www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap             Page 2-8
239   VistA 1.5
240   • VA Enrollment System (VES)
241
242   The following entities depend on Master Patient Index (MPI):
243   VistA 1.0
244   • Admission Discharge Transfer (ADT)/Registration
245   • Clinical Information Resource Network (CIRN)
246   • Clinical Procedures/Medicine
247   • Compensation Pension Records Interchange (CAPRI)/Automated Medical Information Exchange (AMIE)
248   • Computerized Patient Record System (CPRS)
249   • CPRS: Consult/Request Tracking
250   • Decision Support System (DSS) Extracts
251   • Enrollment Application System
252   • Fee Basis
253   • Home Telehealth
254   • Hospital Inquiry (HINQ)
255   • Income Verification Match (IVM)
256   • Integrated Billing (IB)
257   • Kernel Duplicate Record Merge: Patient Merge
258   • Kernel Toolkit
259   • Laboratory
260   • Mental Health
261   • Patient Appointment Information Transmission (PAIT)
262   • Patient Record Flags
263   • Pharmacy: Bar Code Medication Administration (BCMA)
264   • Pharmacy: Benefits Management (PBM)
265   • Pharmacy: Outpatient Pharmacy
266   • Prosthetics
267   • Quality Audiology Speech Analysis & Reporting (QUASAR)
268   • Release of Information (ROI) Manager
269   • Remote Order Entry System (ROES)
270   • Scheduling
271   • Surgery
272   • Veterans Identification Card (VIC)
273   • Vista Imaging System
274   • VistA 1.5
275   • Person Service Lookup v. 4.0.4.4
276   • Person Service Lookup v. 4.0.4.3
277   • Patient Service Construct v. 2.0.0.7
278   • Patient Service Construct v. 2.0.0.8
279   • My HealtheVet
280   • VistA Blood Establishment Computer Software (VBECS)
281   • Person Service Identity Management (PSIM)
282   Centralized Data Repositories



      www.oserha.org                              OSEHR System-Architecture, Product Definition and Roadmap   Page 2-9
283   •   Health Data Repository (HDR)
284       • HDR Historical (HDR Hx)
285       • HDR Intermediate Messaging Solution (HDR IMS)
286       • HDR Clinical Data Services (CDS)
287       • HDR National (HDR II)
288   • Administrative Data Repository (ADR)
289   Department of Defense (DoD) Information Sharing
290   • Federal Health Information Exchange (FHIE)
291   • Bidirectional Health Information Exchange (BHIE)
292   • Clinical Data Repository/Health Data Repository (CHDR)
293   Corporate Databases
294   • National Database Integration (NDBI)
295   External Entities
296   • VA Nationwide Health Information Network (NHIN)
297
298   For more information, reference:
299   • VA Software Document Library (VDL): http://www.va.gov/vdl/application.asp?appid=16
300   • VistA Monograph (2009): http://www4.va.gov/vista_monograph/
301   • Office of Enterprise Development (OED) Project Repository:
302       • MPI FY09 Changes Project Notebook:
303            http://tspr.vista.med.va.gov/warbOARD/anotebk.asp?proj=1288&Type=Active
304       • Master Patient Index V. 1.0 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=151
305       • Master Patient Index / Patient Demographics Project Notebook:
306            http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=38
307       • MPI Changes – ISS Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=682
308       • MPI Changes – Iteration 01 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=734
309       • MPI Changes – Iteration 02 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=784
310       • MPI Changes – Iteration 03 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=954
311       • MPI Changes – MS Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=683
312       • MPI FY08 Changes Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1252
313       • MPI FY09 Changes Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1288
314       • MPI FY10 Changes Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1353
315       • MPI Health Eligibility Center Enumeration – MPI/HEC Project Notebook:
316            http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1008
317       • MPI Integration at HEC Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=430
318       • MPI Master of Record Enhancements Project Notebook:
319            http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=488
320       • MPI/PD Phase III Enhancements Project Notebook:
321            http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=482
322   • Master Patient Index (MPI) Homepage: http://vista.med.va.gov/mpi/index.asp
323   • Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
324   • National Data Systems (NDS) Master Patient Index (MPI) website:
325       http://vaww4.va.gov/NDS/MasterPatientIndex.asp




      www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap        Page 2-1
       class Master Patient Index (MPI)

          Name:      Master Patient Index (MPI)
          Package:   Master Patient Index (MPI)
          Version:   Oct 2011
          Author:    OSEHRA
           Centralized Data Repositories                                                               VistA 1.0




                                                            DoD Information Sharing




                  VistA 1.5                                                                          Master Patient Index (MPI)




326
327                                                           Figure 2-5
328
329   2.2.4      Health Eligibility Center (HEC)
330                                THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
331                                  NO DETAILED DOCUMENTATION WILL BE PROVIDED.
332
333   Description: The Health Eligibility Center (HEC) v. 1.0 supports VA's health care enrollment system while providing
334   centralized eligibility verification and determination services. This office supports VA by verifying veterans' eligibility
335   and processing enrollment applications. The HEC supports, coordinates, and implements VHA's financial
336   assessment process, consolidating financial eligibility determinations for VA health care.
337
338   The HEC also:
339   • Conducts VHA's income verification process for veterans whose financial assessments exempt them from
340       medical care co-payments
341   • Validates Social Security numbers from the Social Security Administration
342   • Verifies income from the Internal Revenue Service and the Social Security Administration
343   • Receives information from VBA to determine Veterans’ eligibility and enrollment assignment
344   • Implements information system enhancements to support CBO vision of application, eligibility and enrollment
345       processing
346   • Assists in the maintenance of the Enrollment Database by performing data management functions focused on
347       improving the integrity of veterans' personal, eligibility, and financial information



      www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap               Page 2-1
348   •   Is the authoritative source and Data Steward for Demographic, Eligibility, and Enrollment data. This does not
349       include Patient Identity elements.
350   •   Provides Business oversight to all software products related to Registration, Eligibility and Enrollment.
351
352   The HEC recently deployed Enrollment System Redesign (ESR) version 3.0, the HealtheVet replacement system for
353   the current product known as HEC Legacy. This expert system gathers information obtained from VistA, VBA, and
354   the HEC staff to determine and communicate verified medical benefits eligibility and enrollment (E&E) information for
355   all veterans and beneficiaries. For every exception where the expert system process cannot make a determination,
356   “cases” are created for human intervention. HEC staff utilizes ESR to manage these “cases” to completion so that
357   verified E&E can be determined.
358
359   The HEC, located in Atlanta, GA, receives patient-reported Means Test data from the VistA 1.0 Income Verification
360   Match (IVM) module. HEC compares the extracted data with earned and unearned income data retrieved from Social
361   Security Administration (SSA) and Internal Revenue Service (IRS). Patients with reported income in the mandatory
362   category, but whose actual income has been proven to be above that level, will have their eligibility for health care
363   changed to the discretionary category and are subject to back billing.
364
365   The HEC sends the updated demographic and insurance information to the medical facilities for upload. The IVM
366   module allows the HEC data to be compared with locally collected data and selectively uploaded. Local revenue staff
367   may then send healthcare claims to insurance companies for treatment rendered to patients who had not previously
368   reported health insurance coverage. Updated and verified income information from the HEC is automatically
369   uploaded upon receipt at each VA facility, which updates the veteran’s eligibility for health care and creates co-
370   payment charges for previous episodes of care.
371
372   Programming Language:
373   • J2EE
374   • Spring Framework
375   • Struts Framework
376   • Hibernate Framework
377   • JRules
378
379   Deployment Infrastructure:
380   • WebLogic Server
381
382   Depends On:
383   VistA 1.0
384   • FileMan
385   • Income Verification Match (IVM)
386   • MailMan
387   VistA 1.5
388   • Person Service Identity Management (PSIM)
389   • VA Enrollment System (VES)
390   External Entities
391   • Social Security Administration (SSA)



      www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap            Page 2-1
392   •   Internal Revenue Service (IRS)
393
394   The following entities depend on Health Eligibility Center (HEC):
395   VistA 1.0
396   • Research pending
397   External Entities
398   • Social Security Administration (SSA)
399   • Internal Revenue Service (IRS)
400   VistA 1.5
401   • Person Services Identity Management (PSIM)
402   Master Patient Index (MPI)
403   Centralized Data Repositories
404   Administrative Data Repository (ADR)
405
406   For more information, reference:
407   • VA Software Document Library (VDL): http://www.va.gov/vdl/application.asp?appid=143
408   • Office of Enterprise Development (OED) Project Repository:
409       • HEC Redesign – Version 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=504
410       • HEC Redesign – Version 2 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=602
411       • HEC Redesign – Version 3 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=737
412       • HEC VistA Enhancements (HVE) Project Notebook:
413          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=843
414       • HEC HL7 Upgrade Phase 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=359
415       • Enrollment System Redesign (ESR) – Version 3.0 Project Notebook:
416          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=884
417       • Enrollment System Redesign (ESR) – Version 3.1 Project Notebook:
418          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1174
419       • Enrollment System Redesign (ESR) – Version 3.2 Project Notebook:
420          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1275
421       • Enrollment System Redesign (ESR) – Version 3.3 Project Notebook:
422          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1286
423       • Enrollment System Redesign (ESR)-V4.0 IVM Workflow Project Notebook:
424          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1030
425       • Enrollment VistA Changes (EVC) Early Release Project Notebook:
426          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1009
427       • Enrollment VistA Changes (EVC) Release 1 Project Notebook:
428          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=951
429       • Enrollment VistA Changes (EVC) Release 2 Project Notebook:
430          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=982
431       • Enrollment Priority 8 Enhancements Project Notebook:
432          http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1292
433       • VistA Enrollment Database Standards and Procedures:
434          http://tspr.vista.med.va.gov/warboard/ProjectDocs/HEC_Redesign_V1/HEC%20Redesign%20Database%2
435          0Stds%20&%20Procs.doc#_Toc517162753



      www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap     Page 2-1
436           •   Enrollment System Redesign Project Overview:
437               http://tspr.vista.med.va.gov/warboard/ProjectDocs%5CEnrollment_System_Redesign_Ver_3.0%5CESR%2
438               0Overview%208-23-2005.pdf
439   •       Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
440   •       Health Eligibility Center (HEC) Homepage: http://vaww.va.gov/hec/
441
          class Health Eligibility Center (HEC)

             Name:      Health Eligibility Center (HEC)
             Package:   Health Eligibility Center (HEC)
             Version:   Oct 2011
             Author:    OSEHRA




               External Entities                              VistA 1.5                              VistA 1.0




                                                          Health Eligibility Center (HEC)




                                                           Master Patient Index (MPI)




442
443                                                              Figure 2-6
444
445   2.2.5         External Entities
446                                  THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
447                                    NO DETAILED DOCUMENTATION WILL BE PROVIDED.
448
449    Description: This diagram is a visual representation of the entities external to the Department of Veterans Affairs
450   (VA) Office of Information and Technology (OI&T) that receive VistA data.
451
452   Depends On:
453   VistA 1.0
454   VistA 1.5
455   Health Eligibility Center (HEC)



      www.oserha.org                                          OSEHR System-Architecture, Product Definition and Roadmap      Page 2-1
456   Department of Defense (DoD) Information Sharing
457   • Clinical Data Repository / Health Data Repository (CHDR)
458   • Laboratory Data Sharing Interoperability (LDSI)
459   • Bidirectional Health Information Exchange (BHIE)
460   Master Patient Index (MPI)
461
462   The following entities depend on External Entities:
463   VistA 1.0
464   • Hospital Inquiry (HINQ)
465   Health Eligibility Center (HEC)
466   Department of Defense (DoD) Information Sharing
467   • Federal Health Information Exchange (FHIE)
468   • Clinical Data Repository / Health Data Repository (CHDR)
469   • Laboratory Data Sharing Interoperability (LDSI)
470   • Bidirectional Health Information Exchange (BHIE)
471   VistA 1.5
472   • VA Enrollment System (VES)




      www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap   Page 2-1
       class External Entities

                 Name:        External Entities
                 Package:     External Entities
                 Version:     Oct 2011
                 Author:      OSEHRA




                        Node                                                       Node Social
                                                    Node Internal                   Security                                 Node Third Party
                    Department of
                                                   Rev enue Serv ice              Administration                               Insurance
                    Defense (DoD)
                                                                                      (SSA)


                                                                        «flow»
                  «flow»         «flow»
                                                                                 «flow»       «flow»
                                                          «flow»

                DoD Information Sharing                                 Health Eligibility Center (HEC)                     Master Patient Index (MPI)




                                                                                                          «flow»




                                                                                                                                  Node Defense
                                                                                                                                   Finance and
                                                                                                                                    Accounting
                                                                                                                                  Serv ice (DFAS)


                  VistA 1.5                                                 VistA 1.0                                   «flow»
                                                                                                                                                    «flow»



                                                                                                                                  Node Veterans
                                                                                                               «flow»
                                                                                                                                    Benefits
                                                                                                                                  Administration
                                                                                                                                      (VBA)

                                                            «flow»
                        «flow»
                                                                                                                        «flow»

                                                       Node Veterans        Corporate Databases
                                                                                                                                      Node VA
                   Node National                          Benefits
                                                                                                                                    Nationw ide
                    Change of                          Administration
                                                                                                                                       Health
                     Address                  «flow»    (VBA) Master
                                                                                                                                    Information
                                                       Veteran Record
                                                                                                                                  Netw ork (NHIN)
                                                            (MVR)

473
474                                                                         Figure 2-7
475
476   2.2.6    DoD Information Sharing
477                             THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
478                                 NO DETAILED DOCUMENTATION WILL BE PROVIDED.
479                                                              .
480   Description: The VA/DoD Health IT Sharing (HITS) Program Office reports to the Chief Officer, Health Systems
481   Information Management & Technology, in the VHA Office of Information (OI) and directly supports the VA mission
482   and efforts to promote quality healthcare for veterans and eligible service members including National Guard soldiers
483   and reservists. The VA/DoD Health IT Sharing Program was launched in 2000 and elevated to full Program Status in
484   May 2004.
485




      www.oserha.org                                                     OSEHR System-Architecture, Product Definition and Roadmap                           Page 2-1
486   The program serves as an umbrella organization responsible for the oversight and coordination of VA/DoD health IT
487   projects and programs within VA. These projects fall within the VA/DoD Joint Electronic Records Interoperability
488   (JEHRI) strategy.
489
490   Specific objectives of the JEHRI strategy include:
491   • Identifying opportunities for VA/DoD collaboration and cooperation
492   • Supporting the seamless transition of veterans from military service through the provision of high-quality health
493      information technology solutions
494   • Facilitating and supporting the development of mutually beneficial health information technology sharing
495      agreements between VHA and the Military Health System (MHS)
496
497   The VA/DoD Interoperability suite of systems is comprised of:
498   • FHIE - One-way enterprise exchange of text data
499   • BHIE - Bidirectional real-time exchange of text data
500   • CHDR - Bidirectional real-time enterprise exchange of computable data
501
502   Programming Language:
503   • MUMPS
504   • Oracle 10
505   • JDK
506   • J2EE
507
508   Deployment Infrastructure:
509   • Oracle
510   • Windows 2000
511   • HP-UX
512   • Research pending
513
514   Depends On:
515   VistA 1.0
516   • Admission Discharge Transfer (ADT)/Registration
517   • Compensation Pension Records Interchange (CAPRI)/Automated Medical Information Exchange (AMIE)
518   • Computerized Patient Record System (CPRS)
519   • Kernel
520   • Laboratory (Laboratory Electronic Data Interchange (LEDI))
521   • Surgery
522   • VistALink
523   • VistAWeb
524   • Vitals/Measurements
525   VistA 1.5
526   • KAAJEE
527   • Person Service Identity Management (PSIM)
528   • Person Service Lookup (PSL)
529   Master Patient Index (MPI)



      www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap           Page 2-1
530   Centralized Data Repositories
531   • Health Data Repository (HDR)
532     • HDR National (HDR II)
533     • HDR Clinical Data Service (CDS)
534     • HDR Historical (HDR Hx)
535     • HDR Intermediate Messaging Solution (HDR IMS)
536   External Entities
537   • Department of Defense (DoD)
538
539   The following entities depend on Department of Defense (DoD) Information Sharing:
540   VistA 1.0
541   • Computerized Patient Record System (CPRS)
542   • Laboratory (Laboratory Electronic Data Interchange (LEDI))
543   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
544   • VistAWeb
545   External Entities
546   • Department of Defense (DoD)
547
548   For more information, reference:
549   • VA Software Document Library (VDL): N/A
550   • VA Office of Enterprise Development (OED) Project Repository: N/A
551   • VistA Monograph (2009): http://www4.va.gov/vista_monograph/
552   • VA/DoD Health IT Sharing Program Homepage: http://vaww1.va.gov/vadodhealthitsharing/




      www.oserha.org                                OSEHR System-Architecture, Product Definition and Roadmap   Page 2-1
       class DoD Information Sharing

               Name:        DoD Information Sharing
               Package:     DoD Information Sharing
               Version:     Oct 2011
               Author:      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                             Clinical Health Data Repository (CHDR)
                                                                                                            Centralized Data Repositories




553
554                                                                Figure 2-8
555
556   2.2.7       Corporate Databases
557                              THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
558                                NO DETAILED DOCUMENTATION WILL BE PROVIDED.
559
560   Description: The figure is a visual representation of the corporate databases external to VistA 1.0. This list is
561   comprised of information provided in the VHA Corporate Database Monograph, through code-level research
562   conducted by the Analysts Office, and by a review of application-specific documentation in the VA Software
563   Document Library (VDL) (VDL). Included are the VHA databases that comprise the national consolidation of
564   information from VHA's integrated hospital information systems.
565
566   Depends Upon:
567   VistA 1.0
568   • Accounts Receivable (AR)
569   • Admission Discharge Transfer (ADT)/Registration



      www.oserha.org                                           OSEHR System-Architecture, Product Definition and Roadmap                    Page 2-1
570   • Ambulatory Care Reporting
571   • Automated Safety Incident Surveillance and Tracking System (ASISTS)
572   • Capacity Management Tools
573   • Clinical Case Registries
574   • CPRS: Clinical Reminders
575   • CPRS: Health Summary
576   • Decision Support System (DSS) Extracts
577   • Dentistry
578   • Electronic Wait List
579   • Engineering
580   • Fee Basis
581   • Generic Code Sheet (GCS)
582   • Home Based Primary Care (HBPC)
583   • Incident Reporting
584   • Integrated Funds Distribution, Control Point Activity, Accounting and Procurement (IFCAP)
585   • Laboratory
586   • Master Patient Index (MPI)
587   • Mental Health
588   • National Prosthetics Patient Database (NPPD)
589   • Oncology
590   • Patient Care Encounter (PCE)
591   • Pharmacy: Benefits Management (PBM)
592   • Pharmacy: Outpatient Pharmacy
593   • Prosthetics
594   • Quality Audiology Speech Analysis & Reporting (QUASAR)
595   • Remote Order Entry System (ROES)
596   • Scheduling
597   • Spinal Cord Dysfunction
598   • Suicide Hotline
599   • Surgery
600   • Veterans Identification Card (VIC)
601   VistA 1.5
602   • Patient Advocate Tracking System (PATS)
603   • VA Enrollment System (VES)
604
605   The following entities depend on Corporate Databases:
606   VistA 1.0
607   • Decision Support System (DSS) Extracts
608   Corporate Data Warehouse (CDW)
609   External Entities
610   • Occupational Safety and Health Administration (OSHA)
611   • Department of Labor
612   VistA 1.5
613   • VA Enrollment System (VES)



      www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap   Page 2-2
614
615   For more information, reference:
616     Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
617
       class Corporate Databases

              Name:      Corporate Databases
              Package:   Corporate Databases
              Version:   Oct 2011
              Author:    OSEHRA




           Clinical                                  Financial-Administrativ e                 Infrastructure




                                                                                 A




618
619                                                          Figure 2-9
620
621   2.2.8    Centralized Data Repositories
622                              THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
623                                 NO DETAILED DOCUMENTATION WILL BE PROVIDED.
624   Description: The Centralized Data Repositories are defined as stores of clinical and administrative information that
625   reside on one or more independent platforms and are used by clinicians and other personnel to facilitate longitudinal
626   patient-centric care. The data in the repositories will be retrieved from existing Veterans Health Information Systems
627   and Technology Architecture (VistA) and re-engineered package files and organized in a format that supports the
628   delivery of care, regardless of the patient's location or where they have been treated in the past.
629
630   Programming Language:
631   • Oracle
632   • J2EE
633
634   Deployment Infrastructure:
635   • Oracle 11g
636   • Unix
637
638   Depends On:
639   VistA 1.0
640   • Computerized Patient Record System (CPRS)
641   • CPRS: Adverse Reaction Tracking
642   • HL7 (VistA Messaging)
643   • Laboratory
644   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
645   • VistA Data Extraction Framework (VDEF)
646   • VistAWeb



      www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap            Page 2-2
647   • Vitals/Measurements
648   VistA 1.5
649   • Person Service Identity Management (PSIM)
650   • Standard Data Service (SDS)
651   • VA Enrollment System (VES)
652   Master Patient Index (MPI)
653   Department of Defense (DoD) Information Sharing
654   • Clinical Data Repository/Health Data Repository (CHDR)
655   Health Eligibility Center (HEC)
656
657   The following entities depend on Centralized Data Repositories:
658   VistA 1.0
659   • HomeTelehealth
660   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
661   • VistAWeb
662   VistA 1.5
663   • My HealtheVet
664   • Person Services Identity Management (PSIM)
665   • VA Enrollment System (VES)
666   Department of Defense (DoD) Information Sharing
667   • Clinical Data Repository/Health Data Repository (CHDR)
668   Corporate Data Warehouse (CDW)
669   Health Eligibility Center (HEC)
670
671   For more information, reference:
672   • VA Software Document Library (VDL): N/A
673   • VA Office of Enterprise Development (OED) Project Repository: N/A
674   • VistA Monograph (2009): N/A
675




      www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap   Page 2-2
       class Centralized Data Repositories

               Name:      Centralized Data Repositories
               Package:   Centralized Data Repositories
               Version:   Oct 2011
               Author:    OSEHRA




                  Health Data Repository (HDR)                                                DoD Information Sharing
                                                             VistA 1.0




                Corporate Data Warehouse (CDW)            Master Patient Index (MPI)




              Administrativ e Data Repository (ADR)          VistA 1.5                        Health Eligibility Center (HEC)




676
677                                                            Figure 2-10
678
679   2.2.9      Health Data Repository (HDR)
680                             THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
681                               NO DETAILED DOCUMENTATION WILL BE PROVIDED.
682
683   Centralized Data Repositories
684   Package Health Data Repository (PHDR)
685   Health Data Repository (HDR)
686
687   Description : The Health Data Repository (HDR) is a national, clinical data storehouse which supports integrated,
688   computable and/or viewable access to the patient’s longitudinal health record. The HDR will be the authoritative
689   source of veterans’ clinical data when complete, and currently serves as the authoritative source for data from
690   Department of Defense (DoD) Clinical Data Repository (CHDR) and for the Home TeleHealth Program.
691




      www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap           Page 2-2
692   The data in the HDR is retrieved from existing Veterans Health Information Systems and Technology Architecture
693   (VistA) and re-engineered clinical package files and organized in a format that supports the delivery of care,
694   regardless of the patient's location or where they have been treated in the past.
695
696   The overarching business need for the HDR is the integration of clinical patient data from across VA, as well as from
697   participating external health care systems. Health care providers, including direct care providers within and outside of
698   the VA, business office personnel, researchers, and management staff all require integrated clinical patient data to
699   provide and improve health care delivery to veterans. This functionality does not currently exist in VistA, and is a
700   cornerstone for the next generation HealtheVet. The long-term goal of the HDR project is to deploy one national
701   database of all required clinical data and a required number of regional databases that support re-engineering
702   applications as a transactional database.
703
704   Programming Language:
705   • Oracle
706   • J2EE
707
708   Deployment Infrastructure:
709   • Oracle 11g
710   • Unix
711
712   Depends On:
713   VistA 1.0
714   • Computerized Patient Record System (CPRS)
715   • CPRS: Adverse Reaction Tracking
716   • HL7 (VistA Messaging)
717   • Laboratory
718   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
719   • VistA Data Extraction Framework (VDEF)
720   • VistAWeb
721   • Vitals/Measurements
722   VistA 1.5
723   • Person Service Identity Management (PSIM)
724   Department of Defense (DoD) Information Sharing
725   • Clinical Data Repository/Health Data Repository (CHDR)
726   Master Patient Index (MPI)
727
728   The following entities depend on Health Data Repository (HDR):
729   VistA 1.0
730   • Computerized Patient Record System (CPRS)
731   • HomeTelehealth
732   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
733   • VistAWeb
734   VistA 1.5
735   • My HealtheVet



      www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 2-2
736   Department of Defense (DoD) Information Sharing
737   • Clinical Data Repository/Health Data Repository (CHDR)
738   Corporate Data Warehouse (CDW)
739
740   For more information, reference:
741   • VA Software Document Library (VDL): N/A
742   • VA Office of Enterprise Development (OED) Project Repository:
743     • Health Data Repository Project Notebook List:
744        http://tspr.vista.med.va.gov/warboard/GlobalGroup.asp?group=17
745     • ADR/HDR Data Migration Initiative Project Notebook:
746        http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1093&Type=Active
747   • VistA Monograph (2009): http://www4.va.gov/vista_monograph/
748   • Corporate Database Monograph (2009): http://www4.va.gov/vista_monograph/
749   • Health Data Repository Homepage: http://vaww.vista.med.va.gov/hdr/index.html
750   • Additional online resources:
751     • Health Data Repository Overview: http://vaww.vista.med.va.gov/hdr/HDR_SLC_Mtg_with_HISEB.pdf
752     • HDR Domains at a Glance: http://vaww.vista.med.va.gov/hdr/Domains_at_a_glance.pdf
753     • HDR Project Overview PowerPoint:
754        http://vista.med.va.gov/training_lib/brown_bags/related_documents/brown_bag-hdr_overview_prototype_8-27-
755        02.ppt#256,1,Slide
756   • Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
757




      www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap        Page 2-2
       class Health Data Repository (HDR)

          Name:      Health Data Repository (HDR)
          Package:   Health Data Repository (HDR)
          Version:   Oct 2011
          Author:    OSEHRA                           HDR-Health Data Repository




                                                                        Corporate Data Warehouse
                                                                                  (CDW)



                         HDR Interim Messaging       HDR-Hx HDR Historical                                     HDR II
                             Serv ice (IMS)




                                                    VistA 1.0
                                                                                                   HDR Clinical Data Serv ices (CDS)




               Master Patient Index (MPI)           DoD Information Sharing




758
759                                                             Figure 2-11
760
761   2.2.9.1         HDR Clinical Data Services (CDS)
762                             THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
763                               NO DETAILED DOCUMENTATION WILL BE PROVIDED.
764
765   Centralized Data Repositories::Health Data Repository (HDR)
766   Package HDR Clinical Data Services (CDS)
767   HDR Clinical Data Services (CDS) v. 1.0
768   HDR Clinical Data Services (CDS) v. 2.1.2
769
770   Description: HDR Clinical Data Services (CDS) is a subproject of the Health Data Repository (HDR) project. Under
771   the HealtheVet strategy, CDS is designated to be the authoritative data service for HealtheVet applications and
772   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-2
773   developed within the context of HealtheVet-VistA strategy, which will be used by the Veterans Health Administration
774   (VHA) to assist in the delivery of healthcare to its patients.
775
776   CDS supplies read and write services to HDR data that is nationalized (patient data collected from all applicable and
777   accessible sources of clinical data, regardless of site of treatment), patient-centric (directly-related to an individual
778   patient, not reference data), clinical (used for patient care), and viewable (needed by applications other than the
779   application that generated the data). There are many other enterprise initiatives defined to support data that does not
780   fit into the definition of nationalized, patient-centric, clinical viewable data. Non-patient clinical reference data will be
781   managed by the Enterprise Terminology Services (ETS) project, non-clinical data will be managed by the
782   Administrative Data Repository (ADR), and that clinical data that is non-nationalized and non-viewable will be
783   managed by the application that owns this data.
784
785   CDS also provides HealtheVet applications with data access to VistA; however, CDS is one of many ways to access
786   VistA clinical data and is not the exclusive, authoritative service for VistA data.
787
788   CDS v. 1.0 supports the HDR IMS application, while CDS v. 2.1.2 supports the HDR II application.
789
790   CDS is deployed at the Hines Information Technology Center (HITC) in Hines, Illinois.
791
792   Programming Language:
793   • J2EE
794
795   Deployment Infrastructure:
796   • Linux
797
798   Depends On:
799   VistA 1.0
800   • Computerized Patient Record System (CPRS)
801   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
802   • VistAWeb
803   Centralized Data Repositories
804   • Health Data Repository (HDR)
805     • HDR Historical (HDR Hx)
806     • HDR Interim Messaging Solution (HDR IMS)
807     • HDR National (HDR II)
808   VistA 1.5
809   • Person Service Identity Management (PSIM)
810   Master Patient Index (MPI)
811
812   The following entities depend on HDR Clinical Data Service (CDS):
813   Department of Defense (DoD) Information Sharing
814   • Clinical Data Repository/Health Data Repository (CHDR)
815   Centralized Data Repositories
816   • Health Data Repository (HDR)



      www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap                 Page 2-2
817     •     HDR National (HDR II)
818
819   For more information, reference:
820   • VA Software Document Library (VDL): N/A
821   • VA Office of Enterprise Development (OED) Project Repository:
822   • HDR II Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=918
823   • Clinical Data Services Project Notebook:
824       http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=962&Type=Active
825   • VistA Monograph (2009): http://www4.va.gov/vista_monograph/
826   • HDR II and Clinical Data Service (CDS) Documentation Webpage:
827       http://vaww.vista.med.va.gov/hdr/HDR_II_Documents.html
828   • HDR PowerPoint Presentation: http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf
829   • HDR Overview: http://vaww.vista.med.va.gov/hdr/HDR_SLC_Mtg_with_HISEB.pdf
830   • Clinical Data Service (CDS) Vision Document:
831       http://vaww.vista.med.va.gov/hdr/HDR_II_Documents/CDS_Vision_Document.pdf
832   • Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
833
       class HDR Clinical Data Serv ices (CDS)

            Name:      HDR Clinical Data Services (CDS)
            Package:   HDR Clinical Data Services (CDS)
            Version:   Oct 2011
            Author:    OSEHRA




                       HDR-Health Data Repository             HDR-Health Data Repository                     HDR Interim
                                                                                                          Messaging Serv ice
                                 HDR II                       HDR Clinical Data Serv ices
                                                                                                                (IMS)
                                                                        (CDS)




              VistA 1.0                                                                                    VistA 1.5
                                                                      HDR-Health Data Repository
                                                                        HDR-Hx HDR Historical




                                               Master Patient Index (MPI)                       DoD Information Sharing




834
835                                                              Figure 2-12
836




      www.oserha.org                                           OSEHR System-Architecture, Product Definition and Roadmap       Page 2-2
837   2.2.9.2     HDR Historical (HDR-Hx)
838                        THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
839                           NO DETAILED DOCUMENTATION WILL BE PROVIDED.
840
841   Centralized Data Repositories::Health Data Repository (HDR)
842   Package HDR Historical (HDR Hx)
843   HDR Historical (HDR Hx)
844
845   ** Please note, this information was gathered via documentation found in the Office of Enterprise Development
846   (OED) Project Repository, the VistA Monograph, and the HDR Hx Homepage. As the Analysts Office did not receive
847   feedback from the HDR Historical points of contact, this information has not been verified.
848
849   Description: HDR Historical (HDR Hx) stores all clinical data from VistA not contained in HDR IMS and not identified
850   for inclusion in HDR II. It provides historical clinical data in a computable and/or viewable access form to user
851   interfaces such as RDI, CHDR and VistAWeb to support patient care.
852
853   HDR Hx extracts and stores legacy data from 128 VistA systems to a relational database in the Austin Information
854   Technology Center (AITC). The data is viewable from the HDR Hx database via Remote Data Views (RDV) in CPRS.
855   HDR Hx allows sites to archive and purge selected data in local databases. The historical data provided by HDR Hx
856   is combined with other HDR data for use across the organization to facilitate patient care, clinical decision support,
857   and research activities.
858
859   Programming Language:
860   • Research pending
861
862   Deployment Infrastructure:
863   • Oracle 11g
864   • Unix
865
866   Depends On:
867   VistA 1.0
868   • Computerized Patient Record System (CPRS)
869   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
870   Department of Defense (DoD) Information Sharing
871   • Clinical Data Repository/Health Data Repository (CHDR)
872   Master Patient Index (MPI)
873
874   The following entities depend on HDR Historical (HDR Hx):
875   VistA 1.0
876   • VistAWeb
877   Centralized Data Repositories
878   • HDR Clinical Data Services (CDS) v. 1.0
879   • HDR National (HDR II)
880   Corporate Data Warehouse (CDW)



      www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 2-2
881   Department of Defense (DoD) Information Sharing
882   • Clinical Data Repository/Health Data Repository (CHDR)
883
884   For more information, reference:
885   • VA Software Document Library (VDL): N/A
886   • VA Office of Enterprise Development (OED) Project Repository:
887     • HDR Historical Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=909
888   • VistA Monograph (2009): http://www4.va.gov/vista_monograph/
889   • Health Data Repository Hx Homepage: http://vaww.vista.med.va.gov/hdr/HDR_Hx_Documents.html
890   • Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
891   • Health Data Repository PowerPoint Presentation:
892       http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf
893
       class HDR-Hx HDR Historical

          Name:       HDR-Hx HDR Historical
          Package:    HDR-Hx HDR Historical
          Version:    Oct 2011                                       HDR-Health Data
          Author:     OSEHRA                                           Repository




                                       HDR Clinical Data           HDR-Hx HDR Historical                       HDR II
                                        Serv ices (CDS)




                          Corporate Databases                                               VistA 1.0




                                                Master Patient Index (MPI)                 DoD Information Sharing




894
895                                                             Figure 2-13
896
897   2.2.9.3        HDR II
898                                THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
899                                  NO DETAILED DOCUMENTATION WILL BE PROVIDED.
900



      www.oserha.org                                          OSEHR System-Architecture, Product Definition and Roadmap   Page 2-3
901   Centralized Data Repositories::Health Data Repository (HDR)
902   Package HDR National (HDR II) v. 2.1.2
903   HDR National (HDR II) v. 2.1.2
904
905   Description: The ultimate database solution, HDR II, is a relational database that replaces HDR IMS, and stores
906   discrete data rather than messages. It enables providers to obtain integrated data views and acquire the patient-
907   specific clinical information needed to support treatment decisions. HDR II serves as the primary source of clinical
908   data for the legal medical record. It maintains data supporting core business functions and serves as a platform for
909   new and re-engineered HealtheVet applications.
910
911   Currently, HDR IMS and HDR II are both deployed.
912
913   HDR II is housed at the Austin Information Technology Center (AITC) in Austin, TX.
914
915   Programming Language:
916   • J2EE
917
918   Deployment Infrastructure:
919   • Research pending
920
921   Depends On:
922   Centralized Data Repositories
923   • Health Data Repository (HDR)
924     • HDR Clinical Data Services (CDS)
925     • HDR Historical (HDR Hx)
926   VistA 1.0
927   • CPRS: Adverse Reaction Tracking
928   • HL7 (VistA Messaging)
929   • Laboratory
930   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
931   • Vitals/Measurements
932   • VistA Data Extraction Framework (VDEF)
933   Master Patient Index (MPI)
934
935   The following entities depend on HDR National (HDR II):
936   VistA 1.0
937   • Home Telehealth
938   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
939   • VistAWeb
940   Department of Defense (DoD) Information Sharing
941   • Clinical Data Repository/Health Data Repository (CHDR)
942   Centralized Data Repositories
943   • Health Data Repository (HDR)
944     • HDR Clinical Data Service (CDS) 2.1.2



      www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap           Page 2-3
945
946   For more information, reference:
947   • VA Software Document Library (VDL): N/A
948   • VA Office of Enterprise Development Project Repository:
949     • HDR II Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=918&Type=Active
950   • VistA Monograph (2009): http://www4.va.gov/vista_monograph/
951   • Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
952
       class HDR II

            Name:      HDR II
            Package:   HDR II
                                                HDR-Health Data Repository
            Version:   Oct 2011
            Author:    OSEHRA




                                                                                        HDR-Hx HDR
            HDR Clinical Data Serv ices (CDS)               HDR II                       Historical




                                                                                    VistA 1.0




           DoD Information Sharing

                                                                              Master Patient Index (MPI)




953
954                                                         Figure 2-14
955
956   2.2.9.4     HDR Interim Messaging Service (IMS)
957                         THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
958                           NO DETAILED DOCUMENTATION WILL BE PROVIDED.
959
960   Centralized Data Repositories::Health Data Repository (HDR)
961   Package HDR Interim Messaging Solution (IMS)
962   HDR Interim Messaging Solution (HDR IMS)
963




      www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap   Page 2-3
 964   Description: HDR Interim Messaging Solution (HDR IMS) is an interim solution built to store data triggered from the
 965   current VistA systems to a centralized database while the HDR II solution is designed and implemented. Components
 966   of the Federal Health Information Exchange (FHIE) framework were reused as part of the interim solution. The HDR
 967   IMS was used as the VA database for the CHDR prototype (September 2004) to demonstrate data interfacing
 968   between DoD and VA. HDR IMS serves as the national database for storing information from Home TeleHealth. HDR
 969   data is visible from CPRS; VistAWeb is used to support Order Checks via the Remote Data Interoperability (RDI)
 970   subset of Pharmacy: Outpatient Pharmacy.
 971
 972   HDR IMS stores clinical data in a standard messaging format (HL7) from all VistA systems for a select number of
 973   clinical domains (vitals, outpatient pharmacy, allergies). It provides patient-centric data in a computable form to user
 974   interfaces such as Remote Data Interoperability (RDI), Clinical Health Data Repository (CHDR), Home Telehealth,
 975   and VistAWeb to support patient care.
 976
 977   The production environment is established at the Austin Information Technology Center (AITC).
 978
 979   Programming Language:
 980   • Java
 981   • Oracle
 982
 983   Deployment Infrastructure:
 984   • Unix
 985
 986   Depends On:
 987   VistA 1.0
 988   • HL7 (VistA Messaging)
 989   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
 990   • VistA Data Extraction Framework (VDEF)
 991   Master Patient Index (MPI)
 992
 993   The following entities depend on HDR Interim Messaging Solution (HDR IMS):
 994   VistA 1.0
 995   • Home Telehealth
 996   • Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)
 997   • VistAWeb
 998   Department of Defense (DoD) Information Sharing
 999   • Clinical Data Repository/Health Data Repository (CHDR)
1000   Centralized Data Repositories
1001   • HDR Clinical Data Service (HDR CDS)
1002
1003   For more information, reference:
1004   • VA Software Document Library (VDL): N/A
1005   • VA Office of Enterprise Development (OED) Project Repository:
1006     • HDR Interim Messaging Solution (IMS) Project Notebook
1007        http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=910



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 2-3
1008   •      VistA Monograph (2009): http://www4.va.gov/vista_monograph/
1009   •      HDR Interim Messaging Solution (HDR IMS) Documentation Webpage:
1010          http://vaww.vista.med.va.gov/hdr/HDR_IMS_Documents.html
1011   •      Health Data Systems Health Data Repository Fact Sheet:
1012          http://vaww.vista.med.va.gov/hdr/HDR_Fact_Sheet.pdf
1013   •      Health Data Repository PowerPoint Presentation::
1014          http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf
1015   •      Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
1016
           class HDR Interim Messaging Serv ice (IMS)

              Name:      HDR Interim Messaging Service (IMS)
              Package:   HDR Interim Messaging Service (IMS)
              Version:   Oct 2011                              HDR-Health Data
              Author:    OSEHRA                                  Repository




                         HDR Clinical Data
                          Serv ices (CDS)                        HDR Interim
                                                                  Messaging               DoD Information Sharing
                                                                 Serv ice (IMS)




                               Master Patient Index (MPI)           VistA 1.0




1017
1018                                                            Figure 2-15
1019
1020
1021   2.2.10 Corporate Data Warehouse (CDW)
1022                         THIS VA SPECIFIC CAPABILITY IS NOT A PART OF OSEHR;
1023                           NO DETAILED DOCUMENTATION WILL BE PROVIDED.
1024
1025   Description: The Veterans Health Administration (VHA) has created a corporate data warehouse specifically
1026   designed to facilitate business analysis. The purpose of this corporate data warehouse is to integrate information
1027   across many segments of the organization. This integrated environment will provide the foundation upon which
1028   analytical tools are applied to answer business questions and pursue clinical research.
1029



       www.oserha.org                                          OSEHR System-Architecture, Product Definition and Roadmap    Page 2-3
1030   The Corporate Data Warehouse (CDW) is a business driven information repository useful to key business
1031   stakeholders for strategic decision making. The information in the data warehouse is integrated, consistent, detailed,
1032   historical, cross-geographic, and cross-functional/cross-LOB (e.g., clinical, financial, administrative, research, public
1033   health, education, policy, performance and quality, patient safety, emergency management, surveillance). The CDW
1034   is an enterprise asset encompassing multiple subject areas and potentially enabling multiple departments/lines of
1035   business within VHA. Since CDW is an enterprise information asset, the information in the CDW is driven by strategic
1036   business drivers that enable betterment of process outcomes.
1037
1038   CDW is dependent upon the National Patient Care Database (NPCD) which is housed at the AITC.
1039
1040   The infrastructure, including necessary system and support personnel components, are deployed in the Austin
1041   Information Technology Center.
1042
1043   Programming Language:
1044   • SQL
1045
1046   Deployment Infrastructure:
1047   • SQL Servers
1048   • IIS Servers
1049
1050   Depends On:
1051   VistA 1.0
1052   • Decision Support System (DSS) Extracts
1053   Centralized Data Repositories
1054   • Health Data Repository (HDR)
1055     • HDR Historical (HDR Hx)
1056   Corporate Databases
1057   • National Patient Care Database (NPCD)
1058
1059   The following entities depend on Corporate Data Warehouse (CDW):
1060   • None
1061
1062   For more information, reference:
1063   VA Software Document Library (VDL): N/A
1064   VA Office of Enterprise Development (OED) Project Repository: N/A
1065   VistA Monograph (2009): N/A
1066   Application Profile: N/A




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 2-3
        class Corporate Data Warehouse (CDW)

            Name:      Corporate Data Warehouse (CDW)
            Package:   Corporate Data Warehouse (CDW)
                                                        Corporate Data Warehouse (CDW)
            Version:   Oct 2011
            Author:    OSEHRA




                                                         Centralized Data Repositories




            Corporate Databases                                                                         VistA 1.0




1067
1068                                                                    Figure 2-16
1069
1070   2.3 GT.M Subsystems
1071   GT.M, an abbreviation for Greystone Technology M, was developed by the Greystone Technology Corp in the 1980s.
1072   It is an implementation of ANSI standard M for various UNIX systems and OpenVMS. In addition to preserving the
1073   traditional features of M, GT.M also offers an optimizing compiler that produces object code that does not require
1074   internal interpreters during execution.GT.M is a high-throughput key-value database engine optimized for transaction
1075   processing. (It is a type also referred to as "schema-less", "schema-free," or "NoSQL.") GT.M is also an application
1076   development platform and a compiler for the ISO standard M language, also known as MUMPS.
1077
1078   The database engine, made open source in 2000, is maintained by Fidelity Information Services. GT.M is used as
1079   the backend of their FIS Profile banking application, and it powers ING DIRECT banks in the United States, Canada,
1080   Spain, France and Italy. It is also used as an open source backend for the Electronic Health Record system
1081   WorldVistA and other open source EHRs such as Medsphere's OpenVista. It is listed as an open source healthcare
1082   solution partner of Red Hat. Today it consists of approximately 2 million lines of code.GT.M consists of a language
1083   subsystem, a database subsystem, and utility programs. The language subsystem and database subsystem are
1084   closely integrated, but each is usable without the other. The language and database subsystems share common data
1085   organization and typing.
1086
1087   On GNU/Linux on x86-64 & IA-32 (x86), and on OpenVMS on Alpha/AXP, GT.M is released as Free / Open Source
1088   Software (FOSS) under the terms of the GNU Affero General Public License, version 3. On other platforms, it is
1089   available under proprietary licenses.
1090
1091   See http://tinco.pair.com/bhaskar/gtm/doc/books/ao/OpenVMS_manual/titlepage.html for GT.M Administration and
1092   Operations Guide.
1093


       www.oserha.org                                                 OSEHR System-Architecture, Product Definition and Roadmap   Page 2-3
1094   2.3.1 GT.M Language Subsystem
1095   Unlike the database where global variable nodes must fit within a database block, local variable strings can grow to
1096   1MB. The GT.M run-time provides dynamic storage allocation with garbage collection. The number of local variables
1097   and the number of nodes in local variables are limited only by storage available to the process. The default scope of
1098   a local variable is the lifetime of a process. Local variables created within routines using the New command have
1099   more limited scope.
1100
1101   GT.M routines are dynamically compiled and linked for execution in the address space of each process. With the
1102   exception of the 32-bit implementation of GT.M for the x86 GNU/Linux platform, object modules can also be placed in
1103   shared libraries with the standard ld command, in which case the memory used is shared. This is important because
1104   an application such as OSEHR has over 20,000 routines whose compiled object code exceeds 200MB. A large
1105   hospital running OSEHR can have thousands of concurrently running user processes.
1106
1107   With a couple of small exceptions, GT.M includes a nearly complete implementation of ISO standard M
1108   (affectionately known as MUMPS for historical reasons). In GT.M, M code can freely call out to C code (or code in
1109   other languages with a C compatible interface), and C code can freely call in to M code (so the top level program can
1110   be a C main()). For example is a GT.M module in CPAN and m_python for access from Python.
1111   Web services written in GT.M can be deployed under an Internet super server such as inetd or xinetd. Web enabled
1112   applications can use layered software such as EWD.
1113
1114   2.3.2 GT.M Database Subsystem
1115   The logical database of a GT.M process consists of one or more global variable name spaces, each consisting of
1116   unlimited number of global variables. For each global variable name space, a global directory maps global variables
1117   to the database files where they actually reside. An unlimited number of global variables can fit within one database
1118   file; a global variable must fit in one database file.
1119
1120   A database file consists of up to 224M (276,168,704) database blocks. A database block is a multiple of 512 bytes,
1121   with a maximum size of 65,024 bytes. Commonly used block sizes are 4KB, 8KB and 16KB - so, with an 8KB block
1122   size, an individual global variable can grow to 1,792GB. A global variable node (global variable, subscripts plus
1123   value) must fit in one database block and each block has a 16 byte overhead. So, the largest node that will fit in a
1124   database with a 4KB block size is 4,080 bytes. A key (global variable plus subscripts) can be up to 255 bytes.
1125
1126   The database engine is daemonless and processes accessing the database operate with normal user and group ids -
1127   a process has access to a database file if and only if the ownership and permissions of that database file (plus any
1128   layered access control such as SELinux permits access). Each process has within its address space all the logic
1129   needed to manage the database, and processes cooperate with one another to manage database files. When a
1130   database file is journaled, updates are written to journal files before being written to database files, and in the event
1131   of a system crash, database files can be recovered from journal files.
1132
1133   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
1134   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
1135   and m_python for access from Python. Web services written in GT.M can be deployed under an Internet super server
1136   such as inetd or xinetd. Web enabled applications can use layered software such as EWD.
1137



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 2-3
1138   2.3.3 GT.M Tools and Utility Subsystem
1139   GT.M provides utility programs to administer the system. All GT.M utilities follow the OpenVMS Command Definition
1140   conventions so that the user interface is consistent with other OpenVMS system components. All the utilities use the
1141   standard OpenVMS HELP facility.Each utility is summarized below.
1142
1143   GDE
1144   The Global Directory Editor (GDE) is a GT.M utility program that creates and maintains global directories. GDE
1145   provides commands for operating on the global directory.
1146
1147   MUPIP
1148   MUPIP (M Peripheral Interchange Program) is the GT.M utility program for general database operations, GT.M
1149   Journaling, Multi-site Database Replication, and some non-database operations.
1150
1151   The MUPIP commands are:
1152      BACKUP: Backup database files
1153      CONVERT: Converts M routines from a sequential "%RO" format into GT.M source files.
1154      CREATE: Create and initialize database files.
1155      EXIT: <CTRL-Z> terminates MUPIP and returns control to the process from which MUPIP was invoked.
1156      EXTEND: Expand the size of a database file.
1157      EXTRACT: Export data from database files into sequential (flat) files.
1158      FREEZE: Prevent updates to database files.
1159      INTEG: Check the integrity of GDS databases.
1160      INTRPT: Send an asynchronous signal to a GT.M process.
1161      JOURNAL: Recover database files (for example, after a system crash) and extract journal records.
1162      LOAD: Import data into databases.
1163      REORG: Defragment database files to improve performance.
1164      REPLICATE: Controls the operation of GT.M database replication from a primary instance to one or multiple
1165       instances.
1166      RESTORE: Restore databases from bytestream backup files.
1167      RUNDOWN: Properly close database files when processes terminate incorrectly.
1168      SET: Modify database and/or journal file characteristics.
1169      STOP: Stop GT.M processes.
1170
1171   LKE
1172   The M Lock Utility (LKE) is the GT.M utility program that examines and modifies the lock space where GT.M
1173   maintains the current M LOCK state. LKE can monitor the locking mechanism and remove locks.
1174
1175   Database Structure Editor (DSE)
1176   The Database Structure Editor (DSE) is the GT.M utility program to examine and alter the internal database
1177   structures. DSE edits GT.M Database Structure (GDS) files. It provides an extensive database "patch" facility
1178   (including block integrity checks), searches for block numbers and nodes, and provides symbolic examination and
1179   manipulation facilities. See Chapter 10: “Database Structure Editor” for more information.
1180




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 2-3
1181   2.3.4 GT.M-LINUX Operating System
1182   GT.M is fully supported on GNU/Linux on Itanium, x86_64 and IA-32 (x86) architectures. On GNU/Linux on the IA-32
1183   (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
1184   GNU/Linux on IA-32 (x86) includes changes needed to run on Cygwin on Microsoft Windows but this is not yet
1185   considered a supported platform.
1186
1187   Linux is a computer operating system which is based on free and open source software. Although many different
1188   varieties of Linux exist, all are Unix-like and based on the Linux kernel, an operating system kernel created in 1992
1189   by Linus Torvalds.
1190
1191   Linux can be installed on a wide variety of computer hardware, ranging from mobile phones, tablet computers,
1192   routers and video game consoles, to desktop computers, mainframes and supercomputers. Linux is a leading server
1193   operating system, and runs the 10 fastest supercomputers in the world.
1194
1195   The development of Linux is one of the most prominent examples of free and open source software collaboration;
1196   typically all the underlying source code can be used, freely modified, and redistributed, both commercially and non-
1197   commercially, by anyone under licenses such as the GNU General Public License. Typically Linux is packaged in a
1198   format known as a Linux distribution for desktop and server use. Some popular mainstream Linux distributions
1199   include Debian (and its derivatives such as Ubuntu), Fedora and openSUSE. Linux distributions include the Linux
1200   kernel, supporting utilities and libraries and usually a large amount of application software to fulfill the distribution's
1201   intended use.
1202
1203   The name "Linux" comes from the Linux kernel, originally written in 1991 by Linus Torvalds. The main supporting
1204   user space system tools and libraries from the GNU Project (announced in 1983 by Richard Stallman) are the basis
1205   for the Free Software Foundation's preferred name GNU/Linux.
1206
1207   2.3.5 Other (Optional) GT.M/LINUX Components
1208   A distribution oriented toward desktop use may include the X Window System, the GNOME and KDE Plasma
1209   desktop environments. Other distributions may include a less resource intensive desktop such as LXDE or Xfce for
1210   use on older or less-powerful computers. A distribution intended to run as a server may omit any graphical
1211   environment from the standard install and instead include other software such as the Apache HTTP Server and a
1212   SSH server like OpenSSH. Because Linux is freely redistributable, it is possible for anyone to create a distribution for
1213   any intended use. Commonly used applications with desktop Linux systems include the Mozilla Firefox web browser,
1214   the OpenOffice.org or LibreOffice office application suites, and the GIMP image editor.
1215
1216   M2Web is an open source web gateway to MUMPS for use with OSEHR. A free open source module from
1217   M/Gateway called MGWSI has been developed to act as a gateway between GT.M, Cache, or M21 MUMPS
1218   databases and programming tools such as PHP, ASP.NET, or Java, in order to create a web-based interface.
1219
1220   2.4 Caché Subsystems
1221   Caché is a Database Management System and application development environment, much like many in the Multi-
1222   Value market. The database is often referenced like a relational data source, making it popular among SQL users,
1223   but the internal structure is similar to MultiValue. The standard environment comes with a browser-based




       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap               Page 2-3
1224   administration dashboard, a development “Studio,” and an assortment of tools for browser UI development, web
1225   services, Java, .NET, XML, etc..
1226
1227   Caché was originally based on MUMPS. This database has a history remarkably similar to that of Pick and Prime.
1228   Our communities have similar passions for the power and simplicity of our chosen models. The markets were
1229   similarly fractionalized with competing products. Even today a few versions of MUMPS exist, just as there are many
1230   flavors of MultiValue. But InterSystems has largely consolidated that market. At a time when many MultiValue people
1231   still feel a little haunted by their heritage (think foot pedals, rap singers, and software that changes ownership every
1232   few years) most Caché people I’ve met are proud to acknowledge their roots. It’s not that their core technology has
1233   changed so much, though Caché is a significant improvement over its predecessors, but that InterSystems has
1234   fostered the validation of their technology in the eyes of the business and technical world.
1235
1236   Today, the Caché environment is associated with industry buzzwords like Post-Relational and Multi-Dimensional—
1237   terms also used to describe the MultiValue model. Caché is best regarded as an Object Oriented DBMS. This is not
1238   the same as Object-Relational which, while sounding more tech-savvy, is considered to be a weaker paradigm.
1239
1240   The OO-based Caché has native support for data objects and related code within the environment itself. Compare
1241   this to API connectivity to a flat relational environment from OO languages. I will explain more about this object-
1242   orientation in another article. However it’s categorized, Caché is fairly well recognized due to ongoing marketing
1243   campaigns by InterSystems. The database is featured in many IT and business magazines, articles, and success
1244   stories. It’s noted for performance, scalability, reliability, and tight security. In short, Caché is a proven and accepted
1245   mainstream platform, and now for our purposes it is also a MultiValue DBMS.
1246
1247   See http://docs.intersystems.com/ for Caché documentation
1248
1249   2.4.1    Caché Development Environment
1250
1251   Caché Studio
1252   Caché Studio is the primary development environment for Caché. The Studio lets you create class definitions, Caché
1253   Server Pages, and routines using a full-featured editor. Studio includes sophisticated syntax checking and coloring,
1254   graphical debugging, and a point-and-click class inspector. Caché Studio works directly with the Caché database (it
1255   is a Caché application) and offers multideveloper support as well as source control system integration. You can
1256   customize Studio through the use of Studio templates. For more information, see Using Caché Studio.
1257
1258   2.4.2 Caché Database Subsystem
1259   Caché is designed to transcend the limitations of the relational model while providing an evolutionary upgrade path
1260   for the thousands of existing relational database applications as well as support for the many SQL-based reporting
1261   tools on the market. In addition to being a high-performance object database, Caché is also a full-featured relational
1262   database. All the data within a Caché database is available as true relational tables and can be queried and modified
1263   using standard SQL via ODBC, JDBC, or object methods. Because of the power of the underlying Caché database
1264   engine, we believe that Caché is the fastest, most reliable, and most scalable relational database available today.
1265   What’s more, Caché offers a range of features that go beyond the limits of relational databases, while still supporting
1266   a standard relational view of data. These features include:




       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap               Page 2-4
1267       –   The ability to model data as objects (each with an automatically created and synchronized native relational
1268           representation) while eliminating both the impedance mismatch between databases and object-oriented
1269           application environments as well as reducing the complexity of relational modeling.
1270       – A simpler, object-based concurrency model.
1271       – User-defined data types.
1272       – The ability to take advantage of methods and inheritance, including polymorphism, within the database
1273           engine.
1274       – Object-extensions for SQL to handle object identity and relationships.
1275       – The ability to intermix SQL and object-based access within a single application, using each for what they are
1276           best suited.
1277       – Control over the physical layout and clustering used to store data in order to ensure the maximum
1278           performance for applications.
1279   While most databases with both object and relational access provide one form of access on top of the other, the SQL
1280   and object aspects of Caché both go directly to the data — so that users enjoy the performance benefit of either
1281   approach.
1282
1283   2.4.3 Caché Tools and Utilities Subsystem
1284   Caché includes a number of application development tools as well as database administration utilities. On a Windows
1285   system, these are accessible from the Caché cube icon within the Windows task bar. (Right-click on the icon. If you
1286   do not see this icon, open the Windows Start menu, find the Caché folder under Programs, and click on the Caché
1287   entry.) The various graphical utilities are client/server applications whose clients run on Windows systems but can be
1288   used with remote Windows, Linux, UNIX®, and OpenVMS server systems.
1289
1290   The Caché development tools and utilities include:
1291   Management Portal
1292   The Management Portal provides a Web-based interface for managing a Caché site. The Portal includes tools for
1293   system administrators, security managers, database operators, and any others needing access to Caché. Its
1294   administrative features allow you to set up a Caché system, view and alter its configuration parameters, adjust
1295   system settings, and create and edit databases and namespaces. Its database-browsing features include the ability
1296   to browse the contents of a Caché database, to examine data (globals) in the data engine; and to browse classes
1297   and routines — as well as monitoring database activity and performing backup operations. Its security-related
1298   features allow you to add, alter, and remove users, roles, resources, privileges, and to perform other security
1299   management tasks. Its SQL-related features provide a graphical, SQL-based view of a Caché database; you can use
1300   it to manage SQL roles and permissions, browse table and view definitions, execute ad hoc SQL queries, manage
1301   the query cache, and import and export data. For more information, see Caché System Administration Guide.
1302
1303   Caché Terminal
1304   Caché Terminal provides an interactive, command-line interface to Caché. You can use Terminal for direct
1305   interactions with the Caché database engine. The Terminal is an important tool for testing and troubleshooting
1306   applications. For information, see the manual Using Caché Terminal.
1307
1308   Caché DocBook




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 2-4
1309   The Caché DocBook application provides a fully searchable, Web-based interface to the documentation for Caché or
1310   any other installed InterSystems product. For an introduction to this application, see the “Basic Features” chapter of
1311   Using InterSystems Documentation.
1312
1313   2.4.4 Caché-Windows Operating System
1314   The NT family of Windows systems was fashioned and marketed for higher reliability business use. The first release
1315   was NT 3.1 (1993), numbered "3.1" to match the consumer Windows version, which was followed by NT 3.5 (1994),
1316   NT 3.51 (1995), NT 4.0 (1996), and Windows 2000, which is the last NT-based Windows release that does not
1317   include Microsoft Product Activation. Windows NT 4.0 was the first in this line to implement the "Windows 95" user
1318   interface (and the first to include Windows 95’s built-in 32-bit runtimes).
1319
1320   Microsoft then moved to combine their consumer and business operating systems with Windows XP that was
1321   released in August 2001. It came both in home and professional versions (and later niche market versions for tablet
1322   PCs and media centers); they also diverged release schedules for server operating systems. Windows Server 2003,
1323   released a year and a half after Windows XP, brought Windows Server up to date with Windows XP. After a lengthy
1324   development process, Windows Vista was released toward the end of 2006, and its server counterpart, Windows
1325   Server 2008 was released in early 2008. On July 22, 2009, Windows 7 and Windows Server 2008 R2 were released
1326   as RTM (release to manufacturing). Windows 7 was released on October 22, 2009.
1327
1328   64-bit operating systems
1329    Windows NT included support for several different platforms before the x86-based personal computer became
1330   dominant in the professional world. Versions of NT from 3.1 to 4.0 variously supported PowerPC, DEC Alpha and
1331   MIPS R4000, some of which were 64-bit processors, although the operating system treated them as 32-bit
1332   processors.
1333
1334   With the introduction of the Intel Itanium architecture (also known as IA-64), Microsoft released new versions of
1335   Windows to support it. Itanium versions of Windows XP and Windows Server 2003 were released at the same time
1336   as their mainstream x86 (32-bit) counterparts. On April 25, 2005, Microsoft released Windows XP Professional x64
1337   Edition and Windows Server 2003 x64 Editions to support the x86-64 (or x64 in Microsoft terminology) architecture.
1338   Microsoft dropped support for the Itanium version of Windows XP in 2005. Windows Vista was the first end-user
1339   version of Windows that Microsoft released simultaneously in x86 and x64 editions. Windows Vista does not support
1340   the Itanium architecture. The modern 64-bit Windows family comprises AMD64/Intel64 versions of Windows 7 and
1341   Windows Server 2008, in both Itanium and x64 editions. Windows Server 2008 R2 drops the 32-bit version, although
1342   Windows 7 does not.
1343
1344   Microsoft Windows CE 5.0
1345   Windows CE (officially known as Windows Embedded Compact), is an edition of Windows that runs on minimalistic
1346   computers, like satellite navigation systems and some mobile phones. Windows Embedded Compact is based on its
1347   own dedicated kernel, dubbed Windows CE kernel. Microsoft licenses Windows CE to OEMs and device makers.
1348   The OEMs and device makers can modify and create their own user interfaces and experiences, while Windows CE
1349   provides the technical foundation to do so.
1350




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 2-4
1351   Windows CE was used in the Dreamcast along with Sega's own proprietary OS for the console. Windows CE is the
1352   core from which Windows Mobile is derived. Microsoft's latest mobile OS, Windows Phone 7, is based on
1353   components from both Windows CE 6.0 R3 and the upcoming Windows CE 7.0.
1354
1355   Windows Embedded Compact is not to be confused with Windows XP Embedded or Windows NT 4.0 Embedded,
1356   modular editions of Windows based on Windows NT kernel.
1357
1358   Future of Windows
1359    Windows 8, the successor to Windows 7, is currently in development. Microsoft has stated that Windows 8 will be
1360   released late in 2012. Also, during the pre-Consumer Electronics Show keynote, Microsoft's CEO announced that
1361   Windows 8 will also run on ARM CPUs. Since ARM CPUs are usually in the form of SOCs found in mobile devices,
1362   this new announcement implies that Windows 8 will be more compatible with mobile devices such as netbooks, tablet
1363   personal computers, and smartphones.
1364
1365   2.4.5 Other (Optional) Caché/Windows Components
1366   An open source project called EsiObjects has also allowed the (ANSI- Standard) MUMPS language and database
1367   technology to evolve into a modern object-oriented language (and persistent-object store) that can be integrated into
1368   mainstream, state-of-the-art technologies. For the Caché MUMPS database, a similar object-oriented extension to
1369   MUMPS called Caché ObjectScript has been developed. Both of these have allowed development of the MUMPS
1370   database environment (by programmers) using modern object-oriented tools.
1371
1372   2.5 Product Roadmap
1373   An inclusive product roadmap cannot be done for this September 17, 2011 deliverable, because OSEHRA is not
1374   scheduled to be fully operational till October 17, 2011 and has not yet gotten the open source community feedback.
1375   See the Section 2.5.3 Plan of Actions and Milestones for details.
1376




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap            Page 2-4
1377   2.5.1    2011 System Architecture (Conceptual View)

                                           VistA “Front End”
                                           ANSI MUMPS (M)
                                                                           Graphical User
                                                 Applications             Interfaces GUIs)

                                                      APIs




                                                                                              M
                                                                                            Global
                                                                                            Access
                                               APIs                              RPCs




                                                                                   RPC
                                                                APIs

                                                       APIs
                                                                             RPC Broker
                                           Kernel/Tools                       VistALink
                                                      FileMan          M Global Access


                                           VistA “Database”
                                           ANSI MUMPS (M)                                M Global
                                           InterSystems Cache (Win)                       Files
1378                                       GT.M (Linux-UNIX)
1379                          Figure 2-13 Conceptual View of Legacy VistA System Architecture
1380
1381   Figure 2-1 shows a conceptual view of the 2011 OSEHR system architecture. Legacy OSEHR is predominantly
1382   coded in Ansi MUMPS (M) and can be run within the open source GT.M Linux/UNIX environment or within the
1383   InterSystems Cache Windows environment. At the conceptual level, OSEHR has the following major components:
1384         Applications, such as Scheduling, Pharmacy (Rx), Laboratory, Radiology, ADT plus 100+ other packages
1385         Kernel/Tools, such as Security, Menu Management, TaskMan, MailMan, Package Manager, etc.
1386         FileMan, which contains set of APIs, search, inquire, edit, print, utility functions, data dictionary utilities,
1387            transfer entries, etc.
1388         “Database”, which is composed of FileMan, which manages the M global namespaces and the Data
1389            Dictionary, which defines OSEHR’s hierarchical file layout for Apps., Rx, Lab, Images, Common Data, Plus
1390            over 100+ other files.
1391
1392   Typically, each OSEHR application module generates at-least-one global data file. Within these files are the clinical,
1393   administrative, and computer infrastructure-related information that supports day-to-day operations and contain
1394   patients' medical and healthcare utilization histories, including data on demographics, episodes of care, medicines,
1395   practitioner information, diagnoses, procedures.
1396




       www.oserha.org                                         OSEHR System-Architecture, Product Definition and Roadmap          Page 2-4
1397   2.5.2            Future-State Architecture (Conceptual View)
                                                                                                                                            iEHR is interoperable Electronic Healthcare Record
                                                                                iEHR Tier 1                                                 iEHR Common Data implies the native use of a single logical
                                                                             Front End Systems                                              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                                                               Security Controls support the NIST 7497 Security
                                                                                                Applications                                Architecture Design Process for Health Information
                                                                     Services                                                               Exchanges (HIEs) and DoD 8500 (series) Information
                                                                                                                                            Assurance controls.
                                                                                                                                            BITE is Built-In-Test-Environment for performance and
                                                                            Virtualization-Layer of Federated                               payload-data-integrity testing of ad-hoc trading-partners and
                                                                                                                                            plug-and-play applications; BITE uses Schematron.
                                                                               Standards-Based Services
                                                                                                                                            Schematron is a rule-based validation language.
         VLER is Virtual Lifetime Electronic Record
       NwHIN is Nationwide Health Information Network                              iEHR Tier 2
                                                                                   ESB Broker
                                                              Security
                                                              Controls                                          Terminology                                       CIIF
                      VLER                                                                                       Services
                                                                                                                                                              Design-Time
                                                              Service                 CIIF                                                                   Workbench of
                                                              Registry              Run Time                                                                  Model Driven
                                                    iEHR                                                          BITE
                                                                                                                              Metadata                    Health Tools (MDHTs)
                                                                                      Dynamic                                 Services
                                                   Gateway                                                       Services
                                                                Common              Translator for                                                      Metadata
                                                               Common                Structures,                                                                                   MDR
                                                                Services
                                                              Common                                                                                    Services
                                                               Services               Codes &
                                                              Services
                                                                                      Versions
              NwHIN Gateway                                                                                      Schema
                                                                                                                                                                             MDR is Meta Data Repository
                                                             Performance                                         Services
                                                               Caches
                     Secure                                                                                                              Information                                Metadata and rules
                Standards-Based                                                                                                             Model
             Information Exchanges                                          Virtualization-Layer of Federated
                                                                               Standards-Based Services

                                                                                iEHR Tier 3
              St Elsewhere                                                                                                                                                          SNOMED CT and Extensions,
                                                                             Back End Systems                                            Terminolgy
                                                                                                                                                                                    LOINC and RxNorm
                                                                         iEHR Common Data (CIIF Schemas)                                  Models
                 SSA / CMS                                                     Federated/Virtual Data                                                                               Payload = service, message.
                                                                                   Legacy Data                                                                                    Document or application-interface
                                                                                                                                                                                   information exchange content.
                         ...
                                                                               Data                                                                                                       Payload Models
              SSA is Social Security Administration                                                Data                                  Translation
                                                                              Services                                                                                                   Payload Schemas
        CMS is Center for Medicare and Medicaid Services                                          Stores                                   Models
                                                                                                                                                                                         BITE Schematron
1398
1399                                                              Figure 2-12 Future-State Architectural Vision
1400
1401   The future-state architectural vision presented here:
1402       • is a pragmatic, but, non-prescriptive starting point, which will be adjusted, based on open-source
1403           community’s feedback.
1404       • maintains interoperability with the legacy MUMPS and the DoD-VA iEHR architectural vision as well as
1405           accommodating commercial vendors.
1406       • Is based on standards to create virtual service layers of Application Program Interfaces (APIs) that support
1407           plug-and-play applications (e.g., the smartphone application market model) and various data repositories,
1408           ranging from single or client-server systems’ MUMPS FileMan to federated systems feeding a high
1409           performance Healthcare Data Repositories.
1410       • foster innovation at the component level and encourages Darwinian selection among competing
1411           components based on user’s cost, performance and support preferences.
1412       • can support
1413           – legacy or modern hardware and software platforms, languages, applications and databases.
1414           – scalability from minimal-cost individual-clinician-systems to enterprise-massively-parallel high-
1415              performance grids running on commodity-hardware-platforms (e.g., amazon.com, google.com models).
1416
1417   The key points of Figure 2-12 are:
1418    The joint DoD-VA iEHR Way modernization initiative’s Common Information Interoperability Framework (CIIF)
1419       information exchange component will be determined collaboratively with the VLER VCA1 Final Operational
1420       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-4
1421       capability to manage and maintain a lifelong Electronic Medical Record. The EHRWF initiative defines a
1422       Common Information Interoperability Framework (CIIF) to facilitate appropriate semantic interoperability among
1423       DoD, VA and partner EHR repositories. The EHRWF shall use Federally validated standards, particularly
1424       SNOMED-CT (the Systematic NOMenclature of MEDicine, Clinical Terms), combined with a Federally
1425       standardized clinical information model. Together these two components comprise the EHRWF Common
1426       Information Interoperability Format, or CIIF. While the CIIF is under development and in its early deployment,
1427       there may be a *gradual* VLER VCA1 transition to use CIIF prior to VCA1 December 2012 FOC as the DoD and
1428       VA transition to a common EHR environment.
1429      The Nationwide Health Information Network (NwHIN) is within VLER
1430      Applications-database decoupling
1431      iEHR 3-tier extendible architecture
1432      Use of Open Health Tools’ Model Driven Health Tools (MDHTs)
1433      CIIF is key to semantic interoperability
1434      CIIF Run-Time environment within iEHR
1435      CIIF Design-Time environment with-respect-to iEHR Run-Time
1436      BITE to facilitate performance & payload-data-integrity testing
1437      NIST 7497 Security Architecture Design Process for Health Information Exchanges (HIEs)
1438      DoD 8500 (series) Information Assurance Controls
1439
1440   The following problems are being addressed by the future-state architecture:
1441   1. Innovation to revitalize OSEHR. Services within a standards-based component-architecture encourage lower-
1442       cost component innovation without requiring enterprise-wide expertise and extensive testing. SDK empowers
1443       individuals and avoids stovepipes.
1444   2. Interoperability among DoD, VA, IHS and purchased care partners. CIIF canonical information and
1445       terminology models can be used to map among heterogeneous system information exchanges. By adopting
1446       common CIIF data, terminology, and communications standards; multiple organizations can share and ultimately
1447       harmonize Electronic Medical Records.
1448   3. Transition from legacy systems and data to an interoperable EHR architecture. Virtualization-Layers of
1449       Federated Standards-Based Services allow new and legacy COTS, GOTS and open-source applications,
1450       scaleable databases and infrastructure to coexist.
1451   4. Agility to respond to rapid healthcare changes and related legislation. Services within a standards-based
1452       component-architecture encourage faster and lower-cost changes to be made and tested within components
1453       without requiring enterprise-wide expertise and testing.
1454   5. High Costs of change and sustainment. Virtualization-Layers of Federated Standards-Based Services make
1455       plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and can
1456       be tested efficiently. Interchangeable-components can compete based, on functionality, quality, performance vs.
1457       cost, usability and supportability. Built In Test Environment (BITE) identifies faults early, improving robustness
1458       and reducing test costs. .
1459   6. Patient Safety issues resulting from software changes. Component architecture localizes faults. BITE
1460       identifies faults early, improving system robustness, patient safety.
1461   7. Open Source Community Enablement Virtualization-Layers of Federated Standards-Based Services support
1462       alternate configurations of applications, databases and infrastructure, which may be combinations of MUMPS,
1463       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-4
1464
1465   2.5.3 Plan of Actions and Milestones (POA&M)
1466   We had 30 days to produce the first OSEHR system architecture contract deliverable. To achieve this first deliverable
1467   we had an architecture team do a “time boxed” first pass through the 168 OSEHR packages/routines, based on the
1468   online OSEHR documentation library. We intend to continue to verify, validate and refine the fidelity of the 2011
1469   system architecture as we move to specifying the future-state Interoperable EHR (iEHR) architectural roadmap. We
1470   will further expand on the following:
1471          key features/attributes of As-Is and To-be, which are briefly covered in Sections 2.5.1 and 2.5.2.
1472          What are some major differences between the 2011 and future-state architectures? Why the difference? Is
1473              it historic? What requirements are driving the changes?
1474                    o These are briefly covered in Section 2.5.2.
1475          What is to be changed? What will be added? What will be deleted or replaced? From an architectural
1476              perspective, what is the priority of changes?
1477                    o Briefly, the highest priority is to transition to a 3-tiered architecture with a well specified Software
1478                         Development Kit (SDK)
1479          What is the implications of these changes or additions? Would the changes become useful incrementally or
1480              do we have to wait till a lot of changes are implemented before they useful?
1481                    o Briefly, going to a 3-tiered architecture with well specified service layers, allows innovation at the
1482                         module level, rather than globally, which is the current situation.
1483          What would be a good sequence of changes/addtions from an architectural perspective? Ar serial changes
1484              and parallel activities possible?
1485                    o Once the 3-tierd architecture is established, then parallel development/procurement becomes
1486                         practical.
1487          How will we track changes in architecture during this project.
1488                    o Briefly, The tool can filter and show 2011 views versus “Future State” views
1489          How can this document be used to track changes in architecture?
1490                    o Briefly, as we go forward, we will show the 2011 views, Future State views and any transition views
1491                         in the Roadmap.
1492
1493   Following is the year “1” OSEHRA System Architecture (SA) and Product Definition (PD) POA&M
1494        17 Jun 11 – Custodial Agent contract signed
1495        17 Aug 11 – OSEHRA Custodial Agent established as a non-profit organization
1496        17 Sep 11 – Phase 1: 2011 Initial Baseline
1497                o Based on VistA Documentation Library
1498                o 168 Modules modeled as UML Class Elements, including
1499                         Module descriptions
1500                         Module functions/features included in descriptions
1501                         Module-module install dependencies
1502                         Module-data dependencies
1503                o SA Report delivered as Contract Deliverable (CDRL)
1504                o HTML web browsable SA on OSEHRA web site
1505                o Task 5.9 2011 System Architecture Baseline CDRL
1506                         Combined Task 5.9 SA & Task 5.11 PD Report
1507                o Task 5.11 2011 Product Baseline (Build Definition) CDRL



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                Page 2-4
1508                        Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
1509         Sep-Dec - OSEHRA website periodically updated as Phase 2 work is done.
1510              o Community SA and PD Discussions Forums
1511              o Cleanup-tasks
1512                        De-conflict duplicate namespaces and duplicate modules
1513                        Add master list of Namespaces, based on VA internal feedbach.
1514                        Investigate modules without documentation
1515                        Harmonize ICRs (aka DBIAs) across SA, based on VA internal documentation
1516                        Add missing APIs, RPCs and Component Diagrams
1517                        Add patchs to module-diagrams and map patches-to-modules
1518                        Map Namespaces-to-modules and visa-versa
1519                        Incorporate Xindex mapping of modules-to-routines and modules-to-data files
1520                        Create/Obtain GT.M and Cache build
1521                                Map namespaces-to-files
1522                                Map namespaces-to-routines
1523                        Verify OSEHR SA versus VA Research Group architecture artifacts
1524              o HTML web browsable SA on OSEHRA web site
1525         17 Oct 11 – OSEHRA is Fully Operational
1526              o Architecture Working Group (AWH) established
1527              o SA and PD Community Forums established
1528         17 Dec 11 - Phase 2: 2011 Verified Baseline
1529              o 168 Modules modeled as UML Classes & Components, including
1530                        Application Program Interfaces (APIs) modeled as UML Components
1531                        Remote Procedure Calls (RPCs)
1532                        Data Base Integration Agreements (DBIAs) modeled as UML Associations
1533                        Verified Module functions/features included in descriptions
1534                        Verified Module-module dependencies
1535                        Verified Module-data dependencies
1536              o Updated SA Report CDRL
1537                        Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
1538              o Updated HTML web browsable SA on OSEHRA web site
1539              o Task 5.9 Updated & Verified 2011 SA Baseline
1540              o Task 5.11 Updated & Verified 2011 PD Baseline & Roadmap
1541         Dec-Mar - OSEHRA website periodically updated as Phase 3 work is done.
1542              o Community SA and PD Discussions Forums
1543              o HTML web browsable SA on OSEHRA web site
1544         17 Mar 12 - Phase 3: iEHR 2012 Strawman Future-State Specifications
1545              o iEHR 2012 Strawman Future-State SA is a brainstormed System Architecture intended to
1546                  generate discussion of its (dis) advantages and to provoke the generation of new and better
1547                  proposals.
1548              o Strawman DoD-VA Interoperable EHR (iEHR) Specifications
1549                        Using HL7 Service Aware Interoperability Framework (SAIF)
1550              o Strawman Software Development Kit (SDK)
1551              o Strawman SA Report CDRL



       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap    Page 2-4
1552                        Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
1553              o Strawman HTML web browsable SA on OSEHRA web site
1554              o Task 5.9 Strawman 2012 Future-State System Architecture Baseline
1555              o Task 5.11 Strawman 2012 Future-State Product Baseline & Roadmap
1556         Mar-Jun - OSEHRA website periodically updated as Phase 4 work is done.
1557              o Community SA and PD Discussions Forums
1558              o HTML web browsable SA on OSEHRA web site
1559         17 Jun 12 - Phase 4: 2012 Ironman Future-State SA Speifications
1560              o Ironman Future-State SA Specification is a harmonized proposed System Architecture intended
1561                  to generate plans for its implementation and to provoke the generation of new and better design
1562                  specifications.
1563              o Ironman DoD-VA iEHR Specifications
1564                        Using HL7 SAIF
1565              o Ironman SDK Specifications
1566              o Ironman SA Report CDRL
1567                        Combined Task 5.9 SA & Task 5.11 PD Report generated by SA tool
1568              o Ironman HTML web browsable SA on OSEHRA web site
1569              o Task 5.9 Ironman 2012 Future-State SA Baseline
1570              o Task 5.11 Ironman 2012 Product Baseline & Roadmap
1571
1572




       www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap         Page 2-4
1573   3 System Architecture (SA)
1574   The OSEHR System Architecture contains the Financial-Administrative, Infrastructure, HealteVet, Clinical sub-
1575   sections. First we document the OSEHR System Architecture (SA) process. The OSEHR System Architecture is a
1576   living document, updated at least quarterly, being constructed incrementally based on the following source materials:
1577        1. modules modeled as classes, based on VistA-HealtheVet Monograph
1578            a. modules modeled as UML classes
1579            b. module definitions
1580        2. module dependency models, based on existing package documents
1581            a. Component UML class dependencies
1582                 i. module-module dependencies
1583                ii. module-data dependencies
1584               iii. deployment-dependencies
1585        3. SA Functional Models, showing modular functional-descriptions
1586            a. based on HL7 EHR System Functional Model (EHR-S FM)
1587            b. Including EHR-S FM conformance criteria to support test and certification
1588            c. ARRA Meaningful use objectives and criteria
1589            d. Applicable HHS mandated HITSP-constructs and other HHS mandated standards.
1590        4. Verified and Validated Open Source Baseline SA Model, based on
1591            code reviews and analysis by the Custodial Agent (CA) and open source community.
1592
1593
1594




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-5
1595   3.1 Clinical
1596   Clinical Health Data Systems (HDS) supports the mission of Veterans Health Information Technology (IT) by
1597   providing complete, accessible, longitudinal, veteran-centric data to the end-user applications of the enterprise. This
1598   work is accomplished through four major program areas:
1599   1. Standards & Terminology Services
1600   2. Repositories
1601   3. Registries
1602   4. Health IT Sharing
1603
1604   Standards & Terminology Services (STS) develops, implements, and maintains authoritative data standards, and
1605   enables the interoperability and exchange of standardized and computable information between VA information
1606   technology (IT) systems and with government and private health care partners.
1607
1608   The Repositories Program supports storage of enterprise-wide, veteran-centric clinical and administrative data via
1609   the Health Data Repository (HDR) and Administrative Data Repository (ADR) products. Repository data supports
1610   data needs of current and future VA IT software programs. The HDR Data Warehouse meets the data needs of the
1611   VA research and analysis community without impacting database performance for the end-users.
1612
1613   The Registries Program supports the population-specific data needs of the enterprise including, but not limited to,
1614   Oncology Tumor Registry, Traumatic Brain Injury Registry, Embedded Fragment Registry and Eye Trauma Registry.
1615
1616   The Healthcare Associated Infection and Influenza Surveillance System (HAIISS) monitors data in VA’s integrated IT
1617   systems to identify potential disease, bioterrorism, or healthcare-associated infection outbreaks.
1618




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-5
       class Clinical

                 Name:          Clinical
                 Package:       Clinical
                 Version:       Oct 2011
                 Author:        OSEHRA


                  ADT/Registration              AIT          AMT-Anticoagulation       AR/WS             ASCD            BCMA        Beneficiary Trav el             Blind                   CHDR                 CPRS
                                                              Management Tool                                                                                     Rehabilitation




                       CPRS:                    ASU              CPRS: CR           CPRS: Consult/    CPRS: Health   CPRS: Problem   Care Management                  CCR                     CP                 Data
                   ART-Adv erse                                                    Request Tracking     Summary           List                                                                               Standardization
                  Reaction Tracking




                                                                                                                                                           HDR-Health Data Repository
                        Dentistry              EDIS                 EPI                  EWL              FIM         Group Notes          HBPC                     HDR-Hx              Home Telehealth            ICR




                         IEMM                   IRT                 I&O                 LEDI           Laboratory         AP         Laboratory: Blood          Laboratory: Blood       Laboratory: How dy      Laboratory:
                                                                                                                                           Bank                       Bank                Computerized           National
                                                                                                                                                                  Workarounds           Phlebotomy Login     Laboratory Tests
                                                                                                                                                                                             Process         (NLT) Documents
                                                                                                                                                                                                                and LOINC
                                                                                                                                                                                                               Request Form




                           UI              Lexicon Utility         MED                  MRSA            Medicine         MHA                NFS                       NHIN                  Nursing          OncoTraX: Cancer
                                                                                                                                                                                                                 Registry




                         PADP                   PAIT         PBM-Pharmacy:               PCE             PCMM            PIMS               POC                       PPP                   CMOP                    CS
                                                                Benefits
                                                              Management




                          PDM                    DA            Pharmacy:                 NDF              OP          Prosthetics        QUASAR                     RAI/MDS                  ROES              Radiology/
                                                                Inpatient                                                                                                                                    Nuclear Medicine
                                                               Medications




                          STS               Scheduling       Shift Handoff Tool      Social Work          SCD           Surgery             TBI                    Terminology              VBECS                  VIST
                                                                                                                                                                     Serv ices




                   Virtual Patient         Visit Tracking     VistA Imaging           VistAWeb           Vitals/          WH                TIU                      ASI-MV                   PRF
                       Record                                     System                              Measurements




1619
1620                                                                                                     Figure: 3.1-1
1621
1622   3.1.1 ADT-Admission, Discharge, Transfer/Registration
1623   The Admission, Discharge, Transfer (ADT) module provides a comprehensive range of software dedicated to the
1624   support of administrative functions related to patient admission, discharge, transfer, and registration. The functions of
1625   this package apply throughout a patient's inpatient and/or outpatient stay, from registration, eligibility determination
1626   and Means Testing through discharge with on-line transmission of Patient Treatment File (PTF) data to the Austin
1627   Information Technology Center (AITC).
1628
1629   The ADT software also aids in recovery of cost of care by supplying comprehensive PTF/RUG-II and Means Test
1630   software. The ADT module functions as the focal collection point of patient information, encompassing demographic,
1631   employment, insurance, and medical history data. Many other modules, such as Laboratory, Pharmacy, Radiology,
1632   Nursing, and Dietetics, utilize information gathered through the various ADT options. Several features have been
1633   designed to maximize efficiency and maintain control over user access of specified sensitive patient records. The
1634   Patient Sensitivity function allows a level of security to be assigned to certain records within the database (i.e.,
1635   records of employees, government officials, etc.) in order to maintain control over unauthorized user access. The
1636   Patient Lookup function screens user access of these records. It also provides for efficient and faster retrieval of
1637   patient records and identified potential duplicate patient entries. The ADT module allows for efficient and accurate
1638   collection, maintenance, and output of patient data, thus enhancing a health care facility’s ability to provide quality
1639   care to its patients. The functions within ADT currently fall into seven major categories: Application Processing
1640   (registration), Bed Control (inpatient movements), Inpatient Care Grouping (DRG)/Long Term Care Grouping (RUG),
1641   Data Transmission to National Database (PTF and RUG), Patient Assessment Instrument (PAI), Supervisor
1642   Functions (system setup and maintenance), and Local/National Management Reporting.
1643
1644   Features


       www.oserha.org                                                                                 OSEHR System-Architecture, Product Definition and Roadmap                                                                 Page 3-5
1645   •   Provides on-line patient registration and disposition of applications for medical care.
1646   •   Tracks patient movements during inpatient stays.
1647   •   Provides up-to-date on-line patient information.
1648   •   Generates numerous managerial and statistical reports.
1649   •   Performs patient data consistency checks.
1650   •   Supports the flagging and monitoring of patient records deemed to be sensitive.
1651   •   Enrolls patients in the VA Patient Enrollment System during the registration process.
1652   •   Uses industry standard International Classification of Diseases (ICD)/Current Procedural Terminology (CPT)
1653       codes.
1654   •   Aids in cost recovery of care by supplying comprehensive PTF/RUG-II, Means Test, and pharmacy co-pay
1655       software.
1656




       www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap         Page 3-5
1657
1658                     Figure: 3.1-3
1659




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-5
1660   ADT-Admission, Discharge, Transfer / Registration - (Component diagram)




1661
1662                                                       Figure: 3.1-4
1663
1664   3.1.2 Ambulatory Care Reporting
1665   The Ambulatory Care Reporting Project (ACRP) enhances the process of collecting and storing encounter-based
1666   clinical, diagnostic, and administrative outpatient andinpatient data for daily transmission to the Austin Automation
1667   Center (AAC).
1668
1669   The Ambulatory Care project will be working in concert with the National Patient Care Database project (NPCDB).
1670   The two projects have common objectives.
1671   • Capture and record selected demographic data about the patient
1672   • Identify the date and time services were provided
1673   • Identify what was done, why it was done, and who provided the services
1674   • Move the information from VISTA to the NPCDB via an Event Driven Reporting mechanism for the purpose of
1675       workload credit.


       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-5
1676
1677   Collecting more specific and encounter-based clinical, diagnostic, and administrative data will enable more detailed
1678   analysis of VHA’s outpatient and inpatient healthcare activity. Tracking the amount of care provided across the types
1679   of healthcare services offered will be key in the calculation of corporate costs. The information will also be a valuable
1680   database for resource utilization studies, forecasting, and healthcare planning for the future.
1681   All options in the ACRP Reports menu have been modified to return multiple reports when multiple divisions are
1682   selected. For example, if you select division A and division B, the output will contain a report for division A, a report
1683   for division B, and a report that reflects the combination of divisions A and B.
1684
1685   The following is a brief description of the options contained in the Ambulatory Care Reporting Menu.
1686
1687   ACRP Reports Menu
1688    ACRP Ad Hoc Report Menu
1689    Error Listing
1690    Transmission Reports
1691    Supervisor Ambulatory Care Menu
1692    Data Transmission Report
1693    Incomplete Encounter Management
1694    Retransmit Ambulatory Care Data by Date Range
1695    Retransmit Selected Error Code
1696    Selective Retransmission of NPCDB Rejections
1697
1698   The ACRP Interface Toolkit (AIT) is a set of programmer tools that provides access to outpatient encounter data.
1699   This initial version contains Application Programmer Interfaces (APIs) and Remote Procedure Calls (RPCs) that
1700   provide access to procedure, diagnosis, provider, and general data related to an encounter. It is hoped that in a
1701   future version of the AIT, Delphi objects, components, and DLLs will be provided as well.
1702
1703   This AIT provides Class I packages, Class III software, and other local code with one highly structured interface to
1704   the encounter data.
1705
1706   Scheduling V. 5.3
1707       Ambulatory Care Reporting Project (ACRP)
1708       Incomplete Encounter Management Module (IEMM), part of the Ambulatory Care Reporting Project (ACRP)
1709          Phase II. Installation adds the IEMM menu to the Ambulatory Care Reporting menu. This new menu
1710          contains the Incomplete Encounter Reports submenu and the Correct Incomplete Encounters option.
1711
1712   Please refer to SD*5.3*66 for a complete description of the Incomplete Encounter Management Module patch.
1713
1714   This package contains KIDS builds from three software packages. Minimally, the following three base packages must
1715   be installed to install this package.
1716         PCE V. 1.0
1717         Registration V. 5.3
1718         Scheduling V. 5.3
1719   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-5
1720
1721                     Figure: 3.1-5
1722




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-5
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)
                                                                                 Remote Procedure Calls
           Interface Toolkit (AIT)
                                                                                 SDOE Assigned a Diagnosis
           January 1998
                                                                                 SDOE Assigned a Procedure
                                                                                 SDOE Assigned a Provider
           Introduction                                                          SDOE Find Diagnosis
           Application Programmer Interfaces                                     SDOE Find First Encounter
           56 - SDOE Get Diagnoses                                               SDOE Find First Standalone
           58 - SDOE Get Providers                                               SDOE Find Last Standalone
           61 - SDOE Get Procedures                                              SDOE Find Procedure
           63 - SDOE Assigned a Provider                                         SDOE Find Provider
           64 - SDOE Assigned a Diagnosis                                        SDOE Get Diagnoses
           65 - SDOE Assigned a Procedure                                        SDOE Get General Data
           69 - SDOE Find Provider                                               SDOE Get Primary Diagnosis
           70 - SDOE Find Diagnosis                                              SDOE Get Procedures
           71 - SDOE Find Procedure                                              SDOE Get Providers
           72 - SDOE Find First Standalone                                       SDOE Get Zero Node
           73 - SDOE Get Primary Diagnosis                                       SDOE List Encounters for Dates
           74 - SDOE Find First Encounter                                        SDOE List Encounters for PAT
           75 - SDOE Find Last Standalone                                        SDOE List Encounters for Visit
           76 - SDOE Get General Data                                            SDOE Parse 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                                                           Figure: 3.1-6
1726



       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap   Page 3-5
1727   3.1.3 AMT-Anticoagulation Management Tool
1728   The tool enables the user to enter, review, and continuously update all information connected with patient
1729   anticoagulation management. With the Anticoagulation Tracking, one can order lab tests, enter outside lab results
1730   and graphically review lab data, enter notes, complete encounter data, complete the consults if consults are used to
1731   initiate entry into the Anticoagulation clinic, and print a variety of patient letters. Upon exiting the program all activities
1732   within the program are recorded on an Anticoagulation flow sheet maintained on the Computerized Patient Record
1733   System (CPRS) Reports tab. The Anticoagulation Tracking provides clinic staff a mechanism of ensuring continuous
1734   patient monitoring with a built-in mechanism that alerts staff when patients haven’t been monitored in a timely period.
1735   A Lost to Follow-up list is maintained to ensure that staff knows of patients who need attention
1736




1737
1738                                                           Figure: 3.1-7
1739
1740   3.1.4 ASCD-Automated Service Connected Designation
1741   Enhancements to the VistA Legacy Mumps application to automate the clinician’s decision-making process when
1742   marking a patient encounter either Service Connected (SC) or Non-Service Connected (NSC) within the Patient Care
1743   Encounter (PCE) and Scheduling packages.




       www.oserha.org                                         OSEHR System-Architecture, Product Definition and Roadmap                  Page 3-5
1744
1745                                                       Figure: 3.1-8
1746
1747   3.1.5 Beneficiary Travel
1748   The Beneficiary Travel module provides the ability to perform the functions involved in issuing beneficiary travel pay.
1749   Travel reimbursement is provided to specified categories of eligible veterans. It is also provided to non-employee
1750   attendants who are eligible for such reimbursement. These attendants will be issued travel pay under the veteran's
1751   name.
1752
1753   Payment for travel by special mode (ambulance, handicapped van, etc.) may be authorized if medically necessary
1754   and approved before travel begins, except in cases of medical emergency where delay would be hazardous to life or
1755   health.
1756
1757   For certain claims, the system will compute the amount payable from factors such as account type, parameter set-up
1758   of deductible amount per visit and per month, one-way or round-trip mileage, and applied costs.



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-6
1759
1760   Features
1761   • Automatically computes the amount payable for claims with an account type of Compensation and Pension.
1762   • Allows each site to define and edit site-specific beneficiary travel parameters.
1763   • Produces a variety of statistical reports for a specified date range.
1764   • Provides the ability to reprint the standard pre-formatted beneficiary travel form for cash reimbursement.




1765
1766                                                        Figure: 3.1-9
1767
1768   3.1.6 Blind Rehabilitation
1769   The Blind Rehab application provides enhanced tracking, and reporting, of the blind rehabilitation services provided
1770   to veterans by:
1771   • Visual Impairment Service Teams (VIST) Coordinators
1772   • Blind Rehabilitation Centers (BRCs)
1773   • Blind Rehabilitation Outpatient Specialists (BROS)
1774   • Visual Impairment Services Outpatient Rehabilitation (VISOR) Programs
1775   • Visual Impairment Center to Optimize Remaining Sight (VICTORS)
1776
1777   Currently, there is no VistA software that meets the needs of the Blind Rehabilitation Centers or BROS and the VIST
1778   4.0 package only monitors, tracks, and reports on a limited amount of data for the VIST.
1779
1780   The site-based VIST 4.0 package is being replaced with the re-hosted Blind Rehabilitation (BR) Version 5.0
1781   application supporting the HealtheVet-VistA enterprise architecture. In addition to providing the base functionality of
1782   the BR 4.0 system, BR 5.0 provides a web-enabled GUI through which users can access enhanced capabilities
1783   intended for VIST Coordinators, new functionality for BROS, BRC personnel and waiting times and waiting list.
1784
1785   The Blind Rehabilitation 5.0 application provides entirely new functionality that encompasses and integrates all five
1786   segments of the Blind Rehabilitation Services including waiting times and waiting list.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-6
1787
1788                                                      Figure: 3.1-10
1789
1790   3.1.7 Care Management
1791   The Care Management project was initiated because VA healthcare professionals needed an application that could
1792   display order and result information for a relevant panel of patients. The four applications (known as “perspectives”)
1793   that comprise Care Management—Clinician Dashboard, Nurse Dashboard, Sign List, and Query Tool—provide a
1794   complement to, rather than a replacement for, the single-patient view offered by the Computerized Patient Record
1795   System (CPRS).
1796
1797   Key features:
1798   • An intuitive graphical user interface (GUI)
1799   • Pre-defined and custom patient lists to provide an at-a-glance view of multiple patients who have items that
1800       require attention
1801   • Editable, linkable tasks to help track important follow-up items
1802   • A multi-patient, multi-item sign list to reduce administrative time
1803   • Color-coded icons to indicate the status of items that require attention
1804   • Flexible, pre-defined and custom reports to extract the most current data available for a variety of criteria.
1805
1806   Care Management Perspectives
1807   • Clinician Dashboard The Clinician Dashboard provides clinicians with an easy-to-read table that lists patients
1808       who have items that need attention. The table allows clinicians to quickly and easily view healthcare information.



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-6
1809       For example, you can use the Clinician Dashboard to quickly determine which patients have order results that
1810       should be reviewed or acknowledged, or documents that need to be signed.
1811   •   Nurse Dashboard The Nurse Dashboard provides nurses with an easy-to-read table that lists patients who have
1812       items that require a nurse’s attention. For example, you can use the Nurse Dashboard to quickly determine
1813       which patients have orders that need to be verified. The Nurse dashboard also displays patients’ vitals.
1814   •   Query Tool The Query Tool allows you to create reports based on patient data. You can use the five predefined
1815       reports (Abnormal Results, Consult Status, Incomplete Orders, Recent Activity, and Scheduled/Due Activity) or
1816       you can create a custom report.
1817   •   Sign List The Sign List allows you to sign multiple items for multiple patients. For example, using the Sign List
1818       you could sign a discharge summary for John Smith and notes for Jane Smith simultaneously. The types of
1819       items that appear on your Sign List depend on which dashboard you are using. Items that appear on the Sign
1820       List for the Clinician Dashboard include unsigned and un-cosigned clinical documents. Items that appear on the
1821       Sign List for the Nurse Dashboard include unverified orders and completed text orders.
1822
1823   The Care Management software package requires three separate installation procedures: one for installing M-
1824   specific components on your M server, one for installing Java components on the HealtheVet Desktop/Care
1825   Management server, and one for installing Java components on users’ workstations.




1826
1827                                                        Figure: 3.1-11
1828   3.1.8 Clinical Case Registries
1829   The Clinical Case Registries (CCR) software application supports the maintenance of local and national registries for
1830   clinical and resource tracking of care for patients with certain clinical conditions. Registries for Hepatitis C
1831   (CCR:HEPC) and Human Immunodeficiency Virus (CCR:HIV) are available. This application allows access to
1832   important demographic and clinical data on all VHA patients with these conditions, and provides many capabilities to
1833   VA facilities that provide care and treatment to patients with these conditions, including clinical categorization of
1834   patients and automatic transmission of data to the VA's National Case Registry. It also provides clinical and
1835   administrative reports for local medical center use.
1836
1837   CCR accesses several other Veterans Health Information Systems and Technology Architecture (VistA) files that
1838   contain information regarding other diagnoses, prescriptions, surgical procedures, laboratory tests, radiology exams,




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-6
1839   patient demographics, hospital admissions, and clinical visits. This access allows identified clinical staff to take
1840   advantage of the wealth of data supported through VistA.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-6
www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-6
1842                                                      Figure: 3.1-12
1843
1844   Clinical Case Registries - (Component diagram)
                      cmp Clinical Case Registries

                        Name:        Clinical Case Registries
                        Package:     Clinical Case Registries
                        Version:     1.0
                        Author:      Karen Kirkpatrick




                                             Clinical Case Registries


                                                           «interface»
                                                          Clinical Case
                                                                              National CCR Database
                                                           Registries::
                                                          National CCR
                                                            Database


                                                          «interface»
                                                         Clinical Case        Med Proc (EKG)
                                                        Registries::Med
                                                          Proc. (EKG)


                                                            «interface»
                                                          Clinical Case
                                                           Registries::
                                                           Automated          AMIS
                                                          Management
                                                           Information
                                                              System

1845
1846                                                      Figure: 3.1-13
1847
1848   3.1.9 Clinical Procedures
1849   Clinical Procedures (CP) is a new VistA package that provides features that can be used across clinical departments,
1850   such as general medicine, cardiology, pulmonary, women’s health, neurology, and rehabilitation medicine. CP is a
1851   conduit for passing patient results, using HL7 messaging, between the vendor and VistA. Patient test results are
1852   displayed in the Computerized Patient Record System (CPRS). CP includes three modules, which are CP User, CP
1853   Manager, and CP Gateway.
1854



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-6
1855   CP User is the primary application that clinicians use. For example, you can place an order for a procedure, such as
1856   an EKG, through the Consults tab or Orders tab in CPRS, or Order Entry. Then you can use CP User to check in a
1857   patient and initiate the actual procedure. If the procedure is performed on a bi-directional instrument, the patient
1858   demographics are automatically transmitted to the instrument. When the procedure is complete, the result is
1859   transmitted back to VistA Imaging and attached to a TIU note/document that is associated with the original procedure
1860   order. If the procedure is performed on a uni-directional instrument, you use CP User to match the instrument results
1861   to the requested procedure. The TIU note is created when the instrument results are submitted to VistA Imaging.
1862   Standard Consults functionality is used to complete and sign the TIU note. The main purpose of CP User is to link the
1863   results from the automated instrument to the procedure ordered through Consults in CPRS.
1864
1865   System managers and clinical application coordinators use CP Manager. The main purpose of this application [CP
1866   Manager] is to add and edit automated instruments and procedures in the CP database. CP Manager is also used to
1867   configure the site files and required system parameters.
1868
1869   CP Gateway manages the flow of information from the instrument interfaces to CPRS. CP Gateway polls the system
1870   regularly for new data from instruments and processes this data into usable attachments for the VistA Imaging
1871   system.
1872
1873   Hemodialysis is a new module [1.0*6] of the Clinical Procedures (CP) package that provides features specific to
1874   hemodialysis treatment. Hemodialysis allows you to collect hemodialysis treatment information from the medical
1875   device, and manually enter treatment data into the application. Pre-dialysis vitals, information obtained during
1876   treatment, and post-dialysis vitals can be entered into the Hemodialysis data entry screens. A Treatment Summary is
1877   created and used to fill out Centers for Medicare & Medicaid Services (CMS)/End Stage Renal Disease (ESRD)
1878   forms.
1879
1880   The Clinical Flowsheets patch [1.0*16] of the Clinical Procedures (CP) package provides an electronic representation
1881   of the traditional paper flowsheet maintained during each inpatient stay. Vitals, Intake/Output, Wound Documentation,
1882   etc., are examples of data types that can be recorded via Clinical Flowsheets into the Veterans Health Information
1883   System and Technology Architecture (VistA) system. Clinical Flowsheets provides a departure from its predecessor
1884   applications by storing collected information as discrete data. Some date elements, such as vital signs, are available
1885   to the Vitals Package and Computerized Patient Record System (CPRS). Various reports built on the other data
1886   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-6
1887
1888                                                     Figure: 3.1-14
1889
1890   3.1.10 CHDR-Clinical/ Health Data Repository
1891   The Department of Defense (DoD) and the Department of Veterans Affairs (VA) in partnership, designed and
1892   implemented a Clinical Data Repository/Health Data Repository (CHDR) system that generates standards-based,
1893   computable electronic health records that can be exchanged and shared between the two agencies healthcare
1894   systems. The computable data can then be divided into fields and can be sorted, rather than provided as unsortable
1895   text.
1896



       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap           Page 3-6
1897   Medical records and patient health care histories are stored and maintained in a centralized repository at each
1898   agency. Medical records entered and maintained in the DoD TRICARE system are stored in the Clinical Data
1899   Repository (CDR), a component of the Armed Forces Health Longitudinal Technology Application (AHLTA). Similarly,
1900   the VA Health Data Repository (HDR) provides a centralized storage for medical records entered and maintained in
1901   the Veterans Health Information System and Technology Architecture (VistA) and Computerized Patient Record
1902   System (CPRS). The CHDR system is the link between these two systems.
1903
1904   CHDR works in the background to deliver improved information sharing between the DoD and VA of medical records
1905   for Active Dual Consumers (ADC) patients. The interoperability provides clinical users at DoD and VA medical
1906   facilities with bidirectional, real-time exchange of medical records that will include at a minimum, the exchange of
1907   outpatient pharmacy and drug allergies (limited only to drug allergies) to enable drug/drug and drug/allergy order
1908   checks. The integrated clinical data between the DoD and the VA (outpatient pharmacy and drug allergy data) can be
1909   viewed in VistAWeb or CPRS Remote Data Views (RDV).
1910
1911   CHDR facilitates the sharing of a Virtual Lifetime Electronic Record (VLER) between DoD and the VA for our nations
1912   Veterans. This enables the VA/VHA to provide a comprehensive integrated medical record that is compliant with the
1913   Health Insurance Portability and Accountability Act (HIPAA) and other privacy regulations, and to facilitate a
1914   seamless transition from military to Veteran status.




1915
1916                                                      Figure: 3.1-15
1917




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-6
1918   3.1.11 CPRS-Computerized Patient Record System
1919   The Computerized Patient Record System (CPRS) v. 1.0 is a Veterans Health Information Systems and Technology
1920   Architecture (VISTA) software application. CPRS enables clinicians, nurses, clerks, and others to enter, review, and
1921   continuously update all information connected with any patient.
1922
1923   [Highest revision in VA Software Document Library (vld) is OR*3.0*309. (2011_08_06)]
1924
1925   Developing a computerized patient record is a long-term goal of the Veterans Health Administration (VHA) as part of
1926   its mission to provide high quality healthcare for America’s veterans. New information needs are emerging as VHA
1927   continues to shift into a primary care, ambulatory healthcare delivery model. In the new clinical information
1928   environment, all information relevant to treating any given patient will be readily available to healthcare providers,
1929   clinical and management decision-makers, educators, and researchers through a secure platform on a need-to-know
1930   basis.
1931
1932   With CPRS, care providers can quickly flip through electronic “pages” of the chart to add new orders, review or add
1933   problems, write progress notes, or see results. Alerts, notifications, cautions, warnings, advanced directives, future
1934   appointments, demographic data, medications, and orders are all available. Order entry now includes quick orders,
1935   order sets, and order checking.
1936
1937   FAQ
1938   Q. What is the relationship between OE/RR and CPRS? I sometimes hear references to OE/RR 3.0 and much of the
1939   CPRS package just seems to be an enhanced OE/RR 2.5.
1940   A. This distinction does get fuzzy at times. CPRS is the umbrella package for a much more comprehensive suite of
1941   software. OE/RR 3.0 is a component of CPRS, and can’t be used outside of CPRS. Many of the packages contained
1942   within CPRS still have independent lives, for use by their services for administrative and other purposes, and
1943   occasionally to add and review orders (known as “backdoor” ordering). The CPRS documentation set mainly
1944   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-7
www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-7
1946                                                     Figure: 3.1-16
1947   Documents available in the vdl:
1948   (http://www.va.gov/vdl/application.asp?appid=61)
1949   Name Date Created          Last Updated
1950       CPRS Clinician's Getting Started Guide List Manager Version     2005-03-01      2005-03-15
1951       CPRS GUI 24: Set Up Notes for Non-VA Medications        2004-07-01      2004-12-30
1952       CPRS GUI Version 27 (Patch OR*3.0*243) and Associated Patches Installation Guide        2008-08-20
1953             2008-09-17
1954       CPRS GUI Version 28 (Patch# OR*3*280) and Associated Patches Installation Guide 2011-03-07      2011-
1955        03-21
1956       CPRS Patch OR*3.0*296 (CPRS GUI v.27.90) and Associated Patches Installation Guide      2009-08-27
1957             2009-09-10
1958       CPRS Query Installation/Implementation Guide 2003-04-28         2003-04-28
1959       CPRS Query User Manual          2003-04-28      2004-12-30
1960       CPRS Read-Only User Guide 2002-07-01            2004-12-30
1961       CPRS Release Notes: GUI Version OR*3.0*190 (v.24)       2004-07-01      2004-12-30
1962       CPRS Release Notes: GUI Version OR*3.0*195 (v.25)       2005-01-01      2005-01-31
1963       CPRS Release Notes: GUI Version OR*3.0*215 (v.26)       2006-05-01      2006-05-01
1964       CPRS Release Notes: GUI Version OR*3.0*243 (v.27)       2008-08-20      2009-02-05
1965       CPRS Release Notes: GUI Version OR*3.0*280 (v.28)       2011-03-07      2011-03-07
1966       CPRS Release Notes: GUI Version OR*3.0*296 (v.27.90) 2009-08-27         2009-08-27
1967       CPRS Release Notes: GUI Version Patch OR*3.0*231        2005-04-01      2005-04-26
1968       CPRS Release Notes: GUI Version Patch OR*3.0*235        2005-06-01      2005-06-20
1969       CPRS Release Notes: GUI Version Patch OR*3.0*252        2007-05-02      2007-05-02
1970       CPRS Release Notes: GUI Version Patch OR*3.0*258        2006-06-01      2006-06-08
1971       CPRS Release Notes: GUI Version Patch OR*3.0*270        2007-01-23      2007-01-23
1972       CPRS Release Notes: GUI Version Patch OR*3.0*277        2007-10-31      2007-10-31
1973       CPRS Release Notes: GUI Version Patch OR*3.0*304        2008-11-20      2008-11-20
1974       CPRS Technical Manual           2006-05-01      2011-04-20
1975       CPRS Technical Manual: GUI Version 2006-05-01           2011-03-07
1976       CPRS User Guide: GUI Version            2006-05-01      2011-04-20
1977       CPRS-VBECS Interface (OR*3.0*212) Release Notes         2009-06-08      2009-06-08
1978       CPRS-VBECS Interface Follow-Up Fixes (OR*3.0*309) Release Notes         2010-03-26      2010-03-26
1979       Installation Guide    1999-07-01        2007-05-02
1980       OR*3.0*294 Installation Guide 2011-03-03        2011-03-03
1981       Remote Data Interoperability (OR*3.0*232) Release Notes 2007-04-13      2007-04-13
1982       Setup Guide 2000-08-01          2011-04-20
1983
1984   3.1.12 CPRS: ART-Adverse Reaction Tracking
1985   The objective of the Adverse Reaction Tracking (ART) package, is to collect, track, and report patient allergy and
1986   adverse reaction data. This is accomplished via the four major functional areas of the package.
1987
1988   1. Data Entry options - ART has two options where a user can enter data.




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap           Page 3-7
1989   a. Enter/Edit Patient Reaction Data - This option allows the clinical users (i.e., doctors, nurses, other clinicians and
1990   clerks) to enter data.
1991   b. Verify Patient Reaction Data - This option allows the designated verifiers (e.g., clinical pharmacists) to verify the
1992   correctness of data entered by the clinical users. This option does NOT perform evaluation of suspected Adverse
1993   Drug Reactions (ADRs) as described in Section 5.a.(2).(d) of Directive 10-92-070.
1994
1995   2. Reporting options - These options report the patient causative agent data to the user via a print option. Also, this
1996   data is made available to other software applications via a data extract utility.
1997   3. Enter/Edit Site File Configurable Menu - This menu allows the various site configurable files to be modified to allow
1998   ART to better meet the needs of each individual site.
1999
2000   4. Adverse Drug Reaction (ADR) options - These options support implementation of Directive 10-92-070. They allow
2001   for the evaluation of a suspected ADR by a qualified individual (e.g., clinical pharmacist, clinical pharmacologist)
2002   other than the attending physician, as specified in Section 5.a.(2).(d) of Directive 10-92-070. This component also
2003   generates the reports needed by the Food and Drug Administration (FDA).




2004
2005                                                       Figure: 3.1-17
2006
2007   3.1.13 CPRS: ASU-Authorization Subscription Utility
2008   The Authorization/Subscription Utility (ASU) implements a User Class Hierarchy which is useful for identifying the
2009   roles that different users fulfill within the hospital. It also provides tools for creating business rules that apply to
2010   documents used by members of such groups. ASU provides a method for identifying who is AUTHORIZED to do
2011   something (for example, sign and order). ASU originated in response to the long recognized demand for a means of
2012   implementing the “Scope of Practice” model, which was first discussed during the analysis and design of OE/RR
2013   v1.96, but the driving force behind its development was the complexity of Text Integration Utilities’ (TIU’s) document
2014   definition needs. Current security key capabilities were unable to efficiently manage the needs of clinical
2015   documentation (Discharge Summaries, Progress Notes, etc.).
2016



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-7
2017   ASU Features & Benefits
2018   • ASU lets you define, populate, and retrieve information about User Classes. These User Classes can be defined
2019      hospital-wide or more narrowly for a specific service and can be used across VISTA to replace and/or
2020      complement keys.
2021   • ASU lets you link user classes with Document Definitions and document events. This part of ASU defines
2022      behavior TIU documents only.
2023   • The User Class Membership file is a relational file which allows a many-to-many relationship to be defined
2024      between User Classes and their members (as defined in the New Person File (#200)).
2025   • Membership in classes may be scheduled for automatic transition to other classes (e.g., the PGY1 Residents will
2026      rotate on June 30th, and will become PGY2 Residents as of July 1st).
2027   • The Authorization/Subscription file (#8930.1) is another relational table, linking actions or events (e.g., Signature)
2028      with Document Definitions (e.g., Clinical Warning Note), record statuses, user classes (e.g., Provider) and user
2029      roles (e.g., Author, Expected Signer, Expected Cosigner, etc.). In this manner, a “Knowledge Base” or table of
2030      “Production Rules” can be developed in compliance with the site’s local by-laws (or in some cases, national
2031      requirements) for handling of various elements of the medical record. This eliminates the need for “hard-coding”
2032      business rules within the application, thereby enforcing policies, independent of the local facility’s preferences.
2033      These rules are also “inherited” through both the User Class and Document Definition hierarchies.
2034   • ASU imposes no limitation on the depth or specificity of the User Class hierarchy which a site may choose to
2035      develop.
2036   • Other applications within VistA may access the User Class file to determine the role of an employee.




2037
2038                                                       Figure: 3.1-18
2039
2040   3.1.14 CPRS: Clinical Reminders
2041   Namespace PXRM
2042
2043   The Clinical Reminder system helps caregivers deliver higher quality care to patients for both preventive health care
2044   and management of chronic conditions, and helps ensure that timely clinical interventions are initiated.
2045




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-7
2046   Reminders assist clinical decision-making and also improve documentation and follow-up, by allowing providers to
2047   easily view when certain tests or evaluations were performed and to track and document when care has been
2048   delivered. They can direct providers to perform certain tests or other evaluations that will enhance the quality of care
2049   for specific conditions. The clinicians can then respond to the reminders by placing relevant orders or recording
2050   clinical activities on patients’ progress notes.
2051
2052   Clinical Reminders may be used for both clinical and administrative purposes. However, the primary goal is to
2053   provide relevant information to providers at the point of care, for improving care for veterans. The package benefits
2054   clinicians by providing pertinent data for clinical decision-making, reducing duplicate documenting activities, assisting
2055   in targeting patients with particular diagnoses and procedures or site-defined criteria, and assisting in compliance
2056   with VHA performance measures and with Health Promotion and Disease Prevention guidelines.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-7
2057
2058                    Figure: 3.1-19
2059
2060




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-7
2061   3.1.15 CPRS: Consult/ Request Tracking
2062   Consult/Request Tracking package V. 3.0 improves the quality of patient care by:
2063    Interfacing with CPRS to provide an efficient mechanism for clinicians to order consults and procedure requests.
2064    Providing consulting services with the ability to update and track the progress of a consult/procedure request
2065        from the point of receipt through its final resolution.
2066    Providing results reporting that includes doctor's notes and comments entered during the tracking process.
2067




2068
2069                                                      Figure: 3.1-20
2070
2071   3.1.16 CPRS: Health Summary
2072   A Health Summary is a clinically oriented, structured report that extracts many kinds of data from VISTA and displays
2073   it in a standard format. The individual patient is the focus of health summaries. Health summaries can also be printed
2074   or displayed for groups of patients. The data displayed covers a wide range of health-related information such as
2075   demographic data, allergies, current active medical problems, and laboratory results.
2076
2077   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-7
2078
2079                    Figure: 3.1-21
2080




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-7
2081   CPRS: Health Summary - (Component diagram)
                      cmp CPRS: Health Summary




                                                                  Health Summary



                             DHCP Ancillary        Reminder             Surgery Report   Next of Kin
                                                  Maintenance              (OR/NON)




                             Reminder Brief        NON OR               Reminders Due    Vital Signs
                                                  Procedures                             Outpatient




                               Reminders            Selected            Global Assess    Spinal Cord
                                Summary          Progress Notes            Function      Dysfunction




                             Detailed Vitals      MAG Imaging           Vital Select     Select Image
                                                                         Outpatient       Impression




2082
2083                                                              Figure: 3.1-22
2084
2085   3.1.17 Electronic Wait List
2086   In the outpatient setting, patients are assigned a primary care team and provider who are responsible for delivering
2087   essential health care, coordinating all health care services, and serving as the point of access for specialty care. This
2088   is accomplished through the Primary Care Management Module (PCMM) of the Veterans Health Information
2089   Systems and Technology Architecture (VistA). When a patient cannot be assigned to a primary care team or position,
2090   the PCMM software asks if the patient should be placed on the Electronic Wait List. PCMM Wait List reports assist in
2091   the management of patients awaiting a primary care team or provider assignment.
2092   The purpose of EWL is to provide quicker or more convenient patient care by providing care by another team or
2093   location for the patient’s benefit. The EWL can be accessed through the PCMM GUI or by a Stand alone Roll and
2094   Scroll application from the VistA Scheduling Appointment menu, as well as from the Scheduling Appointment
2095   Management Menu. The EWL standalone menu is accessible to users with the SDWL MENU security key.
2096
2097   The goal of the EWL is to provide care to the patient as quickly as possible. To facilitate this goal, patients may be
2098   placed on a Wait List for a different team or even at a different facility. The EWL keeps track of appointments, clinics,
2099   and providers associated with patients on the various Electronic Wait Lists. Patient eligibility information and service
2100   connected status is also recorded and updated. The EWL runs a background job to determine patient changes in the
2101   veteran’s service connected percentage, service connected priority as well as changes to appointment, clinics, and
2102   personnel that affect Wait List patients. EWL also sends messages to assigned mail groups to notify of such
2103   changes.
2104   The Electronic Wait List can also produce reports on demand regarding EWL related activities.
2105
2106   This patch is a part of the Electronic Wait List enhancements as identified through a list of requirements that the EWL
2107   User Group has validated and prioritized. Management of the EWL disposition process and its close relation to
2108   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-7
2109   existing EWL package in its current state. The Electronic Wait List sub-system shall be included in the Scheduling
2110   Re-hosting project that is in testing right now and the EWL features introduced in this patch are expected to be
2111   implemented in this Scheduling Re-hosting project as well.
2112   The main purpose of this project is to speed up the disposition process of open EWL entries if a related appointment
2113   is scheduled and to alert the new EWL Mail Group: SD EWL BACKGROUND UPDATE, about the need for editing an
2114   EWL entry in response to a change in the status of its EWL type.
2115   A user manual specific to just patch SD*5.3*327 has been created and is located at
2116   http://www.va.gov/vdl/VistA_Lib/Clinical/Electronic_Wait_List/SD_53_P327_um.pdf.
2117   NOTE: The general online User Manual of Electronic Wait List for Scheduling and Primary Care Management
2118   Module (PCMM) is available at
2119   http://www.va.gov/vdl/VistA_Lib/Clinical/Electronic_Wait_List/SD_53_P263_um.pdf.
2120
2121   Product Feature Summary - SD*5.3*327 will introduce the following enhancements:
2122   • User interface to select open EWL entries by clinic, by specialty or all
2123   • Ability to disposition a selected EWL entry and to update with data of the related appointment
2124   • Optional selection of open EWL entries for marking with a non-removal reason
2125   • Display of selected EWL entries with the Reopen Reason, appointment information, and the related comments if
2126       applicable.
2127   • The new EWL background job to include:
2128           o Identification of ‘canceled’ appointments used previously for disposition of the related EWL entries, and
2129                automatic change of the related EWL entry status to ‘open’.
2130           o Identification of the Date of Death change and update of the related EWL entry status accordingly.
2131           o Identification of ‘inactivated’ clinics, teams, and positions used in open EWL entries with follow up
2132                notification sent to the EWL Mail Group.
2133           o Generation of appropriate messages (listed above) sent by Mail Man to the designated EWL Mail
2134                Group: SD EWL BACKGROUND UPDATE.
2135   • Design of a new report with EWL entries sorted by Reopen Reason.
2136   • Ability to prompt for a new entry to the EWL if no appointment could have been selected from Action:
2137       Unscheduled Visit under Appointment Management.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-8
2138
2139                    Figure: 3.1-23
2140
2141




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-8
2142   3.1.18 CPRS: Problem List
2143   The Problem List program is used to document and track a patient’s problems. It provides clinicians with a current
2144   and historical view of a patient’s health care problems, and allows each identified problem to be traced through the
2145   DHCP system in terms of treatment, test results, and outcome.
2146
2147   Version 2 supports primary care providers in both inpatient and Ambulatory Care settings, including physicians,
2148   nurses, social workers, psychologists, and others. It also is designed to be used by PIMS clinic and ward clerks and
2149   by PIMS coding clerks. Many data entry methods are possible with this program.
2150
2151   Features in Problem List
2152   • Allows one problem list for a given patient.
2153   • Tied to a coding system.
2154   • Requires minimal data entry.
2155   • Linked to other sections of the medical record, such as CPRS and Health Summary.
2156   • Supports import of problem information from other clinical settings outside the immediate VAMC.
2157   • Uses a common language of terminology, the Lexicon Utility. Each term is well-defined and understandable. A
2158       user, site, or application may substitute a preferred synonym.
2159   • Allows reformulation of a problem.
2160   • Can be interfaced with a customized encounter form.




2161
2162                                                      Figure: 3.1-24
2163
2164   3.1.19 CPRS: TIU-Text Integration Utility
2165   Namespace TIU



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-8
2166
2167   The purpose of Text Integration Utilities (TIU) is to simplify the access and use of clinical documents for both clinical
2168   and administrative VAMC personnel, by standardizing the way clinical documents are managed. In connection with
2169   Authorization/ Subscription Utility (ASU), a hospital can set up policies and practices for determining who is
2170   responsible or has the privilege for performing various actions on required VHA documents.
2171
2172   The initial release of Version 1.0 includes Discharge Summary and Progress Notes. Consult Reports was added with
2173   the release of Computerized Patient Record System (CPRS). TIU replaces and upgrades the previous versions of
2174   these VISTA packages. It has also been designed to meet the needs of other clinical applications that address
2175   document handling.
2176
2177   TIU lets you continue to access Progress Notes and Discharge Summaries from OE/RR menus. The CPRS
2178   Graphical User Interface (GUI) allows point-and-click access to all Progress Notes, Discharge Summaries, and
2179   Consults TIU documents.
2180
2181   [Highest revision in VA Software Document Library (vld) is Patch TIU*1*250. (2011_08_06)]




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-8
2182
2183                                                     Figure: 3.1-25
2184
2185   3.1.20 Dentistry
2186   Dental Record Manager (DRM) Plus
2187
2188   In 1997, Document Storage Systems, Inc., in conjunction with the VA, developed a dental software package titled the
2189   Dental Record Manager (DRM). The Dental Record Manager is a nationally purchased software product and is
2190   installed in all VA dental clinics. Future plans for DRM included the computerization of the patient’s Diagnostic
2191   Findings, Completed Care Treatment Plan and Periodontal Chart. The planning for these enhancements has been a
2192   joint VA/DSS effort. DRM Plus is a combination of DRM and these major enhancements. Document
2193   Storage Systems and Discus Dental Software worked together to develop DRM Plus. In September, 2003, the VA
2194   purchased a national license for DRM Plus. DRM Plus was fully implemented by September 30, 2005.
2195


       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-8
2196   The DRM Plus program is designed to provide dental health care facilities with an intuitive, user friendly Windows
2197   interface for end-users to create encounter information assess patient dental conditions, and develop and maintain
2198   the Treatment Plan. The DRM Plus program is an application that uses “RPC Broker” technology that permits the
2199   facility users to store and retrieve clinical data within the VistA System.
2200
2201   Implementation of DRM Plus results in more accurate insurance billing for dental visits, consults and procedures.
2202   This application also supports the transfer from Dental Amis System (DAS) to Dental Encounter System (DES) filing
2203   within the guidelines established by the Veterans Health Administration, Office of Dentistry.
2204
2205   DRM Plus introduces two new areas for recording and charting patient information – Treatment & Exam and
2206   Periodontal Chart. The patient’s Diagnostic Findings, Treatment Plan and Completed Care can be recorded and
2207   maintained within the Treatment & Exam screen. The patient’s periodontal conditions can be recorded and
2208   maintained within the Periodontal Chart screen.




2209
2210                                                     Figure: 3.1-26
2211
2212   3.1.21 EDIS-Emergency Department Integration Software
2213   Emergency Department Integration Software (EDIS) incorporates several Web-based views that extend the current
2214   Computerized Patient Record System (CPRS) to help healthcare professionals track and manage the flow of patient
2215   care in the emergency-department setting. EDIS views are based on a class-three application developed by the
2216   Upstate New York Veterans Health Care Network—or Veterans Integrated Services Network (VISN) Most views are
2217   site configurable. EDIS enables you to:
2218   • Add emergency-department patients to the application’s display board
2219   • View information about patients on the display board
2220   • Edit patient information
2221   • Remove patients from the display board
2222   • Create administrative reports
2223
2224   EDIS runs as a Web application on a centrally-located BEA WebLogic server that contains program logic and
2225   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-8
2226   The data tier encompasses local sites’ Veterans Health Information Systems and Technology Architecture (VistA)
2227   systems and a centrally located relational database management system (RDMS) data store containing Standard
2228   Data Services (SDS) tables.
2229
2230   The application uses remote procedure calls (RPCs) from local VistA implementations to populate patient- and
2231   provider-selection lists, provide limited data synchronization between EDIS and CPRS, and determine users’ access
2232   levels.




2233
2234                                                      Figure: 3.1-27
2235
2236   3.1.22 FIM-Functional Independence Measurement
2237   The Functional Independence Measures (FIM) Version 1.0 provides an integration of FIM assessments into the
2238   Computerized Patient Record System (CPRS) and into the Functional Status and Outcomes Database (FSOD) at the
2239   Austin Automation Center (AAC). The FIM is an 18-item, 7-level functional assessment designed to evaluate the
2240   amount of assistance required by a person with a disability to perform basic life activities safely and effectively.
2241
2242   There are five types of FIM assessments: admission, goals, interim, discharge, and follow-up.
2243
2244   The FIM assessments are used clinically to monitor the outcomes of rehabilitative care as required by the Joint
2245   Commission on the Accreditation of Health Care Organizations (JCAHO) and the Commission on the Accreditation of
2246   Rehabilitative Facilities (CARF). According to VHA Directive 2000-16, medical centers are mandated to measure and
2247   track rehabilitation outcomes on all new stroke, lower-extremity amputees, and traumatic brain injury (TBI) patients
2248   using the FIM.
2249
2250   Finally, the Performance Measurement Workgroup of the Department of Veterans Affairs Central Office (VACO)
2251   approved a Network Director Performance Measure for rehabilitation for FY03 that requires the collection of FIM
2252   data. FIM Version 1.0 should greatly ease the burden placed on rehabilitation professionals in the field who are
2253   working to comply with the new performance measure.
2254
2255   FIM provides a Graphic User Interface (GUI) front-end programmed in Delphi to allow multiple clinicians to input FIM
2256   data for a given patient. This documentation then becomes available in CPRS as a progress note with addendums



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-8
2257   and/or a completed consults. The GUI front-end gathers demographic data as well as other required data by FSOD
2258   from VistA, therefore, eliminating the need for the clinician search of VistA for the information and re-enter for FIM.
2259
2260   FIM data is then placed in a VistA FileMan file for Health Level Seven (HL7) transmission to the FSOD at ACC.




2261
2262                                                       Figure: 3.1-28
2263




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-8
2264
2265
2266
2267
2268   FIM-Functional Independence Measurement - (Component diagram)
            cmp FIM-Functional Independence Measurement

              Name:        FIM-Functional Independence Measurement
              Package:     FIM-Functional Independence Measurement
              Version:     1.0
              Author:      Karen Kirkpatrick




                             FIM-Functional Independent Measures




                                                           «interface»
                                                         FIM-Functional
                                    HL7                   Independent     Austin Automation Center (AAC
                                                        Measures::Austin
                                                        Automation Center




2269
2270                                                       Figure: 3.1-29
2271
2272   3.1.23 Group Notes
2273   This program was designed to assist providers in documenting group therapy sessions and events such as
2274   immunization clinics. It allows the easy assembly of patient groups based on Clinics, Specialties, Wards, Teams, or
2275   Provider lists. It then allows the note author to specify parts of a note that apply to the entire group and parts that
2276   apply to individuals. It does the same with encounter data. After the note and encounter information is complete, it
2277   provides for a single signature for the entire group.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-8
2278
2279                                                       Figure: 3.1-30
2280
2281   3.1.24 HDR-Hx - HDR-Historical
2282   Centralized Data Repositories::Health Data Repository (HDR)
2283   Package HDR Historical (HDR Hx)
2284   HDR Historical (HDR Hx)
2285
2286   ** Please note, this information was gathered via documentation found in the Office of Enterprise Development
2287   (OED) Project Repository, the VistA Monograph, and the HDR Hx Homepage. As the Analysts Office did not receive
2288   feedback from the HDR Historical points of contact, this information has not been verified.
2289
2290   Description: HDR Historical (HDR Hx) stores all clinical data from VistA not contained in HDR IMS and not identified
2291   for inclusion in HDR II. It provides historical clinical data in a computable and/or viewable access form to user
2292   interfaces such as RDI, CHDR and VistAWeb to support patient care.
2293
2294   HDR Hx extracts and stores legacy data from 128 VistA systems to a relational database in the Austin Information
2295   Technology Center (AITC). The data is viewable from the HDR Hx database via Remote Data Views (RDV) in CPRS.
2296   HDR Hx allows sites to archive and purge selected data in local databases. The historical data provided by HDR Hx
2297   is combined with other HDR data for use across the organization to facilitate patient care, clinical decision support,
2298   and research activities.
2299
2300   Programming Language:
2301     Research pending
2302
2303   Deployment Infrastructure:
2304     Oracle 11g
2305     Unix
2306
2307   Depends On:
2308     VistA 1.0
2309       Computerized Patient Record System (CPRS)
2310       Pharmacy: Outpatient Pharmacy (Remote Data Interoperability (RDI) v. 1.0)




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-8
2311     Department of Defense (DoD) Information Sharing
2312       Clinical Data Repository/Health Data Repository (CHDR)
2313     Master Patient Index (MPI)
2314
2315   The following entities depend on HDR Historical (HDR Hx):
2316     VistA 1.0
2317        VistAWeb
2318     Centralized Data Repositories
2319        HDR Clinical Data Services (CDS) v. 1.0
2320        HDR National (HDR II)
2321     Corporate Data Warehouse (CDW)
2322     Department of Defense (DoD) Information Sharing
2323        Clinical Data Repository/Health Data Repository (CHDR)
2324
2325   For more information, reference:
2326      VA Software Document Library (VDL): N/A
2327      VA Office of Enterprise Development (OED) Project Repository:
2328         HDR Historical Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=909
2329      VistA Monograph (2009): http://www4.va.gov/vista_monograph/
2330      Health Data Repository Hx Homepage: http://vaww.vista.med.va.gov/hdr/HDR_Hx_Documents.html
2331      Remote Data Interoperability (RDI) Training Homepage: http://vaww.vistau.med.va.gov/VistaU/rdi/default.htm
2332      Health Data Repository PowerPoint Presentation:
2333   http://vaww.vista.med.va.gov/hdr/HDR_Presentation_010605.pdf




2334
2335                                                     Figure: 3.1-31



       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap      Page 3-9
2336
2337   3.1.25 HBPC-Home Based Primary Care
2338   The Home Based Primary Care (HBPC) package formally known as Hospital Based Home Care (HBHC) is a VISTA
2339   application developed for use by the HBPC Programs at the medical centers. The software:
2340   • Allows the entry and storage of information on all Evaluations/Admissions,
2341   • Scans Outpatient Encounters for all HBPC visits and stores the visit data,
2342   • Allows the entry and storage of HBPC Discharge information,
2343   • Provides reports covering all aspects of the data,
2344   • Informs the staff when incomplete records for transmission are found,
2345   • Transmits the data to Austin using MailMan.




2346
2347                                                Figure: 3.1-32
2348




       www.oserha.org                              OSEHR System-Architecture, Product Definition and Roadmap     Page 3-9
2349   HBPC-Home Based Primary Care - (Component diagram)
            cmp HBPC-Home Based Primary Care

              Name:      HBPC-Home Based Primary Care
              Package:   HBPC-Home Based Primary Care
              Version:   1.0
              Author:    Karen Kirkpatrick




                          HBPC-Home Based Primary Care




                                                «interface»
                             HL7            HBPC-Home Based
                                           Primary Care::Austin    Austin Automation Center (AAC)
                                            Automation Center
                                                   (AAC)




2350
2351                                              Figure: 3.1-33
2352




       www.oserha.org                            OSEHR System-Architecture, Product Definition and Roadmap   Page 3-9
2353   Home Telehealth - (Component diagram)
                 cmp Home Telehealth

                   Name:        Home Telehealth
                   Package:     Home Telehealth
                   Version:     1.0
                   Author:      Karen Kirkpatrick




                                    Home Telehealth




                                                   «interface»
                             HL7                Home Telehealth::
                                                Austin Automation          Austin Automation Center (AAC)
                                                  Center (AAC)




2354
2355                                                      Figure: 3.1-34
2356
2357   3.1.26 Home Telehealth
2358   The goal of the Home Telehealth IT program is to integrate vendor supported Home Telehealth services into the
2359   VistA medical information infrastructure. The Home Telehealth program builds on the excellent existing and evolving
2360   VistA system. This phase of the Home Telehealth project moves us towards an integrated environment through the
2361   following process:
2362   • The patient screening process starts with a VistA Consult.
2363   • The Consult is completed through the standard VistA Progress Note.
2364   • Patient sign-up is done through a VistA Patient Information Management System (PIMS) interface.
2365
2366   The care coordinator selects the patient name, the supporting vendor, the consult type, the care coordinator’s name,
2367   and then submits the request. VistA extracts all the pertinent patient data and sends a Health Level Seven (HL7)
2368   Sign-Up message to the vendor server.
2369   • The care coordinator then uses the vendor software to associate the home device with the patient record on the
2370       vendor system.
2371   • Measurement data gathered by devices in the veteran’s home are stored in the vendor server and available for
2372       review, and are sent to the VA’s Health Data Repository (HDR) using HL7 messages sent through the VistA
2373       Interface Engine (VIE) Infrastructure.



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-9
2374   •   The Home Telehealth data in the HDR along with VistA data from facility VistA systems is viewed using
2375       VistAWeb, which is available through the Computerized Patient Records System (CPRS) by using the Remote
2376       Data View (RDV) function.
2377   •   Monthly, vendor servers send HL7 messages to the Sign-Up VistA facility for the Care Coordinator to review
2378       draft progress notes summarizing patient activity from the previous month.
2379
2380   This functionality involves components on the vendor servers as well as several VistA packages including Consults,
2381   PIMS for sign up, Progress Notes, TIU, VIE, Master Patient Index (MPI), HDR, Clinical Data Services (CDS), Clinical
2382   Context Object Workgroup (CCOW) for patient context, VistAWeb, and CPRS.




2383
2384                                                     Figure: 3.1-35
2385
2386   3.1.27 ICR-Immunology Case Registry
2387   Immunology Case Registry (ICR) version 2.1 was removed from service by patch IMR*2.1*21 in October 2005.
2388   ICR and the Hepatitis C Case Registry are now supported by the Clinical Case Registries (CCR) package. CCR
2389   version 1.5 was released in February 2006.
2390
2391   For documentation on the latest version of CCR, please see the Clinical Case Registries page on the VA Software
2392   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-9
2393                                                                                                   Figure: 3.1-36
2394
2395   3.1.28 IRT-Incomplete Records Tracking
2396   The Incomplete Records Tracking (IRT) software is formerly a component of PIMS V. 5.3. With PIMS V. 5.3, it
2397   includes many enhancements that should allow the users greater flexibility and efficiency when tracking incomplete
2398   records.
2399
2400   The package now tracks all types of deficiencies, in addition to those already being tracked (Discharge and Interim
2401   Summaries and OP Reports). The sites will have the ability to add the deficiencies they wish to track to make this
2402   package more site specific.
2403
2404   The Physician for Deficiency will be tracked throughout the IRT process. The users will know who is responsible for
2405   the deficiency at various stages of tracking, from entry through completion.




2406
2407                                                     Figure: 3.1-37
2408




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-9
2409   3.1.29 Intake and Output
2410   The Intake and Output (I&O) application is designed to store, in the patient's electronic medical record, all patient
2411   intake and output information associated with a hospital stay or outpatient visit. This application is not service specific
2412   and currently is interfaced with the PIMS, Nursing, and Pharmacy applications.
2413
2414   Functionality:
2415   • Users may electronically document patient intake (e.g., oral fluids, tube feedings, intravenous fluids, irrigations,
2416        and other types of intake defined by the facility) and patient output (e.g., excreted patient material such as urine,
2417        nasogastric secretions, emesis, drainage, liquid feces/stool, and other types of output defined by the facility).
2418   • Intake data can be entered through either a quick or detailed route. The quick route documents the total fluid
2419        consumed. Detailed information requests the user to enter specific type of fluid intake (e.g., orange juice, water,
2420        soup) along with the quantity absorbed.
2421   • The Start/Add/DC IV and Maintenance option contains nine protocols associated with intravenous therapy:
2422            1. Start IV - Start a new IV line or heparin/saline lock/port.
2423            2. Solution: Replace/DC/Convert/Finish Solution - DC current solution then replace a new solution to the
2424                  selected IV line or convert the IV according to the user's choice.
2425            3. Replace Same Solution - Replace the same solution to a selected IV.
2426            4. D/C IV Lock/Port and Site - Remove IV/lock/port from a selected IV site.
2427            5. Care/Maintenance/Flush - Check site condition, dressing change, tube change and flush.
2428            6. Add Additional Solutions(s) - Add additional solution(s) without discontinuing an existing one.
2429            7. Restart DC'd IV - Restart an IV which was DC'd due to infiltration or other reasons.
2430            8. Adjust Infusion Rate - Adjust infusion rate for a selected IV.
2431            9. Flush - Flush all IV line(s) for a selected infusion site.
2432   • The software supports documentation of intravenous intake via both single and multi-lumen catheters.
2433   • The software is interfaced with the IV module of the Pharmacy software.
2434   • The following reports are included:
2435            o Print I/O Summary by Patient (by Shift and Day(s))
2436            o Print I/O Summary (Midnight to Present)
2437            o Print I/O Summary (48 Hrs)
2438            o 24 Hours Itemized Shift Report
2439            o Intravenous Infusion Flow Sheet
2440   The last four reports can be printed for all patients on a ward, for patients in selected rooms on a ward, and for an
2441   individual patient.
2442   • Patient Intake and Output information is printed on the following Nursing application reports:
2443            o End of Shift Report
2444            o Vital Signs Record
2445
2446   This version of Intake and Output is not interfaced with the Health Summary or the Order Entry/Results Reporting
2447   applications.




       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                Page 3-9
2448
2449                                                         Figure: 3.1-38
2450
2451   Intake and Output - (Component diagram)
                                     cmp Intake and Output

                                                              Nursing
                                       Pharmacy:
                                       Inpatient Med -                         Vitals/ Measurements
                                       IV


                                                                «interface»
                                                             Intake & Output




2452
2453                                                         Figure: 3.1-39
2454
2455   3.1.30 Laboratory
2456   The Laboratory module is part of the integrated VistA software, which automates the manual procedures used in the
2457   following laboratory areas:
2458   1. Ordering of tests and procedures on both patient and non-patient specimens
2459   2. Collection and Accessioning of specimens into the Laboratory database
2460   3. Processing and analysis in appropriate department or work areas
2461   4. Review and verification of results
2462   5. Reporting of results and/or diagnoses for clinical health care treatment
2463   6. Analysis and reporting of quality control data used in generating results
2464   7. Providing management statistical data as well as requirements for accreditation by
2465   regulating bodies and agencies.




       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap     Page 3-9
2466
2467                                                      Figure: 3.1-40
2468
2469   3.1.31 Laboratory: Anatomic Pathology
2470   Anatomic Pathology (AP) is divided into four sections: Surgical Pathology, Cytology (Cytopathology), Electron
2471   Microscopy, and Autopsy Pathology.
2472
2473   The processes of accessioning, data entry, coding, and editing are similar for each of these sections. The computer
2474   program lets you select one of these processes (menus or options) and then the section. That is, if you wish to log in
2475   a specimen for Cytology, you first select the “Log-in Menu,” and then you’ll be prompted to choose the Anatomic
2476   Pathology section.
2477
2478   The search options are based on SNOMED and ICD9CM coding.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-9
2479
2480                                                         Figure: 3.1-41
2481
2482   Laboratory: Anatomic Pathology - (Component diagram)
2483
2484
                              cmp Laboratory: Anatomic Pathology



                                     Laboratory:
                                  Anatomic Pathology


                                       «interface»
                                       Laboratory:
                                        Anatomic
                                                                   DHCP - Decentralized Hospital Computer Program
                                        Pathology




2485
2486                                                         Figure: 3.1-42
2487
2488




       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap   Page 3-9
2489   3.1.32 Laboratory: Blood Bank
2490   The national release of patch LR*5.2*408 on July 18, 2011 finalizes the VHA transition from the VistA Version 5.2
2491   Blood Bank package to the VistA Blood Establishment Computer Software (VBECS) system. Sites with VBECS have
2492   already disabled the VistA v5.2 Blood Bank package when database conversion was executed. With the installation
2493   of this patch the Enter/Edit options for VistA v5.2 Blood Bank are permanently disabled.
2494
2495   Patch releases for VBECS communications with VistA packages will continue as LR*5.2 and VBEC namespace
2496   releases. All customer documentation for these VBECS associated releases are posted to the VistA Document
2497   Library (VDL), Laboratory: VistA Blood Establishment Computer Software (VBECS).
2498
2499   Because Blood Bank legacy records are available as read-only, VistA v5.2 continues to be maintained by OIT as a
2500   Food and Drug Administration cleared medical device (FDA number BK970021). Adulteration of this package at VHA
2501   facilities is prohibited and will be monitored by the product development team.




2502
2503                                                    Figure: 3.1-43
2504
2505   3.1.33 Laboratory: Blood Bank Workarounds
2506   Description not readily available.




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap          Page 3-1
2507
2508                                                       Figure: 3.1-44
2509
2510   3.1.34 LEDI-Laboratory: Electronic Data Interchange
2511   The Veteran Integrated Service Network (VISN) mission is to consolidate electronic lab test ordering and lab test
2512   result reporting throughout all Veterans Affairs (VA) Health Care Facilities laboratories within a VISN, between
2513   VISNs, and non-VA organizations (i.e., commercial reference laboratories, Department of Defense (DoD), and etc.)
2514   without diminishing the quality of services in the patient medical care.
2515
2516   VistA Laboratory Electronic Data Interchange (LEDI) software application provided the new electronic messaging
2517   functionality for lab test ordering and result reporting between VA Health Care facilities laboratories. This electronic
2518   messaging functionality is based on the Health Level Seven (HL7) Version 2.3 and VistA Health Level Seven (HL7)
2519   Version 1.6 Standard Specifications. These specifications are used as the basis for defining VistA Laboratory
2520   Universal Interface (UI) and LEDI HL7 Interface Standard Specification Version 1.2. The
2521   following new electronic features and functionalities were implemented by the release of the VistA LEDI software
2522   application:
2523   • Electronic Messaging
2524   • Electronic Lab Test Ordering
2525   • Electronic Lab Test Results Reporting
2526   • Bar-code Specimen Accessioning
2527   • Workload
2528
2529   VistA Laboratory Electronic Data Interchange Phase III (LEDI III)
2530   The scope of the VistA LEDI III software enhancements involves the development of a bidirectional interface that
2531   allows VA and DoD facilities to be reference laboratories for each other. Laboratory test orders and results are
2532   transmitted via VA VistA systems using LEDI III for VA facilities and Laboratory Data Sharing and Interoperability
2533   (LDSI) software via DoD Composite Health Care System (CHCS) systems for DoD facilities. The VA/DoD LEDI III
2534   LDSI project was designed to determine a methodology that has the capacity and features necessary for sharing
2535   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-1
2536   orders/ results between VA and DoD facilities and implements enhancements to general LEDI functionality. The
2537   exchange of clinical chemistry laboratory data between VA and DoD facilities is a process of data transmission
2538   between VistA and CHCS systems using the HL-7 messaging protocol over a TCP/IP connection utilizing a secure
2539   Virtual Private Network (VPN)/firewall.




2540
2541                                                               Figure: 3.1-45
2542
2543   LEDI-Laboratory: Electronic Data Interchange - (Component diagram)
                                       cmp LEDI-Laboratory: Electronic Data Interchange



                                               LEDI - Laboratory
                                                Electronic Data
                                                  Interchange



                                                        «interface»
                                                    LEDI - Laboratory
                                                     Electronic Data          CHCS - Composit Health Care System
                                                       Interchange




2544
2545                                                               Figure: 3.1-46
2546
2547   3.1.35 EPI-Laboratory: Emerging Pathogens Initiative
2548   Under the auspices of the Program Office for Infectious Diseases VAHQ the Laboratory Emerging Pathogens
2549   Initiative (EPI) software package is to allow the Department of Veterans Affairs (DVA) to track Emerging Pathogens
2550   on the national level without the necessity for additional local data entry. Using this objective information, plans can
2551   be formulated on the national level for intervention strategies and resource needs. Results of aggregate data can
2552   also be shared with appropriate public health authorities for planning on the national level for the non- VA and private
2553   health care sectors.
2554



       www.oserha.org                                              OSEHR System-Architecture, Product Definition and Roadmap      Page 3-1
2555   Major functions:
2556   The Laboratory EPI program is designed to automatically provide data on emerging pathogens to Veterans Affairs
2557   Headquarters (VAHQ) without additional individual data entry at the site level. The data will be sent to Austin
2558   Automation Center (AAC) for initial processing and coupling with denominator data related to workload. VAHQ data
2559   retrieval and analysis can then be accomplished.
2560
2561   Objectives:
2562    Identify Emerging Pathogens.
2563    Extract specific data associated with the Emerging Pathogen.
2564    Transmit data to AAC.
2565    Create national Statistical Analysis System (SAS) data sets for Infectious Diseases Program Office access.
2566




2567
2568                                                       Figure: 3.1-47
2569
2570   3.1.36 Laboratory: Howdy Computerized Phlebotomy Login Process
2571   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-1
2572                                                                                                             Figure:
2573                                                        3.1-48
2574
2575   3.1.37 Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form
2576   The purpose of the National Laboratory Test (NLT) Mapping to the Logical
2577   Observation Identifier Names and Codes (LOINC) is to provide the mapping of CH subscripted tests result codes,
2578   and the standardization of files used in the Laboratory Software application. The LOINC committee including the
2579   largest clinical laboratories in the United States, and Veterans Affairs, has agreed to use LOINC to identify test
2580   results.
2581
2582   NLT Mapping to the Logical Observation Identifier Names and Codes (LOINC)
2583   has the following features:
2584   • Provides a method to communicate across laboratories in support of Clinical Information Resource Network
2585       (CIRN) by mapping VISTA lab tests to LOINC codes.
2586   • Provides sets of universal names and ID codes for identifying laboratory and clinical test results.
2587   • Allows the creation of a uniform naming convention for clinical terms.
2588   • Allows the merging of clinical data across sites (where terminology may vary widely).
2589   • Provides the requirement for the adoption of naming or coding conventions, and the mapping of local
2590       terminology to these conventions.
2591   • Maps the National Laboratory Test file (#64) to the LOINC codes.




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap           Page 3-1
2592
2593                                                     Figure: 3.1-49
2594
2595   3.1.38 POC-Laboratory: Point of Care
2596   The VistA Laboratory Point of Care (POC) Interface utilizes existing functionality provided by Laboratory Universal
2597   Interface (UI) and Laboratory Electronic Data Interchange (LEDI) software. The software supports the transmission,
2598   processing and storing of POC TEST RESULTS in the VistA Laboratory package. The ability of POC interfaces to
2599   subscribe to VistA HL7 Admissions, Discharge, Transfer (ADT) messages for patient demographics and location
2600   information is provided as needed. Support for 5 separate POC interfaces is provided. Additional interfaces can be
2601   added locally when naming of additional interfaces are in conformance to name spacing instructions.
2602
2603   POC is a type of interface that downloads and stores results for a bed side analyzer/ device or any instrument that
2604   performs laboratory testing at the site of care (examination, treatment, diagnosis, etc.). The accession and
2605   verification procedures are modified to accommodate POC type of data storage. POC results are not verified by the
2606   traditional laboratory methods.




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
2607
2608                                                        Figure: 3.1-50
2609
2610   3.1.39 Laboratory: Universal Interface
2611   The purpose of the VistA Laboratory Universal Interface (UI) Health Level (HL) v1.6 Upgrade Patch LA*5.2*66
2612   software release is to improve the transmission of laboratory test results from clinical analyzers to the VistA system.
2613   This release upgrades Lab UI from VistA’s Health Level Seven (HL) v1.5 to VistA’s HL v1.6, which includes the use
2614   of version 1.6 Transmission Control Protocol/ Internet Protocol (TCP/IP) functionality. This functionality supports the
2615   current Lab UI HL7 Interface Specifications based on the HL7 Standard V2.2.
2616
2617   The current UI interface using the HL v1.5 interface will continue to function after patch installation. The transition to
2618   the HL V1.6 interface can be accomplished after patch installation on a connection by connection basis. When
2619   possible, switching from the old interface to the new interface should be done on a per instrument basis instead of all
2620   instruments at once. Follow the post installation instructions to convert an interface to the HL V1.6 interface.
2621
2622   The Generic Instrument Manager (GIM) is a locally procured commercial device that controls communications
2623   between the Laboratory instruments and VistA. The VistA system downloads work lists through the GIM to the
2624   various instruments, and the instruments upload results to VistA through the GIM, eliminating the need for Laboratory



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap               Page 3-1
2625   developers to write a new interface for each different instrument. Due to the increased laboratory workload, higher
2626   instrument throughput, longer and more textual lab results, and the emergence of more efficient communications
2627   platforms have rendered HL7 v1.5 obsolete. HL7 v1.6 allows faster transmission, longer messages, and more
2628   advanced queue handling than HL7 v1.5.
2629
2630   NOTE: New Generic Instrument Manager (GIM) software must be obtained from the vendor in order for this new
2631   interface to work.
2632
2633   Additionally, HL7 messaging depends on VistA’s HEALTH LEVEL SEVEN package for validation and routing
2634   messages. Infrastructure Information Service (IIS) has recommended that all VistA applications upgrade to HL7 v1.6
2635   as soon as feasible.
2636
2637   NOTE: Information Infrastructure Systems (IIS) will make no further enhancements to the VistA HL v1.5 package.
2638
2639   Implementation of this enhancement is expected to cause no changes to the process of reporting lab results.
2640   Although faster, more efficient, and easier to manage, the process itself will not change. Since the release of
2641   Laboratory Electronic Data Interchange (LEDI) II to the field, sites are familiar with the configuration and file structure
2642   of HL7 v1.6.




       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                Page 3-1
2643
2644                    Figure: 3.1-51
2645




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
2646   Laboratory: Universal Interface - (Component diagram)
                                cmp Laboratory: Univ ersal Interface


                                        Laboratory: Univ ersal Interface




                                                             «interface»            GIM - Generic Instrument Manager
                                                             Laboratory:
                                                             Univ ersal
                                                              Interface
                                                                                        DHCP - Decentralized
                                                                                        Hospital Computer
                                                                                        Program




2647
2648                                                                   Figure: 3.1-52
2649
2650   3.1.40 VBECS-Laboratory: VistA Blood Establishment Computer Software
2651   The main purpose of the VistA Blood Establishment Computer Software (VBECS) is to automate the daily processing
2652   of blood inventory and patient transfusions in a hospital transfusion service.
2653
2654   VBECS is an improved Blood Bank application that facilitates ongoing compliance with Food and Drug Administration
2655   (FDA) standards for medical devices and enhances the VA VHA’s ability to produce high-quality blood products and
2656   services to veterans. The system follows blood bank standards, standards of national accrediting agencies, FDA
2657   regulations, and VA policies.
2658
2659   VBECS supersedes VistA Blood Bank v5.2 for blood bank operations. VistA Blood Bank v5.2 blood unit records
2660   remaining after the transfer of patient information to VBECS are available for reference only and cannot be edited.
2661   VistA Blood Bank v5.2 validation records must be maintained for five years after the last of the blood unit records is
2662   transferred to VBECS.




       www.oserha.org                                              OSEHR System-Architecture, Product Definition and Roadmap    Page 3-1
2663
2664                                                      Figure: 3.1-53
2665
2666   3.1.41 Lexicon Utility
2667   Namespace LEX
2668
2669   The Lexicon is a standardized reference for clinical terminology across VHA that enables clinical information to be
2670   recorded, transmitted, retrieved, and analyzed in a precise and consistent manner independent of clinic or medical
2671   center.
2672
2673   The Lexicon provides a comprehensive Application Program Interface (API) that enables any application that needs
2674   to use standardized terminology to be able to interface. At its inception in the early 1990s, the scope of the Lexicon
2675   was limited to expressing diagnostic clinical problems in easy-to-understand terminology and associating terms to
2676   coding systems such as International Classification of Diseases (ICD), Clinical Modification (ICD-9-CM), Diagnostic
2677   and Statistical Manual of Mental Disorders (DSM), and the North American Nursing Diagnosis Association (NANDA).
2678
2679   Over the years, this scope broadened to provide a general purpose utility that serves the terminology needs of many
2680   packages, including Problem List (standardized using SNOMED CT), Encounter Forms, Text Integration Utility (TIU),
2681   Event Capture, Federal Health Information Exchange (FHIE), and the Laboratory Data Sharing Interoperability (LDSI)
2682   project. A number of other VistA applications that need the versioned terminology that Lexicon can provide may be
2683   added to this list in the near future.
2684
2685   In addition to providing terminology, the Lexicon provides a coding system update deployment mechanism. This
2686   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-1
2687   addition to updating standard VistA reference files for the same coding systems that fall outside the Lexicon
2688   namespace. Additionally, the same mechanism is used to update coding systems that do not form part of the
2689   Lexicon. A large number of applications, packages, and services (VistA and external) are now dependent on the
2690   quarterly updates provided by this deployment mechanism. The dependent packages include Integrated Billing, Fee
2691   Basis, Automated Information Collection System (AICS), Laboratory, Dental, Prosthetics, Mental Health, Radiology,
2692   Surgery, Registration, Patient Care Encounter (PCE), Event Capture, Quality: Audiology and Speech Analysis and
2693   Reporting (QUASAR), Home Based Primary Care, Clinical Reminders, Text Integration Utility (TIU), Laboratory Data
2694   Sharing Interoperability (LDSI), and standardized Problem List.
2695
2696   All of the functionality and services provided by the Lexicon are expected to be replaced by a broader and deeper
2697   range of services through VA Enterprise Terminology Services (VETS) applications in the near future.
2698
2699   Features
2700   • Provides a basis for a common language of terminology, so that all members of a health care team can
2701       communicate with each other.
2702   • Provides a concept-based terminology that is well defined, understandable, and encodable by multiple coding
2703       schemes.
2704   • Provides for site modification of term definitions. These modifications are captured by the software and
2705       transmitted to the Lexicon team for ratification and possible inclusion in future updates.
2706   • Provides the ability to deploy updates to code systems from Standards Development Organizations (SDOs) that
2707       are required by statute, mandated by an oversight body, or required by VHA business needs. The current
2708       systems include CPT, HCPCS, CPT modifiers, ICD-9 Diagnoses, ICD-9 Procedures, and SNOMED CT.
2709   • Provides for user definable (user, specialty, or clinic) controlled views of vocabulary through the use of subsets
2710       that may be based on a combination of semantic types and code sources.
2711   • Accepts the provider term if a search of the dictionary does not find a match.
2712   • These terms (otherwise known as unresolved narratives) are captured by the software and forwarded to the
2713       Lexicon team for analysis and possible inclusion in future updates.
2714   • Allows abbreviations or shortcuts to provide quick access to frequently used definitions.
2715   • Supports CPT, HCPCS, ICD-9-CM Diagnoses, DoD DMIS-IDs, and SNOMED CT coding systems.
2716   • Optimizes search results by placing the most frequently-used terms near the start of the list.
2717   • Supports coding system versioning, activation history, and code text history.
2718   • Supports assignment of a VA Unique Identifier (VU ID) to a concept.
2719   • Supports code stratification and merging.
2720   • Supports synonyms, lexical variants, plural forms, abbreviations, word order variants, keywords, and excluded
2721       words.
2722   • Supports inter-coding system mappings.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
2723
2724                                                            Figure: 3.1-54
2725
2726   Lexicon Utility - (Component diagram)
                                      cmp Lexicon Utility



                                                  Lexicon Utility

                                                             «interface»
                                                            Lexicon Utility
                                                                                 G.LEXICON@
                                                                                 ISC-SLC.VA.GOV




2727
2728                                                            Figure: 3.1-55
2729
2730




       www.oserha.org                                          OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
2731   3.1.42 Medicine
2732   The Medicine package is a VA FileMan/ MUMPS-based computer program to serve the needs of the Department of
2733   Veterans Affairs Medicine Service medical community. Medicine test results are organized to help physicians to
2734   manage patient data with greater ease and furnish reports and patient data on a timely basis. It is an important part
2735   of the Decentralized Hospital Computer Program (DHCP), making maximum use of the hospital data base.
2736
2737   Functional Description
2738
2739   The Medicine package is designed for entry, edit, and display of data from a large number of medical tests or
2740   procedures. Printed reports are available for all procedures.
2741
2742   The modules currently included are Cardiology, Pulmonary, Gastrointestinal (GI), Hematology, Rheumatology,
2743   Pacemaker, and Generalized Procedure. Each module has a menu designed for entering, editing, and printing
2744   reports for various procedures/tests associated with that sub-specialty.
2745
2746   The Medicine package has access to the DHCP Imaging System which allows digital images of procedures to be
2747   attached to patient records when run at a workstation. The Imaging system stores, retrieves, transmits, and displays
2748   digital images of conditions and procedures. It allows the physician to have access to a complete view of patient data
2749   which in turn can be electronically shared with consulting physicians. The Imaging system accesses DHCP data such
2750   as laboratory results, pharmacy prescriptions and other clinical information, and displays them along with images of
2751   medical procedures which have been performed. Information such as prior images or previous diagnostic reports can
2752   be integrated and presented as a single record. The Imaging options are only usable on a workstation.
2753
2754   A Summary of Patient Procedures is provided on each menu. The option is documented in a separate section of the
2755   manual. This option allows a user to select a medical patient and obtain a listing of all procedures performed. The
2756   user can determine whether the data should be sorted by date or procedure. If sorted by procedure, the user has the
2757   option of choosing all procedures or a particular type of procedure. The user may select a particular procedure to
2758   view in detail.
2759
2760   Problem Oriented Consult is another option that is common throughout the Medicine package. It is also documented
2761   in a separate section.
2762
2763   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-1
2764
2765                                                       Figure: 3.1-56
2766
2767   Medicine - (Component diagram)
                                        cmp Medicine


                                                Medicine


                                                                      cMore
                                                 «interface»
                                                  Medicine            Medgraphics
                                                                     OE/RR

                                                                     Olympus

                                                                      Marquette

                                                                     DHCP Imaging System
                                                                      DelMar

                                                                      Sensormedics
                                                                     VISTA



2768
2769                                                       Figure: 3.1-57
2770
2771




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
2772   3.1.43 Mental Health
2773   The VistA Mental Health Assistant (MHA) is the graphical user interface (GUI) for the VistA Mental Health Package
2774   (MHP). MHA was developed to create an effective and efficient tool for mental health clinicians and their patients to
2775   use for the administration and scoring of assessment instruments and interviews. Additionally, results are displayed
2776   in report and graphical formats. MHA and MHP support mental health assessments (e.g., psychological testing,
2777   structured interviews, and staff rating scales) that are not available elsewhere in the Computerized Patient Record
2778   System (CPRS)/Veterans Information System and Technology Architecture (VistA). MHA has enjoyed widespread
2779   usage among mental health clinicians over the past several years, and the current revisions of MHA and MHP initiate
2780   steps toward re-engineering VistA Mental Health functionality.
2781
2782   The original revision of MHA created a closer integration with CPRS, by placing the MHA GUI on the CPRS Tools
2783   Menu. Additionally, functionality was created to allow a site to place an individual instrument on the Tools menu,
2784   allowing widespread access to that specific instrument without having to issue the menu for the MHP to all clinicians.
2785
2786   Additional functionality that strengthens the tie to the patient‘s medical record is the creation of a progress note in
2787   CPRS when an instrument is completed through MHA.
2788
2789   Furthermore, MHA maintains and strengthens its ties to the Clinical Reminders program, which allows for the
2790   presentation of specific instruments through reminder dialogs to all clinicians who resolve reminders.
2791
2792   To better meet the needs of clinicians and patients in different programs, particularly non-traditional settings, MHA
2793   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-1
www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
2795                                                      Figure: 3.1-58
2796
2797   Mental Health Installation Guide Release Notes V. 5.01, Dec 1994, p.3.
2798   Package Namespaces
2799   The YI, YS, and YT namespaces are assigned to Mental Health V. 5.01. All Mental
2800   Health V. 5.01 routines, options, bulletins, mail groups, and security keys use these
2801   namespaces. NOTE: YI and YT namespaces are used for testing and interview related
2802   software. All other software functionality has been placed in the YS namespace.
2803   Required Packages
2804   Before installing Mental Health V. 5.01, the following DHCP packages must be installed with the package versions. It
2805   is acceptable to install the version indicated, or any newer version. Package Required Version (or later)
2806   FileManager V. 20
2807   Kernel V. 7.1
2808   MAS V. 5.2
2809   OE/RR V. 2.5
2810   Progress Notes V. 2.5
2811
2812   MH ASI-MV Installation and User Guide (Patch YS*5.01*78)
2813   VistA Mental Health ASI-MV Patch YS*5.01*78, Nov 2004, p.14.
2814   Package Namespaces
2815   VistA Mental Health software namespace is YS.
2816   Required VistA Software Applications:
2817   RPC Broker 1.1
2818   Kernel 8.0
2819   VA FileMan 22.0
2820   Mailman 7.1
2821   Toolkit 7.3
2822   Computer Patient Record System (CPRS) 1.0.24.26
2823   Mental Health V. 5.01 YS*5.01*67 MUST be installed prior to installing VistA Mental Health ASI-MV Patch
2824   YS*5.01*78.
2825
2826   MHA3 Installation Guide (Patch YS*5.01*85), Dec 2007, p. 14.
2827   Package Namespaces
2828   MH Assistant Version 3 Patch YS*5.01*85 namespace is YS and YT.
2829   MHA3 Software Application Requirements
2830   Kernel v8.0
2831   VA FileMan 22.0
2832   Mailman 8.0
2833   RPC Broker 1.1
2834   Toolkit 7.3
2835   CPRS 26
2836   Mental Health V. 5.01 YS*5.01*76 MUST be installed prior to installing MHA3 Patch YS*5.01*85.
2837




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
2838   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                         MH- NDB
               Files\vista\Common Files
               All GAF scores entered through the Mental Health Assistant GAF form are dynamically sent to                      NMHDS
               the National Patient Care Database (NPCD) at the Austin Automation Center (AAC).
               All Mental Health Assessment data entered through the Mental Health Assistant Instrument                         COTS ASI-MV
               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.



2839
2840                                                                        Figure: 3.1-59
2841
2842
2843   3.1.44 MH: Addiction Severity Index
2844   The ADDICTION SEVERITY INDEX MULTIMEDIA VERSION (ASI-MV) is the primary instrument used in Veterans
2845   Health Administration (VHA) to evaluate individual patients’ response to substance dependence treatment and to
2846   evaluate the overall effectiveness of substance dependence treatment programs. Currently the ASI interview is
2847   administered through the VistA roll-and-scroll functionality. Patients’ ASI interviews are generally recorded on paper
2848   and entered later by the clinician or clerk. The ASI interview is a labor-intensive measure. It requires 45-60 minutes to
2849   administer an ASI interview and an additional 20 minutes following the interview to enter the data into the VistA
2850   Mental Health (MH) database using the roll-and-scroll method.
2851   The principal objective of the VistA MH ASI-MV Patch YS*5.01*78 software is to allow patients to respond to an ASI
2852   interview conducted by virtual (computer-animated) counselors. The VistA MH ASI-MV software application is a
2853   significant time-saver for clinicians, because clinicians need not be present during the interview, and are freed to use
2854   this time for other tasks.
2855
2856   VistA Mental Health Addiction Severity Index Multimedia Version (ASI-MV) Interface Software
2857   VistA MH ASI-MV interface software is updated to accompaniment the existing Addiction Severity Index (ASI)
2858   component of the VistA Mental Health V. 5.01 software application. The VistA MH ASI-MV interface introduces the
2859   functionality required to run the Commercial off the Shelf (COTS) Addiction Severity Index Multimedia Version (ASI-
2860   MV) software. The interface allows clinicians and patients to enter demographics and self-administered ASI-MV
2861   interviews via a PC workstation using video and audio technology. The VistA MH ASI-MV interface works mostly in
2862   the background. The demographic and interview data is temporarily stored on a PC workstation when an interview is
2863   completed and saved to the VistA MH database automatically when the software is executed again.
2864
2865   Commercial Off The Shelf (COTS) ASI-MV Software
2866   The COTS ASI-MV software is an effective, efficient, and scientifically researched tool used in substance abuse
2867   treatment centers, employee assistance programs, and other healthcare settings. The software utilizes a mouse-
2868   driven personal computer (PC) for administering an ASI-MV interview and gathering clinical data directly from a



       www.oserha.org                                                      OSEHR System-Architecture, Product Definition and Roadmap          Page 3-1
2869   client/patient/employee. The COTS ASI-MV software generates VistA -compatible data records that can be uploaded
2870   to the VistA database.
        class MH: Addiction Sev erity Index

                  Name:      MH: Addiction Severity Index
                  Package:   MH: Addiction Severity Index
                  Version:   Oct 2011
                  Author:    OSEHRA

                                                                                 Mental Health


                 MH: Addiction
                 Sev erity Index


                                                                                           MH v5.01


                                                                                      ASI-MV
              PCMM-Primary Care                                                                                          Kernel                              Kernel
              Management Module                                                                                          v8.0

                                                                                                                        Toolkit
                                                                                                                        v7.3

                                                                                                                                                         Kernel Toolkit




                                                                                               CPRS v
                                                                    RPC-Broker v1.1            1.0.24.26
              Pharmacy: Data                                                                                                                             CPRS: TIU-Text
               Management                                                                                                                               Integration Utility




                                                             RPC-Remote                            CPRS: Clinical                                      Namespace
                                                            Procedure Call                          Reminders
                                                                                                                                                           ^YS
                                                                Broker




                                                                                                           Patch YS*5.01*67 MUST be installed prior to installing VistA
            Documents available in the vdl: (http://www.va.gov/vdl/application.asp?appid=78)               Mental Health ASI-MV Patch YS*5.01*78.
            Name Date Created Last Updated                                                                 NOTE: YI and YT namespaces are used for testing and
              MH ASI-MV Installation and User Guide (Patch YS*5.01*78) 2004-11-01 2004-11-09             interview related software. All other software functionality has
                                                                                                           been placed in the YS namespace.


2871
2872                                                                         Figure: 3.1-60
2873
2874   ASI-MV - (Component diagram)
2875
2876
                                                            cmp ASI-MV



                                                                             ASI-MV




                                                                           «interface»
                                                                         ASI-MV::ASI-MV


                                                                                                 COTS ASI-MV




2877



       www.oserha.org                                                        OSEHR System-Architecture, Product Definition and Roadmap                                        Page 3-1
2878                                                      Figure: 3.1-61
2879
2880
2881   3.1.45 MRSA-Methicillin Resistant Staph Aurerus
2882   Manual data collection for the MRSA (Methicillin-Resistant Staphylococcus Aureus) Prevention Initiative is time
2883   consuming. The MRSA Program Tools (MRSA-PT) application provides a method to extract data related to MRSA
2884   nares screening, clinical cultures, and patient movements within the selected facility. MRSA-PT contains reports that
2885   will extract and consolidate required data for entry into the Inpatient Evaluation Center (IPEC). Reports can also be
2886   generated to display real-time patient specific information, and can be used to identify patients that have a selected
2887   multi-drug resistant organism (MDRO) and to identify patients who did or did not receive a MRSA nares screen upon
2888   admission to the unit.




2889
2890                                                      Figure: 3.1-62
2891
2892   3.1.46 MED-Mobile Electronic Documentation
2893   [Version TIU Patches 1.0 and MED GUI 2.3]
2894
2895   Mobile Electronic Documentation (MED) is an application that allows the creation of remote documentation and then
2896   import of that documentation into a note in Computerized Patient Record System (CPRS). It allows you to view
2897   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-1
2898
2899                                                     Figure: 3.1-63
2900
2901   3.1.47 NHIN-Nationwide Health Information Network Adapter
2902   The purpose of the Department of Veterans Affairs (VA) Nationwide Health Information Network (NHIN) Gateway
2903   Adapter Version 2.0 is to implement the actions necessary to exchange electronic health records (EHRs) generated
2904   from the VA and received from authorized NHIN Health Information Exchanges (HIEs). The VA NHIN Gateway
2905   Adapter uses a service-oriented architecture (SOA) to share patient health data and to communicate between
2906   systems.
2907
2908   The VA NHIN Adapter interfaces with the VA NHIN CONNECT Gateway, which is an implemented instance of the
2909   Federal CONNECT Gateway software. The Federal NHIN CONNECT Gateway is the product deliverable of the
2910   Federal Health Architecture (FHA), under the Department of Health and Human Services (HSS). This product is the
2911   result of the collaboration and shared development cost of a group of more than twenty government agencies known
2912   as the Federal Consortium. The VA has been exchanging medical information with the Department of Defense (DoD)
2913   for several years. By using the VA CONNECT Gateway together with the VA NHIN Adapter, the VA will now be able
2914   to share patient health data with other federal partners, as well as private providers, such as Kaiser Permanente.
2915
2916   The VA NHIN Gateway Adapter is a HealtheVet-VistA application that acts as a gateway between the VA and other
2917   Health Information Exchanges (HIEs) to share patient clinical records. The VA NHIN Gateway Adapter is deployed as
2918   a single, national instance at AITC (Austin Information Technology Center). Payloads are standards-based CDA
2919   (Clinical Document Architecture) XML documents. VistA data is retrieved through the use of VistALink-mediated RPC
2920   calls; HIE data retrieved by the NHIN Adapter is displayed by VistAWeb. The NHIN Adapter provides a read-only
2921   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-1
2922
2923                                                          Figure: 3.1-64
2924
2925   3.1.48 Nursing
2926   Nursing is a component of the Department of Veterans Affairs VistA program. It is comprised of modules
2927   Administration, Clinical, Education, Performance Improvement, and Research.
2928
2929   Administration:
2930   1) Personnel management information (demographic and professional data of nursing staff),
2931   2) Resource management/analysis tracking for reports on budgeting DRGs, overtime usage,
2932   patient care hours, supply equipment projections, and staffing hours, and
2933   3) Mandatory reports (i.e., AMIS 1106, AMIS 1106a, Annual Report).
2934
2935   Clinical:
2936   1) Patient classification,
2937   2) Patient assessment,
2938   3) Nursing care plans which are system focused and contain both nursing problems and medical diagnoses,
2939   4) Patient care assignments,
2940   5) Clinical protocols/guidelines for care,
2941   6) Patient education material,
2942   7) Discharge planning, and
2943   8) Other patient related medical record data.
2944
2945   Education:
2946   1) Education reports (i.e., mandatory inservice attendance, continuing education attendance,
2947   authorized absence/funding analysis), and
2948   2) Student affiliation information (i.e., scheduling of student clinical labs, affiliation agreements).
2949
2950   Performance Improvement:
2951   1) QA problem tracking system,
2952   2) Infection control trends,
2953   3) Patient incident analysis,
2954   4) Employee accident analysis,



       www.oserha.org                                         OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
2955   5) Continuous care monitors (clinical data), and
2956   6) Administrative monitors (e.g., safety equipment).
2957
2958   Research:
2959   1) Resource listing of VA nurse researchers, and
2960   2) Additional functionalities as defined by the Nursing Focus Group.




2961
2962                                                          Figure: 3.1-65
2963
2964   3.1.49 NFS-Nutrition and Food Service
2965   The VistA Nutrition and Food Service Systems software integrates the automation of many Clinical Dietetics and
2966   Food Management functions. The Clinical Dietetics activities of nutrition screening, nutrition assessment, diet order


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
2967   entry, tubefeeding and supplemental feeding orders, patient food preferences, specific diet pattern calculations,
2968   nutrient analysis of meals, consult reporting, encounter tracking, and quality care monitoring are all available in this
2969   program. Complete automation of food production activities, service and distribution, inventory and cost
2970   management, recipe expansion, menu and recipe nutrient analysis, meal and diet pattern development and
2971   implementation, diet card and tray ticket printing, quality service tracking, and annual management reports are also
2972   available. Detailed functionality and process activity for Nutrition and Food Service software are divided into two
2973   major areas of use: (1) options that the Manager/ADPAC needs to build files, set parameters, review data, and
2974   generate reports; and (2) options the general user needs for normal day-to-day automated Nutrition functions.
2975
2976   Features:
2977   • Allows the building of a site-specific listing of patient food preferences that can be incorporated in meal
2978       production calculations and the printed diet card and tray tickets programs.
2979   • Manages patients' requests or dietary requirements for specific food items or utensils, allowing the selection of
2980       standing orders for any patient, for any meal or quantity.
2981   • Controls all aspects of ingredient usage.
2982   • Develops a list of site-specific recipes that includes portion size, preparation area and time, equipment and
2983       serving utensils, recipe category, ingredients, and directions for preparation. Recipes can be quickly analyzed for
2984       their nutrient value.
2985   • Creates multiple meals and menu cycles. Meals can be used in different patterns by creating menu cycles or by
2986       creating special holiday dates within a cycle. It allows for the nutrient analysis of meals or daily/weekly menus.
2987   • Controls quantities produced in the Food Management program. Specific patient diet orders are reorganized into
2988       production diets and diet patterns that reflect the foods to be served. This information is used along with data
2989       from the meal file to generate production reports, diet cards and/or tray tickets. A forecasting tool also exists in
2990       this section that allows the manager to anticipate, by percentage of total census, the type and quantity of various
2991       production diets that will be needed by any selected service point.
2992   • Allows the entry of information required by the Annual Report that is not automatically retrieved from the
2993       program.
2994   • Prints a patient-specific record of all diet order entry information.
2995   • Controls the order entry activity.
2996   • Manages food items and their nutrients using the latest USDA data, food items from Bowes and Church, and
2997       additional data from research.
2998   • Handles N&FS consults and allows the reassignment of active consults from one staff member to another.
2999   • Manages the supplemental feeding food items and menus. A supplemental feeding menu automatically goes
3000       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-1
3001
3002                                                       Figure: 3.1-66
3003
3004   3.1.50 Oncology
3005   OncoTraX: Cancer Registry is an integrated collection of computer programs and routines, which work together in
3006   assisting the Cancer Registrars to create and maintain a cancer patient database. The software creates case listings
3007   and registry reports for Cancer Boards (Cancer Conferences), special studies, and the Annual Report recommended
3008   by the American College of Surgeons (ACoS).
3009
3010   The software allows the Cancer Registrars to:
3011   1. Perform case finding.
3012   2. Identify potential cases to include in your registry, enter the pertinent data directly into the computer system, and
3013   maintain patient follow-up information on an annual basis.
3014   3. Enter abstracts.
3015   4. Download and transmit data electronically to the VA Central Cancer Registry, state central registries, the National
3016   Cancer Database for the ACoS Call for Data.
3017   5. Produce several reports by using an option in the Utility menu.
3018
3019   Note: Several reports within the software provide basic information; however, for more specific reports, you need to
3020   know basic FileMan functions. Any and all data collected within an abstract can be pulled back into reports.
3021
3022   6. Print out by year the number of cases by site, including sex, race, and stages.
3023   7. Generate follow-up reports as required by the ACoS



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3024
3025   Note: OncoTraX is in complete compliance with all ACoS required data elements, and is updated as changes occur.
3026
3027   OncoTraX is used by cancer registrars and meets all requirements set forth by the American College of Surgeons for
3028   approved cancer programs.
3029
3030   Note: OncoTraX makes extensive use of Help screens, but it does not replace the use of your reference manuals.
3031
3032   Features:
3033   • The software supports multi-divisional sites.
3034   • The program automatically finds cases by searching the database from Anatomical Pathology (Surgery,
3035       Cytology, Electron Microscopy, and Autopsy), Radiology, and Patient Treatment File (PTF). Cases can be
3036       entered into the Suspense File by date of diagnosis, and chart request pull lists can be printed.
3037   • Demographics are drawn directly from Patient Information Management System (PIMS) patient file and stored
3038       permanently. Cancer identification data is obtained from the local database (e.g., laboratory and radiology test
3039       results).
3040   • The program accessions and abstracts with extensive on-line help and stages the extent of disease
3041       automatically.
3042   • It produces a wide range of follow-up lists and registry lists needed for accreditation and allows entry of contacts
3043       directly into Oncology Contact File.
3044   • Professional letters covering diverse situations and customization of letters are available.
3045   • Predefined annual reports can be generated and the user can create specialized reports using VA FileMan.
3046   • Reports to the Associate Chief of Staff (ACOS) can be generated using special routines that extract data onto
3047       floppy disk. The same functionality is available for state reporting.
3048   • The database can be customized to suit the individual hospital.
3049   • The full set of TNM codes is included from the appropriate edition of the AJCC Manual on Staging of Cancer.
3050   • The program allows on-line completion of Patient Care Evaluations (PCEs) during the abstracting function if the
3051       case being abstracted fulfills the selection criteria for the PCE.




3052
3053                                                      Figure: 3.1-67
3054
3055   3.1.51 PAIT-Patient Appointment Information Transmission
3056   The Patient Appointment Information Transmission (PAIT) was developed and released in patch SD*5.3*290 to
3057   provide patient appointment wait time statistics to the national database in Austin, TX. An initial seeding routine


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
3058   scanned patient appointments created from September 1, 2002 to the date that Patch SD*5.3*290 was installed. The
3059   One-Time Option Queue from the TaskMan Management menu was used to start SD-PAIT TASKED
3060   TRANSMISSION on a scheduled date per site—each of the 128 sites at the time was assigned its own start date.
3061
3062   Patch SD*5.3*290 was released on November 26, 2003. Only Pending appointments were selected for the seeding
3063   process. Subsequent bimonthly PAITs update the National Database. Appointment data is wrapped in HL7 batch
3064   messages and transmitted to the Austin Information Technology Center (AITC). This additional data supplements the
3065   existing Clinic Appointment Wait Time extracts 1 and 2. Transmissions should be scheduled on the 1st and 15th day
3066   of each month. The bi-monthly task will collect and format data for HL7 batch transmission.
3067
3068   PAIT enhances the process of collecting and storing appointment data for bi-monthly transmission to the AITC:
3069   • Capturing selected data about the patient’s appointment eligibility including Combat Veteran and Military History
3070   • Identifying the date and time services were desired, scheduled and provided
3071   • Tracking and updating appointments through checkout, cancellation, rebooking, etc.




3072
3073                                                      Figure: 3.1-68
3074
3075   PAIT-Patient Appointment Information Transmission - (Component diagram)
3076
3077




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap           Page 3-1
                   cmp PAIT-Patient Appointment Information Transmission



                       Patient Appointment
                           Information
                                                               Veterans Health Administration Support
                          Transmission
                                                               Service Center at the Austin Information
                                                               Technology Center (AITC)




3078
3079                                                       Figure: 3.1-69
3080
3081   3.1.52 PADP-Patient Assessment Documentation Package
3082   There are no documents for this application at this point. [October 30, 2009]




3083
3084                                                       Figure: 3.1-70
3085
3086   3.1.53 PCE-Patient Care Encounter
3087   Patient Care Encounter (PCE) captures clinical data resulting from ambulatory care patient encounters. The captured
3088   clinical data documents “encounters” and related encounter information, such as problems treated at encounter,
3089   procedures done, immunizations, patient education, and skin tests.
3090
3091   PCE provides a data repository for long-term clinical data. A goal of PCE is to support many data capture methods
3092   for integrating clinical data from many environments. Pilot efforts have included population of the PCE clinical
3093   repository via scanner technologies and workstations. The key users of this clinical data are clinicians, management,
3094   and Quality Management personnel.
3095
3096   Features
3097   • Acts as VA’s long-term clinical repository, documenting encounters from local and non-VA facilities.
3098   • Provides a primary and secondary clinical visit management utility based on appointments and related services.
3099   • Interfaces with the Health Summary package to provide components based on data captured and stored in the
3100       PCE clinical repository.
3101   • Supports capture of outpatient encounter data. Data collection methods include:
3102            o Interface between scanner/workstation and clinical repository.
3103            o On-line data capture using List Manager user interface.


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
3104          o   Historical load utilities for lab and outpatient pharmacy.
3105          o   Future methods will include automatic protocol event driver.




3106
3107                                                    Figure: 3.1-71
3108




       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
3109   PCE-Patient Care Encounter - (Component diagram)
                                     cmp PCE-Patient Care Encounter



                                              PCE-Patient Care
                                                 Encounter

                                                       «interface»
                                                     PCE-Patient Care                  PANDAS
                                                      Encounter::PX
                                                                                       TeleForm




3110
3111                                                         Figure: 3.1-72
3112
3113   3.1.54 Visit Tracking
3114   Visit Tracking is documented as a part of PCE, "PCE V. 1.0 & Visit Tracking V. 2.0 Technical Manual "
3115
3116   Introduction
3117   The Visit Tracking software is designed to link patient-related information in a filestructure that will allow meaningful
3118   reporting and historically accuratecategorization of patient events and episodes of care.
3119
3120   Background
3121   This version of Visit Tracking is a hybrid of a Visit Tracking module developed byand operating at Indian Health
3122   Service (IHS) facilities as part of their Patient Care Component (PCC) and Visit Tracking V. 1.0 developed by the
3123   Dallas InformationSystems Center (ISC) for the Joint Venture Sharing (JVS) sites and operating atAlbuquerque, NM.
3124   The primary data file (VISIT file #9000010) developed by IHS is used with some additional fields and modifications
3125   for VA needs. The supportingsoftware was developed with the intent to operate without modification in either facility.
3126
3127   Relationshipto other packages
3128   Visit Tracking is not a stand-alone application. Other packages will normally callPCE, which will handle the calls to
3129   Visit Tracking.
3130
3131   Functions provided
3132   The Visit Tracking system provides three primary functions:
3133   • Creating and/or matching a visit record using input criteria and user interaction(optionally)
3134   • Providing a list of visits matching input criteria
3135   • Maintaining the VISIT file (#9000010) and its records
3136   Visit Tracking is a utility that can be used by a variety of VISTA modules, with potential benefits for clinical,
3137   administrative, and fiscal applications. Visit Trackingwill allow VISTA packages to link an event to a patient visit entry,
3138   thereby linkingthat event to any number of events occurring throughout the hospital during thepatient’s outpatient
3139   and/or inpatient episode.




       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                Page 3-1
3140
3141   Benefits
3142   • The VISIT file (#9000010) will be a key file in the implementation of the clinicalrepository.
3143   • The VISIT file provides a home for documenting when and where other facilityevents have occurred.
3144   • Medical Care Cost Recovery (MCCR) can obtain billing information related to aclinic visit, a step towards
3145      itemized billing.
3146   • Visit Tracking provides an environment for relating clinical information to theservice visit for workload tracking or
3147      query by service views, as well as by theaggregate clinic visit view.
3148   • Users have the potential to control the Visit level of granularity while reviewingpatient information (e.g., only view
3149      visits from the primary clinic visit level: anaggregate view or only ancillary visits).
3150   • The date and time stamp on clinic and ancillary visits could be useful forretrospective work flow analysis. It may
3151      be exploitable as a Clinical EventSummary file useful to researchers doing longitudinal patient studies.
3152   • A breakdown of clinical care provided by primary and secondary providers couldhelp document the clinical
3153      experience of trainees (including residents, interns, and other clinicians) who require this information for
3154      privileging andcredentialing purposes.
3155   • Visit tracking has the capability to generate patient activity reports that arebased on accurate historical
3156      information.
3157   • The category of patient receiving care can be identified based on a specificepisode of care.
3158   • Medical data can be stored for historical purposes without the requirements ofspecific fields, except for the
3159      patient and date.
3160   • Visit tracking has the ability to associate ancillary services provided to a patient with a DSS ID, admission, and
3161      non-patient encounter (phone contact, pharmacy mail-out, etc.)




3162
3163                                                       Figure: 3.1-73
3164
3165   3.1.55 Patient Record Flags
3166   Patient record flags are used to alert VHA medical staff and employees of patients whose behavior and
3167   characteristics may pose a threat either to their safety, the safety of other patients, or compromise the delivery of
3168   quality health care. These flag assignments are displayed during the patient look-up process.



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3169
3170   The use of patient record flags must be strictly controlled and implemented following the instruction provided in VA
3171   Directive 2003-048 (see Appendix).
3172   The Patient Record Flags (PRF) software provides users with the ability to create, assign, inactivate, edit, produce
3173   reports, and view patient record flag alerts. Patient record flags are divided into Category I (national) and Category II
3174   (local) flags.
3175
3176   Category I flags are nationally approved and distributed by VHA nationally released software for implementation by
3177   all facilities. The Category I flag is shared across all known treating facilities for the patient utilizing VistA HL7
3178   messaging.
3179
3180   Category II flags are locally established by individual VISNs or facilities. They are not shared between facilities.




3181
3182                                                         Figure: 3.1-74
3183
3184   3.1.56 AR/WS-Pharmacy: Automatic Replenishment/ Ward Stock
3185   Automatic Replenishment (AR)/Ward Stock (WS) is a method of drug distribution and inventory management within a
3186   hospital. Drug products can be automatically inventoried and delivered (AR) to an area of use (AOU) or requested on
3187   demand (WS). An area of use is the place where commonly stocked items are stored. The area is potentially
3188   composed of wards, clinics, and specialties. The Automatic Replenishment process usually consists of the following
3189   functions: 1) select the AOUs and types of items within each AOU to be inventoried, 2) visit each AOU and take
3190   inventory, 3) determine the quantity to be dispensed for each item, and 4) dispense the item. The Automatic
3191   Replenishment module is designed to allow each VAMC to adapt the system to its own needs.
3192
3193   Version 2.3 of the AR/WS package contains several new features. Several new options have been added. On the
3194   Supervisor’s Menu there is now a Duplicate Entry Report option that prints a report of duplicate entries. The report
3195   will show all inventory, return, and on-demand data for each drug selected. The Single AOU Inventory Print option
3196   has been added to the Production menu. This option will print an inventory sheet for a single AOU that is included in
3197   the inventory date/time. In addition, a new Crash Cart Menu has been added, and all reports have been modified to
3198   allow selection of AOUs by Inventory Group and changed to form feed only at the end of a report.
3199
3200   Features:



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3201   The AR/WS package:
3202   • Provides inventory management capabilities for clinical care locations and drug crash carts.
3203   • Allows easy drug item inactivation for inventory locations.
3204   • Provides tools to develop medication storage areas with lists of drugs to be maintained in that area. Drugs are
3205       classified by inventory type and assigned storage location and stock level.
3206   • Groups medication storage areas together by inventory group name. Grouping may be by location, date (time or
3207       frequency of inventory), or inventory type.
3208   • Provides tools to conduct inventory: prints inventory sheets and/or pick lists to determine stock to be replenished
3209       in medication storage areas and, by a selected method, replaces needed inventory items.
3210   • Maintains backorder totals if a physical inventory is conducted and entered into AR/WS software.
3211   • Provides inventory management reporting capabilities for clinical care locations and drug crash carts.
3212   • Provides ability to select by inventory group on all reports.
3213   • Supplies a report to fill on-demand requests for out-of-stock items or items not part of the standard inventory.
3214   • Provides various printouts as well as several management statistical reports for the creation and maintenance of
3215       the system.




3216
3217                                                      Figure: 3.1-75
3218
3219   3.1.57 BCMA-Pharmacy: Bar Code Medication Administration
3220   The Bar Code Medication Administration (BCMA) V. 3.0 software includes routines, files, enhancements,
3221   maintenance fixes, and Phase Release changes for BCMA V. 2.0.
3222
3223   BCMA V. 3.0 software is designed to improve the accuracy of the medication administration process. By automating
3224   this process, Department of Veterans Affairs Medical Centers (VAMCs) can expect enhanced patient safety and
3225   patient care.
3226


       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
3227   The electronic information that BCMA V. 3.0 provides clinicians improves their ability to administer medications safely
3228   and effectively to patients on wards during their medication passes. It also helps to improve the daily communication
3229   that occurs between Nursing and Pharmacy staffs.
3230
3231   Features:
3232   The BCMA software provides the following features:
3233   • Medication Tabs on a patient’s Virtual Due List (VDL) are designed for separating and viewing the different types
3234       of active Unit Dose, IV Push, IV Piggyback, and large-volume IV medication orders. Each Tab provides an “alert”
3235       light, which turns green only when the patient has active medication orders for that Tab.
3236   • Patient safety tools include a Missed Medications Report, an alert when due medications are not administered, a
3237       notification when a patient is transferred, and an alert light to indicate that a medication order exists for the
3238       Schedule Type and Start/Stop Date and Time selected on the VDL. Other tools include a listing of Allergies and
3239       Adverse Drug Reactions (ADRs) that are documented for a patient in the Allergy/Adverse Reaction Tracking
3240       (ART) package.
3241   • A Computerized Patient Record System (CPRS) Med Order Button (or “Hot Button”) on the BCMA Tool Bar
3242       streamlines the workflow in ICU-type environments. This button links nurses directly to CPRS for electronically
3243       ordering, documenting, reviewing and signing verbal and telephone STAT and NOW (One-Time) medication
3244       orders already administered to patients.
3245   • BCMA increases the amount and type of information available to nurses at the point of care, improves
3246       communications between Nursing and Pharmacy staff, records Missing Doses for patients, sends an electronic
3247       Missing Dose Request to the Pharmacy, and supports Health Level Seven (HL7) messaging.
3248   • Management and accountability tools identify PRN entries that require effectiveness comments and pain scores,
3249       list medications that were not scanned as administered during an administration time window, list early/late
3250       administration variances, and allow nurses to set site-specific parameters and defaults on their systems.
3251   • Compiles reports by Patient or by Ward for Nursing, Pharmacy, and Information Resources Management (IRM).
3252       Reports available for printing include: a Medication Administration History, Medication Log, Missed Medications,
3253       Missing Dose Request, PRN Effectiveness Log, Medication Due List, Medication History, Medication Variance
3254       Report, Cumulative Vitals/Measurement Report, and Administration Times Report.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3255
3256                                                     Figure: 3.1-76
3257
3258   3.1.58 PBM-Pharmacy: Benefits Management
3259   Pharmacy Benefits Management (PBM) V. 4.0 is a new enhanced version of the software and replaces PBM V. 3.0.
3260   In a series of three enhancements, new extracts and reports were created, existing extracts were modified, and some



       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
3261   options were modified to increase the functionality of this software package. For more detail, refer to the Pharmacy
3262   Benefits Management V. 4.0 Release Notes document.
3263
3264   The software extracts medication dispensing data elements from the Outpatient Pharmacy, Inpatient Medications
3265   Intravenous (IV) and Unit Dose (UD), Automatic Replenishment/Ward Stock (AR/WS), Controlled Substances (CS)
3266   modules, Procurement information from Drug Accountability, Integrated Funds Control, Accounting and Procurement
3267   (IFCAP), and a limited amount of Laboratory data on a monthly basis.
3268
3269   The extracted data is electronically exported via MailMan to the PBM section in Hines, Illinois. MailMan messages
3270   are downloaded to text files onto the PBM network. These electronic messages are then passed through a translation
3271   process, which pulls text files into a database format and is checked for quality assurance and converts all local drug
3272   names to a common drug name and all local dispensing units to a common dispensing unit if possible. After
3273   translation, the information is added to the PBM national database.
3274
3275   Through an option placed on the pharmacy supervisor menu, the software makes data extraction reports available at
3276   local Veterans Affairs Medical Centers (VAMCs) and allows local management to use this data to project local drug
3277   usage and identify potential drug accountability problem areas. The PBM section is able to provide information on
3278   Local Facility, Veterans Integrated Service Network (VISN), and National product use on monthly, quarterly, and
3279   annual intervals. Pharmacy personnel at VAMCs and VISNs shall use this application to collect and report on
3280   pharmacy and patient statistics through user-executed options. Users of the database include the PBM, VAMCs,
3281   VISNs, and the research community.
3282
3283   PBM V. 4.0 extracts additional data elements and modifies current extracts to take advantage of enhancements
3284   made to the other Pharmacy modules since the release of previous versions (D&PPM V. 2.0) and PBM V. 3.0.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3285
3286                                                  Figure: 3.1-77
3287
3288   3.1.59 Pharmacy: Consolidated Mail Outpatient Pharmacy
3289   The Consolidated Mail Outpatient Pharmacy (CMOP) software package establishes an interface for the electronic
3290   transfer of information between Veterans Affairs Medical Centers (VAMCs) and the Consolidated Mail Outpatient
3291   Pharmacy host system for an integrated and highly automated outpatient prescription dispensing system.




       www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap        Page 3-1
3292
3293                                                       Figure: 3.1-78
3294
3295   3.1.60 Pharmacy: Controlled Substances
3296   The Controlled Substances (CS) software package is one segment of the Veterans Health Information Systems and
3297   Technology Architecture (VISTA) installed at VA medical centers. The Controlled Substances module provides
3298   functionality to monitor and track the receipt, inventory, and dispensing of all controlled substances. This module
3299   provides the pharmacy with the capability to define a controlled substance location and a list of controlled substances
3300   to maintain a perpetual inventory.
3301
3302   This software provides the capability for pharmacy personnel to receive a Controlled Substances order, automatically
3303   update the quantity on hand, and view a receipt history. Nursing personnel are provided with the ability to request
3304   orders for Controlled Substances via on-demand requests. Pharmacy may dispense controlled substances via the
3305   software automating all necessary documents (VA FORMS 10-2321 and 10-2638) to complete an order request. The
3306   software provides functionality to record AMIS and Cost data, address returns to stock, destructions, order
3307   cancellations, transfers between locations, and log outpatient prescriptions.
3308
3309   Monthly (or more frequent) inspections can be conducted by management, with discrepancies in stock levels
3310   automatically identified.
3311
3312   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-1
3313
3314   A list of the new additions and modifications to existing options includes:
3315   • Batch Order Entry process
3316   • Electronic Signature
3317   • HL7 Interface to Narcotic Dispensing Equipment
3318   • Electronic Error & Enhancement Requests (E3Rs)
3319   • Green Sheets now print on plain paper
3320   • Other Enhancements




3321
3322                                                        Figure: 3.1-79
3323


       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
3324   Pharmacy: Controlled Substances - (Component diagram)
                                     cmp Pharmacy: Controlled Substances



                                             Pharmacy:
                                             Controlled
                                             Substances




                                               «interface»
                                               Pharmacy:
                                               Controlled             NDES - Narcotic Dispensing Equipment
                                               Substances             Systems




3325
3326                                                           Figure: 3.1-80
3327
3328   3.1.61 Pharmacy: Data Management
3329   Pharmacy Data Management (PDM) provides tools for managing Pharmacy data. It includes tools for creating
3330   Pharmacy Orderable Items and maintaining files necessary for the Computerized Patient Record System (CPRS).
3331   PDM consolidates tools for managing the various Pharmacy software products. It provides Pharmacy Supervisors, in
3332   one location, the capability to enter and edit data from the local DRUG file (#50) for all Pharmacy related packages.
3333   PDM now allows users to enter medication instruction components (e.g., dosage, noun, verb, expansion) in a
3334   language other than English. However, at this time, the Patient Medication Information Sheets only allow patient data
3335   to be in English or Spanish.




       www.oserha.org                                         OSEHR System-Architecture, Product Definition and Roadmap        Page 3-1
3336
3337                    Figure: 3.1-81
3338




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
3339   3.1.62 Pharmacy: Drug Accountability
3340   The Drug Accountability/Inventory Interface program (referred to as DA) V. 3.0 works toward a perpetual inventory for
3341   each Veterans Affairs facility’s pharmacy. This is achieved by tracking drugs through pharmacy locations based on
3342   the connection between the DRUG (#50) file and ITEM MASTER file (#441) or between the prime vendor’s invoice
3343   file and the DRUG file (#50).
3344
3345   The DA V. 3.0 software package provides functionality to maintain a perpetual inventory of drugs. Interfacing with the
3346   Generic Inventory Package (GIP) and the prime vendors’ invoice data increments drug balances in pharmacy
3347   locations and master vaults. Pharmacy’s dispensing software packages pass dispensing data to DA V. 3.0 which
3348   decrements the drug balances in pharmacy locations.




3349
3350                                                      Figure: 3.1-82


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
3351
3352   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




3353
3354                                                                 Figure: 3.1-83
3355
3356   3.1.63 Pharmacy: Inpatient Medications
3357   The Inpatient Medications package provides a method of management, dispensing, and administration of inpatient
3358   drugs within the hospital. Inpatient Medications combines clinical and patient information that allows each medical
3359   center to enter orders for patients, dispense medications by means of Pick Lists, print labels, create Medication
3360   Administration Records (MARs), and create Management Reports. Inpatient Medications also interacts with the
3361   Computerized Patient Record System (CPRS) and the Bar Code Medication Administration (BCMA) packages to
3362   provide more comprehensive patient care.
3363
3364   Features:
3365   Integrated software allows these features, via the List Manager interface, for both IV and Unit Dose. This provides the
3366   user the capability to:
3367   • Browse through a list of orders and take action(s) against those items.
3368   • Print 7-day, 14-day, and 24-hour MARs, labels, and profiles from within the options.
3369   • Select a detailed allergy report, document new allergies or adverse drug reactions.
3370   • Update the Patient’s Record from within List Manager.
3371   • Provides Drug/Drug Interaction, Drug/Class Interaction, Duplicate Drug, and Duplicate Class Order checks.
3372   • Allows easier drug selection using Orderable Item.
3373   • Provides on-line order maintenance (for example: edit, renewal, cancellation) and marks orders that need
3374        attention.
3375   • Provides on-line order entry with an integrity check for each order type.
3376   • Generates labels containing order and patient information upon the entry/maintenance of an order.
3377   • Provides on-line or printed patient profiles that include a history of medication orders for the current or last
3378        medical center visit.
3379   • Displays patient order information and histories of all actions taken on active orders.
3380   • Provides an Action Profile of patient medication orders for use by physicians to cancel or continue medications.
3381   • Provides a Stop Order Notice report to notify users of orders near expiration.
3382   • Cancels/holds medication orders for patients transferred between wards and/or services.
3383   • Provides dispensing cost reports by patient, ward, service, drug, and providers.
3384   • Provides reports and forms by patient, ward, and selected groups of wards.




       www.oserha.org                                                OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
3385   •   Allows electronic entry and inpatient processing of medication orders for an outpatient receiving treatment via a
3386       clinic or ancillary service.
3387
3388   Pharmacy: Inpatient Medications - Intravenous (IV)
3389   Inpatient Medications’ Intravenous (IV) module provides pharmacists and their staffs with IV labels, manufacturing
3390   worksheets, ward lists for order updates, and management reports. It permits the Pharmacy staff to track the
3391   manufacture of IV formulas with greater control than manual procedures allow.
3392   Through order entry and ward list updating, the staff can easily establish and maintain an accurate and timely data
3393   set of IV orders. A carefully designed set of checks and balances has been incorporated to ensure that the patient is
3394   supplied IV solutions quickly and accurately.
3395
3396   Features:
3397   IV module:
3398    Generates Manufacturing Lists to facilitate maximum efficiency in the preparation and delivery of IV products.
3399    Generates IV labels containing all necessary patient, drug, and schedule information. Labels provide a bar-
3400       coded identifier which when used in conjunction with Bar Code Med Administration greatly enhances patient
3401       safety.
3402    Generates management reports designed to track drug costs and workload by ward, provider, IV room, and
3403       patient.
3404    Provides on-line generation of production reports such as renewal lists, active order lists, and formulary drug
3405       reports.
3406    Discontinues/holds orders for patients transferred between wards and/or services.
3407
3408   Pharmacy: Inpatient Medications - Unit Dose (UD)
3409   The Unit Dose (UD) module of Inpatient Medications provides a standard computerized system for dispensing and
3410   managing inpatient medications. Timely, accurate, accessible, and up-to-date patient medication information is
3411   available from any terminal within the facility. Computer-generated working forms allow personnel to dedicate more
3412   time to patient care.
3413
3414   Features:
3415   Unit Dose module:
3416    Allows immediate entry of pre-defined sets of unit dose orders.
3417    Provides computerized pick lists, which include pre-calculated doses for pharmacists.
3418    Provides an interface to automated dispensing equipment.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
3420                                                      Figure: 3.1-84
3421   Documents available in the vdl: (http://www.va.gov/vdl/application.asp?appid=88)
3422   Name Date Created         Last Updated
3423     API Manual - Pharmacy Reengineering (PRE) 2010-02-10                 2010-02-10
3424     Installation Guide- MOCHA v1.0 Combined Build (PSS*1*117, PSO*7*251, PSJ*5*181, OR*3*272, PSO*7*375,
3425      PSS*1*163) REVISED                2011-08-12       2011-08-12
3426     Nurse's User Manual 2011-07-12            2011-07-12
3427     Nurse's User Manual Change Pages - PSJ*5*1132010-06-23               2010-06-23
3428     Nurse's User Manual Change Pages - PSJ*5*1202007-06-08               2007-06-08
3429     Nurse's User Manual Change Pages - PSJ*5*1342008-08-26               2008-08-26
3430     Nurse's User Manual Change Pages - PSJ*5*1452007-08-06               2007-08-06
3431     Nurse's User Manual Change Pages - PSJ*5*160/175             2007-10-25       2007-10-31
3432     Nurse's User Manual Change Pages - PSJ*5*1812011-04-20               2011-04-20
3433     Nurse's User Manual Change Pages - PSJ*5*1962009-03-23               2009-03-23
3434     Nurse's User Manual Change Pages - PSJ*5*2152009-10-28               2009-10-28
3435     Nurse's User Manual Change Pages - PSJ*5*2222010-02-05               2010-02-05
3436     Nurse's User Manual Change Pages - PSJ*5*2432011-07-12               2011-07-12
3437     Pharmacist's User Manual          2011-07-12       2011-07-12
3438     Pharmacist's User Manual Change Pages - PSJ*5*113 2010-06-23                  2010-06-23
3439     Pharmacist's User Manual Change Pages - PSJ*5*120 2007-06-08                  2007-06-08
3440     Pharmacist's User Manual Change Pages - PSJ*5*134 2008-08-26                  2008-08-26
3441     Pharmacist's User Manual Change Pages - PSJ*5*145 2007-08-06                  2007-08-06
3442     Pharmacist's User Manual Change Pages - PSJ*5*160/175                2007-10-25       2007-10-31
3443     Pharmacist's User Manual Change Pages - PSJ*5*181 2011-04-20                  2011-04-20
3444     Pharmacist's User Manual Change Pages - PSJ*5*196 2009-03-23                  2009-03-23
3445     Pharmacist's User Manual Change Pages - PSJ*5*214 2010-02-24                  2010-02-24
3446     Pharmacist's User Manual Change Pages - PSJ*5*215 2009-10-28                  2009-10-28
3447     Pharmacist's User Manual Change Pages - PSJ*5*222 2010-02-05                  2010-02-05
3448     Pharmacist's User Manual Change Pages - PSJ*5*232 2010-10-13                  2010-10-13
3449     Pharmacist's User Manual Change Pages - PSJ*5*243 2011-07-12                  2011-07-12
3450     Pharmacy Ordering Enhancements (POE) Phase 2 Installation Guide               2001-09-01      2001-09-24
3451     Release Notes (CPRS V27 Project)          2008-08-26         2008-08-26
3452     Release Notes (IMO Project) 2006-04-01             2006-04-30
3453     Release Notes (IMO-Phase I II and IMR-Phase II)              2005-03-01       2005-03-31
3454     Release Notes (IMO/IMR-Phase II)          2005-01-01         2005-01-31
3455     Release Notes (IMR-Increment I)           2010-06-23         2010-06-23
3456     Release Notes (IMR-Phase I) 2004-09-01             2004-10-06
3457     Release Notes (Medication Order Check Healthcare Application (MOCHA) v1.0)            2011-04-20      2011-
3458      04-20
3459     Release Notes (Patients on Specific Drug(s) Multidivisional Enhancements) 2010-02-23          2010-02-23
3460     Release Notes (PBM Demographics Enhancements)                2009-07-21       2009-07-21
3461     Release Notes (POE) 2001-09-01            2001-09-24
3462     Release Notes (PSJ*5*160/175)             2007-10-25         2007-12-06
3463     Release Notes (RDI Project) 2005-12-01             2005-12-22



       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap        Page 3-1
3464      Supervisor User Manual        2011-04-20      2011-04-20
3465      Supervisor User Manual Change Pages - PSJ*5*120       2007-06-08      2007-06-08
3466      Supervisor User Manual Change Pages - PSJ*5*181       2011-04-20      2011-04-20
3467      Supervisor User Manual Change Pages - PSJ*5*214       2010-02-24      2010-02-24
3468      Technical Manual / Security Guide     2011-04-20      2011-04-20
3469      Technical Manual / Security Guide Change Pages - PSJ*5*113    2010-06-23      2010-06-23
3470      Technical Manual / Security Guide Change Pages - PSJ*5*134    2008-08-26      2008-08-26
3471      Technical Manual / Security Guide Change Pages - PSJ*5*178    2007-02-13      2007-02-13
3472      Technical Manual / Security Guide Change Pages - PSJ*5*181    2011-04-20      2011-04-20
3473      Technical Manual / Security Guide Change Pages - PSJ*5*214    2010-02-23      2010-02-23
3474      Technical Manual / Security Guide Change Pages - PSJ*5*222    2010-02-05      2010-02-05
3475      Technical Manual / Security Guide Change Pages - PSJ*5*226    2011-03-14      2011-03-14
3476      Version 5.0 Release Notes     1997-12-01      1998-12-31
3477
3478   3.1.64 Pharmacy: National Drug File
3479   The National Drug File (NDF) V. 4.0 software module provides standardization of the local drug files in all
3480   Department of Veterans Affairs Medical Centers (VAMCs). Standardization includes the adoption of new drug
3481   nomenclature and drug classification, and links the local drug file entries to data in the National Drug files.
3482
3483   For drugs approved by the Food and Drug Administration (FDA), VAMCs have access to information concerning
3484   dosage form, strength and unit; package size and type; manufacturer’s trade name; and National Drug Code (NDC).
3485   The NDF software lays the foundation for sharing prescription information among VAMCs.
3486
3487   With this version of NDF, a new design of the NATIONAL DRUG file (#50.6) will lay the foundation for timely data
3488   releases by Pharmacy Benefits Management (PBM) personnel to field facilities using the NDF Management System.
3489   As new drug products are released, this information can be quickly sent to facilities. Pharmacy end users will be able
3490   to match (classify) a greater percentage of their local drug files for new products. Update/delivery of data will be
3491   controlled by PBM personnel. Frequent updating of NDF will be possible with minimal time for installation and
3492   downtime.
3493
3494   In addition to the redesign of NATIONAL DRUG file (#50.6), Version 4.0 will provide the following enhancements:
3495   • Addition of new fields to NDF, such as National Formulary and restriction indicators.
3496   • Lay foundation for interfaces to other Commercial Off The Shelf (COTS) software to update NDF fields for
3497        new/revised drug information.
3498   • Update current NDF with new/revised product information.
3499   • Creation of an Application Programmer’s Interface (API) to accommodate all existing VISTA software Database
3500        Integration Agreements (DBIAs) with NDF.
3501   • A clean-up of associated files, such as DRUG MANUFACTURER (#55.95), DRUG UNITS (#50.607), etc.
3502   • Incorporation of approved enhancement requests by Pharmacy/ Information Resources Management (IRM) end
3503        users.
3504
3505   Features:
3506   National Drug File:
3507   • Standardizes drug file information.



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
3508   •   Standardizes drug classifications.
3509   •   Adopts standard nomenclature.
3510   •   Provides up-to-date prescription and over-the-counter information.
3511   •   Provides available sources for drugs manufactured and approved by the FDA.
3512   •   Provides a base for implementation of drug inventory control and management throughout VA (i.e., Consolidated
3513       Mail Outpatient Pharmacy and Pharmacy Benefits Management).
3514   •   Allows file access by NDC, manufacturer’s trade name, ingredient, dosage form, dosage strength, route of
3515       administration, and VA drug classification.
3516   •   Allows management of drug information, including reports on drugs by classification, ingredient, NDC, trade
3517       name, and/or active/inactive status.
3518   •   Matches additions to medical center drug files with the national drug database.
3519   •   Provides an ingredient file that is an integral component of the Allergy Tracking and Outpatient Pharmacy (drug-
3520       drug interactions) modules.
3521   •   Provides an enhanced formulary report listing local, VISN, and National Formulary information.
3522   •   Includes the Patient Medication Information Sheets that feature the following:
3523             o An explanation of how and why to take a medication and the possible side effects.
3524             o Information supplied by commercial sources.
3525             o Information that is copyrighted and periodically updated.
3526   •   Utilizes data provided and standardized by First DataBank for point of sale electronic billing using Electronic
3527       Claims Management Engine (ECME).




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
3528
3529                                                       Figure: 3.1-85
3530
3531   3.1.65 Pharmacy: Outpatient Pharmacy
3532   The Outpatient Pharmacy (OP) software provides a way to manage the medication regimen of veterans seen in the
3533   outpatient clinics and to monitor and manage the workload and costs in the Outpatient Pharmacy. The Pharmacy
3534   Ordering Enhancements (POE) project (patch PSO*7*46 for Outpatient Pharmacy) improves the flow of orders
3535   between Inpatient and Outpatient Pharmacy as well as between Computerized Patient Record System (CPRS) and
3536   backdoor pharmacy.
3537
3538   The primary benefits to the veteran are the assurance that he or she is receiving the proper medication and the
3539   convenience of obtaining refills easily. The clinicians and pharmacists responsible for patient care benefit from a
3540   complete, accurate, and current medication profile available at any time to permit professional evaluation of treatment


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3541   plans. Utilization, cost, and workload reports provide management cost controlling tools while maintaining the highest
3542   level of patient care.
3543
3544   The Outpatient Pharmacy V. 7.0 package:
3545   • Provides a method for managing the medications given to veterans who have visited a clinic or who have
3546       received prescriptions upon discharge from the hospital.
3547   • Automatically generates prescription labels, and prints refill request forms.
3548   • Medication histories are kept online to permit checks for potential interactions.
3549   • Profiles can be generated to assist the clinician in managing the patient's medication regimen.
3550   • Management reports aid the pharmacy in controlling inventory and costs.
3551
3552   A number of site parameters allow the individual Department of Veterans Affairs Medical Center (VAMC) to
3553   customize the package to meet local needs.
3554
3555   Features:
3556   Outpatient Pharmacy package:
3557   • Checks new prescriptions against existing prescriptions (for the same medication, therapeutic class, reported
3558       allergies, reactions, or drug interactions).
3559   • Allows pharmacists to verify data entered by technicians prior to the printing of labels.
3560   • Allows for the renewal of prescriptions that have no remaining refills. Prints labels for new,
3561   • Auto-cancels individual prescriptions for a patient after admission for inpatient treatment.
3562   • Creates medication profiles for patient charts to meet the Joint Commission on Accreditation of Healthcare
3563       Organizations (JCAHO) requirements for a current medication list. Profiles are suitable for counseling patients.
3564   • Allows the Action Profile to be used as a quick renew/cancel request form by clinic providers, which allows for
3565       rapid entry of request by Pharmacy staff.
3566   • Provides the Screen Profile for review at several points in the order/entry process.
3567   • Provides basic Drug Use Evaluation (DUE) template generator.
3568   • Provides necessary laboratory checks and reports to meet national requirements for Clozapine dispensing.
3569   • Provides finishing of orders entered through CPRS.
3570   • Provides information for billing any applicable medication co-payment when the prescription is released.
3571   • Allows the user to select a different action without leaving an option.
3572   • Uses List Manager features to allow:
3573            o Pharmacist or technician to browse through a list of actions.
3574            o Pharmacist or technician to take action against those items.
3575            o User to select an action that displays an action or informational profile.
3576    Works with Integrated Billing (IB) and Electronic Claims Management Engine (ECME) to enable and manage
3577       point of sale billing supporting the Healthcare Insurance Portability and Accountability Act (HIPAA) Electronic
3578       Claims and Code set congressional mandate.
3579    Allows prescription labels and Prescription Medication Information (PMI) sheets to be printed in another
3580       language if the system has the other language fields populated in Pharmacy Data Management and the
3581       individual patient is identified with the other language preference flag.
3582    Allows the ability to print a microchip-embedded label for a prescription. This label can then be read by
3583       ScripTalk®, thus improving patient safety for visually impaired veterans.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
3584      Provides display of Herbal, over the counter (OTC), and Non-VA medications documented through CPRS. The
3585       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-1
www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
3587                                                   Figure: 3.1-86
3588
3589   Documents available in the vdl:
3590   (http://www.va.gov/vdl/application.asp?appid=90)
3591   Name Date Created Last Updated
3592       API Manual - Pharmacy Reengineering (PRE) 2011-04-28               2011-04-28
3593       Implementation Guide - Medication Reconciliation Tools 2008-06-11          2008-07-02
3594       Installation Guide - Automation Interface 2004-10-01       2004-10-15
3595       Installation Guide - Medication Reconciliation—Medication Worksheet (Tool #2)      2011-04-28      2011-
3596        04-28
3597       Installation Guide - Pharmacy Ordering Enhancements (POE) Phase 2          2001-09-01      2001-09-01
3598       Installation Guide - ScripTalk Talking Prescription Labels 2003-11-01      2003-10-29
3599       Installation Guide- MOCHA v1.0 Combined Build (PSS*1*117, PSO*7*251, PSJ*5*181, OR*3*272, PSO*7*375,
3600        PSS*1*163) REVISED               2011-08-12        2011-08-12
3601       Installation Guide-FDA Medication Guides Project (PSS*1*158, PSN*4*263 and PSO*7*343) 2011-04-20
3602             2011-04-20
3603       Release Notes (PBM Demographics Enhancements)              2009-07-21      2009-07-21
3604       Release Notes - Outpatient Pharmacy Version 7.0            1997-12-01      1997-12-15
3605       Release Notes - Automation Interface 2004-10-01            2004-10-15
3606       Release Notes - Bad Address Enhancements (PSO*7*233)               2006-10-06      2006-10-06
3607       Release Notes - Clinical Indicator Data Capture 2005-08-01         2005-08-31
3608       Release Notes - Combat Veteran Phase II            2004-05-01      2004-05-07
3609       Release Notes - CPRS V27 Project          2008-08-26       2008-08-26
3610       Release Notes - ePharmacy II (PSO*7*281)           2008-04-16      2008-04-16
3611       Release Notes - ePharmacy Phase 4 COB (PSO*7*290) 2011-02-04               2011-02-04
3612       Release Notes - ePharmacy Phase 4 Iteration II (PSO*7*289)         2009-07-16      2009-07-16
3613       Release Notes - FDA Regulatory Changes for Clozapine 2006-10-06            2006-10-06
3614       Release Notes - FY07 Q1 (PSO*7*258, PSO*7*250)             2006-12-21      2006-12-21
3615       Release Notes - FY07 Q2 (PSO*7*200, PSS*1*122)             2007-04-16      2007-04-16
3616       Release Notes - FY07 Q3 (PSO*7*268) 2007-07-19             2007-07-19
3617       Release Notes - FY07 Q4 (PSO*7*264) 2007-10-24             2007-10-24
3618       Release Notes - Herbal/OTC/Non-VA Meds Documentation               2004-05-01      2004-05-03
3619       Release Notes - HIPAA NCPDP Connection for EDI Pharmacy            2006-04-01      2006-03-30
3620       Release Notes - Laser Printed Prescription Labels Phase II         2005-03-01      2005-03-31
3621       Release Notes - Laser Printed Rx Labels with PMI Sheets Phase I 2003-04-01         2003-04-30
3622       Release Notes - Outpatient Medication Copay (PSO*7*71) 2001-11-01          2001-11-26
3623       Release Notes - PFSS (PSO*7*201)          2006-10-19       2006-10-19
3624       Release Notes - Pharmacy Ordering Enhancements (POE)               2001-09-01      2001-09-24
3625       Release Notes - PLQE FY09 Q2 (PSO*7*320) 2009-08-07                2009-08-07
3626       Release Notes - Remote Data Interoperability (RDI) Project         2005-12-01      2005-12-22
3627       Release Notes - Tricare (dormant) Release (PSO*7*287) 2008-09-18           2008-09-18
3628       Release Notes - Tricare Active Duty Release (PSO*7*358) 2010-12-17         2010-12-17
3629       Release Notes - Tricare Release (PSO*7*303) 2008-12-04             2008-12-04
3630       Release Notes and Installation Guide - AudioCARE Renewal (PSO*7*328) 2010-07-21            2011-01-10



       www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap        Page 3-1
3631      Release Notes and Installation Guide - Pharmacy Ordering Enhancements (POE) Phase 1     2000-10-01
3632           2000-10-01
3633      Release Notes- Medication Order Check Healthcare Application (MOCHA) v1.0       2011-04-20      2011-
3634       04-20
3635      Release Notes-FDA Medication Guides Project (PSS*1*158, PSN*4*263 and PSO*7*343)        2011-04-20
3636           2011-04-20
3637      Technical Manual/Security Guide - Outpatient Pharmacy V.7.0     2011-04-20      2011-04-20
3638      Technical Manual/Security Guide Change Pages (PSO*7*225)        2008-08-25      2008-08-25
3639      Technical Manual/Security Guide Change Pages (PSO*7*251)        2011-04-20      2011-04-20
3640      Technical Manual/Security Guide Change Pages (PSO*7*279)        2008-07-09      2008-07-09
3641      Technical Manual/Security Guide Change Pages (PSO*7*288)        2008-06-23      2008-06-23
3642      Technical Manual/Security Guide Change Pages (PSO*7*289)        2009-07-16      2009-07-16
3643      Technical Manual/Security Guide Change Pages (PSO*7*294)        2008-06-11      2008-06-11
3644      Technical Manual/Security Guide Change Pages (PSO*7*305)        2009-06-03      2009-06-03
3645      Technical Manual/Security Guide Change Pages (PSO*7*316, PSO*7*343) 2011-04-20          2011-04-20
3646      Technical Manual/Security Guide Change Pages (PSO*7*320)        2009-08-07      2009-08-07
3647      Technical Manual/Security Guide Change Pages (PSO*7*326)        2009-11-23      2009-11-23
3648      Technical Manual/Security Guide Change Pages (PSO*7*348)        2010-07-15      2010-07-15
3649      Technical Manual/Security Guide Change Pages (PSO*7*358)        2010-12-17      2010-12-17
3650      User Manual - Manager - Outpatient Pharmacy V.7.0       2011-04-20      2011-04-20
3651      User Manual - Manager Change Pages (PSO*7*289)          2009-07-16      2009-07-16
3652      User Manual - Manager Change Pages (PSO*7*225)          2008-08-25      2008-08-25
3653      User Manual - Manager Change Pages (PSO*7*251)          2011-04-20      2011-04-20
3654      User Manual - Manager Change Pages (PSO*7*281)          2008-04-16      2008-04-16
3655      User Manual - Manager Change Pages (PSO*7*288)          2008-06-23      2008-06-23
3656      User Manual - Manager Change Pages (PSO*7*290)          2011-02-04      2011-02-04
3657      User Manual - Manager Change Pages (PSO*7*294)          2008-06-11      2008-06-11
3658      User Manual - Manager Change Pages (PSO*7*303)          2008-12-04      2008-12-04
3659      User Manual - Manager Change Pages (PSO*7*305)          2009-06-03      2009-06-03
3660      User Manual - Manager Change Pages (PSO*7*324)          2010-02-17      2010-02-17
3661      User Manual - Manager Change Pages (PSO*7*326)          2009-11-23      2009-11-23
3662      User Manual - Manager Change Pages (PSO*7*338)          2010-04-05      2010-04-05
3663      User Manual - Manager Change Pages (PSO*7*348)          2010-07-15      2010-07-15
3664      User Manual - Pharmacist - Outpatient Pharmacy V.7.0 2011-04-21         2011-04-21
3665      User Manual - Pharmacist Change Pages (PSO*7*225) 2008-08-25            2008-08-25
3666      User Manual - Pharmacist Change Pages (PSO*7*251) 2011-04-20            2011-04-20
3667      User Manual - Pharmacist Change Pages (PSO*7*289) 2009-07-16            2009-07-16
3668      User Manual - Pharmacist Change Pages (PSO*7*289) 2009-07-16            2009-07-16
3669      User Manual - Pharmacist Change Pages (PSO*7*290) 2011-02-04            2011-02-04
3670      User Manual - Pharmacist Change Pages (PSO*7*294) 2008-06-11            2008-06-11
3671      User Manual - Pharmacist Change Pages (PSO*7*303) 2008-12-04            2008-12-04
3672      User Manual - Pharmacist Change Pages (PSO*7*305) 2009-06-03            2009-06-03
3673      User Manual - Pharmacist Change Pages (PSO*7*324) 2010-02-17            2010-02-17
3674      User Manual - Pharmacist Change Pages (PSO*7*326) 2009-11-23            2009-11-23



       www.oserha.org                                OSEHR System-Architecture, Product Definition and Roadmap     Page 3-1
3675      User Manual - Pharmacist Change Pages (PSO*7*338) 2010-04-05               2010-04-05
3676      User Manual - Pharmacist Change Pages (PSO*7*343) 2011-04-20               2011-04-20
3677      User Manual - Supplemental - Outpatient Pharmacy V.7.0 2010-04-05          2010-04-05
3678      User Manual - Supplemental Change Pages (PSO*7*305) 2009-06-03             2009-06-03
3679      User Manual - Supplemental Change Pages (PSO*7*338) 2010-04-05             2010-04-05
3680      User Manual - Technician - Outpatient Pharmacy V.7.0. 2011-04-20           2011-04-20
3681      User Manual - Technician Change Pages (PSO*7*225) 2008-08-25               2008-08-25
3682      User Manual - Technician Change Pages (PSO*7*251) 2011-04-20               2011-04-20
3683      User Manual - Technician Change Pages (PSO*7*289) 2009-07-16               2009-07-16
3684      User Manual - Technician Change Pages (PSO*7*303) 2008-12-04               2008-12-04
3685      User Manual - Technician Change Pages (PSO*7*305) 2009-06-03               2009-06-03
3686      User Manual - Technician Change Pages (PSO*7*326) 2009-11-23               2009-11-23
3687
3688
3689   Pharmacy: Outpatient Pharmacy - (Component diagram)
                         cmp Pharmacy: Outpatient Pharmacy



                               Outpatient Pharmacy



                                          «interface»
                                             PSO                          M Audiofax (Telephone
                                                                          Refill Requests)




3690
3691                                                     Figure: 3.1-87
3692
3693   3.1.66 PPP-Pharmacy: Pharmacy Prescription Practices
3694   DATE: March 2009
3695   SUBJECT: Retiring of PPP Application
3696
3697   The Pharmacy Prescription Practices (PPP) V. 1.0 application has been retired per PSI-07-114 as it does not provide
3698   the most recent and up-to-date data on prescriptions from other sites. PPP*1*43 has retired PPP, and PSO*7*300
3699   updated routines that referenced PPP.
3700
3701   All options within the PPP V. 1.0 application have been marked Out Of Order with the message OPTION RETIRED
3702   BY PATCH PPP*1*43 AS PER PSI-07-114.
3703




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
3704   Due to the retirement of PPP, all PPP documentation has been removed from the VistA Documentation Library
3705   (VDL).




3706                                                                                                          Figure: 3.1-88
3707
3708   3.1.67 PCMM-Primary Care Management Module
3709   The Primary Care Management Module was developed to assist VA facilities in implementing primary care. It will
3710   support both primary care teams and non-primary care teams. PCMM’s functionality is divided into eight areas.
3711   1. Setup & Define Team
3712   2. Assign Staff to Positions in Teams
3713   3. Assign Patient to Team
3714   4. Assign Patient to Practitioner via Team Position and Enroll in a Clinic
3715   5. Reports/Outputs/Mail Messages
3716   6. Tools to Ease Startup Process of Primary Care
3717   7. Other Changes to Scheduling Package
3718   8. Application Program Interface (API) calls
3719
3720   In the outpatient setting, patients are assigned a primary care team and provider who are responsible for delivering
3721   essential health care, coordinating all health care services, and serving as the point of access for specialty care.
3722   Associate Primary Care Providers (APs) provide primary care to patients under the supervision of the Primary Care
3723   Provider (PCP). PCMM supports both primary care and non-primary care teams. The software allows one to create,
3724   set up, and define teams; create and assign positions to the team; assign staff to the positions; assign patients to the
3725   team; and assign patients to providers’ positions.
3726
3727   In PCMM, primary care providers have an assigned “number of patients allowed” which is compared with the
3728   “number of patients actual” to determine if more patients may be assigned to the provider. PCMM functionality assists
3729   in maintaining accurate, active patient listings for primary care teams and panels. By unassigning patients who have
3730   not seen their primary care providers in a specified amount of time, new patients may be assigned. Unassigned
3731   patients are readily reassigned to their previous primary care team and provider if they return for care. When a
3732   patient cannot be assigned to a primary care team or position, the PCMM software asks if the patient should be



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3733   placed on the Electronic Wait List. PCMM Wait List reports assist in the management of patients awaiting a primary
3734   care team or provider assignment.
3735
3736   The amount of time the APs and PCPs spend providing direct primary care is also entered and measures the
3737   capacity of each institution (and VHA as a whole) to provide outpatient primary care. PCMM also screens staff
3738   assignments to PCP and AP positions to assure the data on providers is correct.
3739
3740   The primary care patient, provider, and team information captured in PCMM is sent to the Austin Information
3741   Technology Center (AITC) and the National Patient Care Database. Some PCMM information is available in the
3742   Kathy L. Frisbee (KLF) Reports. Additionally, the Office of Performance and Quality Measures utilizes PCMM data for
3743   national reporting and performance measures.
3744
3745   Features
3746   • Uses a graphical user interface (GUI) for creating teams and provider positions as well as assigning staff to the
3747       provider positions.
3748   • Ability to assign/unassign patients to primary care and non-primary care teams and providers both in GUI and
3749       VistA roll-and-scroll.
3750   • Automates patient unassignment from primary care teams and providers if the patient has not seen their primary
3751       care provider for a specified time or when a patient’s date of death is entered.
3752   • Screens assignments to PCP and AP positions based on provider type and person class.
3753   • Produces patient-oriented, practitioner-oriented, and team-oriented reports.
3754   • Transmits data for primary care teams, providers, and patients to Austin in Health Level Seven (HL7) message
3755       format and provides the ability to receive/process transmission errors.
3756   • Ability to control transmission of MailMan messages to team positions.




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
3757
3758                                                    Figure: 3.1-89
3759
3760   3.1.68 Prosthetics
3761   Purchasing - Stock Issues (SI)
3762   Prosthetics Sensory Aids Service (PSAS)
3763   National Prosthetics Patient Database (NPPD) Tools
3764   Home Oxygen Module
3765   Electronic Orders/ Suspense (SU)
3766   Prosthetics Inventory Package (PIP)
3767   Delayed Order Report (DOR)
3768   Prosthetics Billing Information
3769
3770   A common Prosthetic purchasing action is the Issue from Stock (IS) option. You can access this option from the
3771   Stock Issues (SI) Menu. The prompts you see when creating an Issue From Stock are recorded on the patient’s 10-
3772   2319 record like other purchasing transactions.
3773
3774   Prosthetics Basics User Manual is for new Prosthetics users of the Prosthetics Sensory Aids Service (PSAS) system
3775   including Purchasing Agents and any other new end user on the system.
3776




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap          Page 3-1
3777   The National Prosthetics Patient Database (NPPD) Tools Menu, a VISTA based program, is used to routinely view,
3778   analyze, and validate the medical center PSAS (Prosthetic Sensory Aids Service) patient transaction data that is
3779   eventually transmitted to the NPPD. The menu resides in VISTA at the medical center level.
3780
3781   The Administrative Home Oxygen Module is exclusively an administrative system. It provides for the recording of
3782   patient information for reporting and invoice billing which can be used as a check against bills received from the
3783   contractor for each patient. The module facilitates the coordination of services when contractors change at the end of
3784   a contract cycle. It also provides correspondence support to remind patients when they need to renew their Home
3785   Oxygen prescriptions.
3786
3787   The Administrative Home Oxygen module is mainly used to manage billing from the vendor, providing several
3788   benefits, including saving money by suspending erroneous charges and time by eliminating a manual review of the
3789   records. The module also provides information about the current prescription of the patient, and flags patients with
3790   special problems quickly.
3791
3792   Correspondence may be required by local VAMC Home Oxygen program policy. With this release, letters may be
3793   sent to patients when prescriptions are due to expire or when service is discontinued.
3794
3795   The purpose of the Electronic Order feature is to provide a method for any request for service or request for items in
3796   Prosthetics to be ordered electronically. Requests are made either manually through the Prosthetics system or sent
3797   electronically from CPRS (Computerized Patient Record System) via Consult Tracking.
3798
3799   Through the Suspense (SU) option, Prosthetic employees are able to post notes to consults, cancel and complete
3800   the consult. Reports are available to display open, pending, and completed consults.
3801
3802   The Prosthetics inventory software (also known as the Prosthetics Inventory Package or “PIP”) tracks quantities of
3803   prosthetic items located in the Prosthetics Sensory and AIDS Service (PSAS) inventory of each facility.
3804   The PIP system using bar coding provides the means to do the following:
3805   • Manages the inventory data using barcode scanner equipment
3806   • Provides for faster data entry with scanning information of labels
3807   • More accurate data entry with scanning of HCPCS Codes
3808   • Sends a mail message when stock is low
3809   • Automatically calculates stock quantities when stock is ordered or issued.
3810
3811   •   The Delayed Order Report (DOR) User Manual corresponds to Patch RMPR*3*59. This patch provides
3812       Prosthetics GUI (graphical user interface) windows for the Delayed Order Report (DOR) feature.
3813   •   Note: Using this feature requires basic MS Windows skills.
3814   •   The Prosthetics users will be able to do the following with this patch:
3815   •   Search for and display manual suspense entries/electronic consult (CPRS order) data by one or all sites.
3816   •   Display data using one or multiple statuses (Open, Pending, Cancelled or Closed).
3817   •   Use a starting date for Closed and Cancelled records to display data.
3818   •   Sort and rearrange the view; display data in a custom view.
3819   •   Print the display.
3820   •   Convert the display into a Microsoft Excel file (for more sorting capabilities).



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
3821
3822   Prosthetics Billing Information (Patch RMPR*3*96) provides Prosthetics GUI (graphical user interface) windows for
3823   the View Prosthetics Billing Information feature.




3824
3825                                                    Figure: 3.1-90




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap          Page 3-1
3826   Prosthetics - (Component diagram)
                                               cmp Prosthetics




                                                       Prosthetics


                                                         «interface»
                                                         Prosthetics



                                                                            NPPD




3827
3828                                                       Figure: 3.1-91
3829
3830   3.1.69 QUASAR-Quality: Audiology And Speech Analysis And Reporting
3831   Quality: Audiology and Speech Analysis and Reporting (QUASAR) is a VISTA software package written for the
3832   Audiology and Speech Pathology Service. QUASAR is used to enter, edit, and retrieve data for each episode of care.
3833   – QUASAR provides transmission of visit data to the Patient Care Encounter (PCE) program in order to
3834        incorporate QUASAR Visit Data in ACRP Workload Reporting, as well as to the Decision Support System (DSS).
3835   – QUASAR produces a variety of reports useful to local managers, medical center management, and central
3836        planners.
3837   – QUASAR contains a VA FileMan function that permits users to generate customized reports using data from
3838        QUASAR's A&SP Clinic Visit file (#509850.6) or A&SP Patient file (#509850.2).
3839   – QUASAR produces an automated Cost Distribution RCS 10-0141 Report (CDR) and has an option for
3840        generating and processing audiology compensation and pension examinations through an agreement with the
3841        Automated Medical Information Exchange (AMIE) package.




3842
3843                                                       Figure: 3.1-92



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap         Page 3-1
3844
3845   3.1.70 Radiology/ Nuclear Medicine
3846   The VistA Radiology / Nuclear Medicine package is a comprehensive software package, designed to assist with the
3847   functions related to processing patients for imaging examinations. The Radiology / Nuclear Medicine package
3848   automates the entire range of diagnostic functions performed in imaging departments, including request entries by
3849   clinical staff, registration of patients for exams, processing of exams, recording of reports/results, verification of
3850   reports on-line, displaying/printing results for clinical staff, automatic tracking of requests/exams/reports, and
3851   generation of management statistics/reports, both recurring and ad hoc. The Radiology / Nuclear Medicine package
3852   automates many tedious tasks previously performed manually, providing faster, more efficient and accurate data
3853   entry and more timely results reporting.
3854
3855   The package is interfaced with VistA Record Tracking software for the purpose of tracking radiology and nuclear
3856   medicine records and creating pull lists for those records needed for scheduled clinic appointments. The VistA
3857   Radiology / Nuclear Medicine package is fully integrated with VA FileMan and provides certain patient demographic
3858   information supplied by the Patient Information Management System (PIMS), formerly the Medical Administration
3859   Service (MAS) package. It also interacts with other VistA packages to allow personnel to see patient medication
3860   histories, contrast media reactions, and laboratory test results which may influence the nature of an examination.
3861   Request entry has been incorporated in two ways: functionality within this package and an interface with the CPRS
3862   package, allowing on-line requesting of exams and viewing of reports. Information regarding each examination is
3863   stored by the system and may be compiled to produce a variety of reports necessary in carrying out daily business
3864   and for use by management in analyzing the workload. Information required to generate a variety of workload reports
3865   and resource allocation reports is also collected.
3866
3867   The VistA Radiology / Nuclear Medicine package supports the HL7 protocol. This allows the exchange of information
3868   concerning exam registration, cancellation, completion, and results (specifically reports and impressions) between
3869   the VistA system and clients within or outside of VistA.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
3870
3871                                 Figure: 3.1-93
3872
3873   Radiology/ Nuclear Medicine




       www.oserha.org                OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
        cmp Radiology/ Nuclear Medicine



              Radiology/Nuclear Medicine




                         «interface»
                 Radiology/Nuclear Medicine
                                               PowerScribe for Radiology


                                               IBM MedSpeak



                                              TalkStation



3874
3875   Figure: 3.1-94
3876
3877   3.1.71 RAI/MDS-Resident Assessment Instrument/ Minimum Data Set
3878   The RAI/MDS implementation is a national project for the VA. One of the many purposes of this project is to provide
3879   computerized storage, access, and analysis of the MDS 2.0 long-term care data on patients in nursing homes across
3880   Veterans Affairs medical centers (VAMCs). The MDS system is intended to create a standard, nationwide system for
3881   connecting VAMCs with nursing home facilities to the Austin Automation Center (AAC) for the purpose of electronic
3882   interchange of data, reports, and other information. The MDS transmission system provides the following functions:
3883    Receipt of MDS records from the AAC by VAMCs.
3884    Authentication and validation of MDS records received from VAMC facilities.
3885    Feedback to VAMCs indicating acknowledgment of the transmission of the data and specifying the status of
3886        record validation.
3887    Storage of MDS records in the database repository at the AAC.
3888    Will replace PAI and provide RUG III codes to the ARC (Allocation Resource Center).
3889
3890   At each VAMC, the user will use the RAI/MDS program to electronically send MDS data records to the AAC over the
3891   VA intranet. Once minimal file checks are completed, a message is sent back to the VAMC indicating whether the file
3892   (referred to as batch submission) has been received successfully or rejected.
3893
3894   The user remains on-line to ensure the submission has been accepted. If the submission passes the initial validation
3895   check, then each record is checked for errors or exceptions to the data specifications and a Final Validation Report is
3896   generated.




       www.oserha.org                                          OSEHR System-Architecture, Product Definition and Roadmap         Page 3-1
3897
3898                                                       Figure: 3.1-95
3899
3900   RAI/MDS-Resident Assessment Instrument/ Minimum Data Set - (Component diagram)
3901
                                             cmp RAI/MDS-Resident Assessment Instru...



                                                      RAI/MDS



                                                       «interface»
                                                        RAI/MDS

                                                                              VA Intranet




3902
3903                                                       Figure: 3.1-96
3904
3905   3.1.72 ROES-Remote Order Entry System
3906   The Remote Order Entry System (ROES) gives authorized end users at VHA facilities the ability to order products
3907   and services from the VA Denver Distribution Center (DDC).




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap      Page 3-1
3908
3909                                                          Figure: 3.1-97
3910
3911   ROES-Remote Order Entry System - (Component diagram)
                                                  cmp ROES-Remote Order Entry System



                                                                ROES




                                                                  «interface»
                                                                    ROES
                                                                                  Browser




3912
3913                                                          Figure: 3.1-98
3914
3915   3.1.73 Scheduling
3916   The Scheduling module automates all aspects of the outpatient appointment process, including the ability to check
3917   in/check out patients, clinic set-up and maintenance, enrollment/scheduling/discharge of patients to and from various
3918   clinics, and the generation of managerial reports, statistical reports, patient letters, and workload reporting. It provides
3919   for multiple-appointment booking, which enables the user to schedule, at one time, numerous appointments on a
3920   consecutive day/week basis. This pattern of scheduling supports requirements for clinics such as dialysis treatment
3921   and physical therapy.
3922
3923   The system may display numerous messages when an appointment is scheduled depending on the availability of the
3924   slot requested. These include notification that the appointment is an overbook, the patient already has an
3925   appointment scheduled for that date and time, or the appointment cannot be made due to previous inactivation of the
3926   designated clinic. In addition, certain classification questions are prompted during the check out process (if
3927   applicable) to determine if treatment rendered was connected to special circumstances (such as Agent Orange,
3928   Ionizing Radiation, Persian Gulf, etc.). If an appointment cannot be scheduled because of limitations, the user is
3929   prompted to add the appointment information to a Wait List for future scheduling.



       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap                Page 3-1
3930
3931   Patient Appointment Information gathers appointment data to be loaded into the National Database in Austin for
3932   statistical reporting. Patient appointments are scanned from September 1, 2002 to the present, and appointment data
3933   meeting specified criteria are transmitted to the Austin Information Technology Center (AITC). Subsequent
3934   transmissions will update the National Database. This additional data supplements the existing Clinic Appointment
3935   Wait Time extracts.
3936
3937   The functions within Scheduling currently fall into four major categories: Appointment Scheduling, Local Reporting
3938   (outputs), National Data Collection, and Module Set-Up and Maintenance.
3939
3940   Features
3941    Creates fixed or variable length clinic patterns.
3942    Provides on-line clinic availability and system identification of conditions such as first available appointment.
3943    Interacts with the Record Tracking module allowing chart request at the time of appointment scheduling.
3944    Generates cancellation, no-show, and pre-appointment letters.
3945    Provides on-line transmission of pertinent visit information to the national database at the AITC.
3946    Patient Appointment Information functionality collects and formats data for Health Level Seven (HL7) batch
3947       transmission. It also utilizes new hardware technologies for transmitting data via the VA’s Intranet.
3948




3949
3950                                                       Figure: 3.1-99
3951




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap         Page 3-1
3952   3.1.74 Shift Handoff Tool
3953   The Shift Handoff Tool is a utility that assists hospital staff going off shift to create a report for the incoming shift. This
3954   report contains demographic and medical information about each patient being handed off. At a minimum it shows
3955   medications and allergies, but can be customized to show other medical information that is relevant to the patient’s
3956   condition. Also referred to as the Physician Handoff Tool.
3957
3958   There has been a great deal of variability in Physician to Physician communication. This is recorded in the medical
3959   literature.
3960
3961   The design and development of the Physician Handoff Tool seeks to address the variability in Physician to Physician
3962   communication at Patient Handoff.
3963
3964   Data elements such as Demographics, Code Status, Allergies, Medications, Problem List, Admitting Diagnosis,
3965   Laboratory and Consults orders are some of the data elements communicated in a standardized way by this tool.
3966
3967   By providing a tool to do this, it is hoped that errors in care will be prevented because the information will be
3968   communicated in a clear, readable, standardized format.
3969
3970   A handoff report can be printed and carried with the physician during rounds. Notes can be written on the paper copy
3971   and re-entered into the Shift Handoff Tool for the providers on the next shift.




       www.oserha.org                                         OSEHR System-Architecture, Product Definition and Roadmap                  Page 3-1
3972
3973                                                      Figure: 3.1-100
3974
3975   3.1.75 Social Work
3976   Version 3.0 of the Social Work Information Management System is a case management system designed to facilitate
3977   the SOcial Work Service functions within the VA Medical Centers. This package contains DHCP computer programs
3978   which are used to track case loads and generate reports without unnecessary paper work. It can be used to
3979   anticipate a patient's domestic or social needs before being discharged, potentially minimizing the patient's hospital
3980   stay. AMIS data to Austin can now be transmitted electronically via VA MailMan system.
3981
3982   The Social Work software package is comprised of four modules. the modules and their functions are:
3983
3984   1. Case Management System. This is the primary menu for the case management. This is a sub-menu under the
3985   Social Work Information Management System (SWIMS) menu. The Case Management System menu contains some
3986   options that non-Social Work Chiefs/ Supervisors will not be able to access, such as High Risk, Automatic Reporting
3987   System, RCH Registry, and Social Work Personnel Information.
3988
3989   2. Clinical Assessment Module. This is the menu for the clinical summary information. It contains data base
3990   assessment profiles of patients, the ability to enter/ delete surrogate supervisors, and discharge planning and closing
3991   note information.
3992



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
3993   3. Community Resource Module. This menu allows you to enter/ edit and print community resource social work
3994   agency information.
3995
3996   4. Maintenance System. Most options under this menu are used for entering and maintaining various data elements
3997   for social work system definitions (i.e., site parameters). Other options are used to purge or re-initialize certain data
3998   elements, activate/ deactivate cost distribution centers, and enter/ edit new and old social workers and residential
3999   care homes.




4000
4001                                                         Figure: 3.1-101
4002
4003   Social Work - (Component diagram)
                                                cmp Social Work



                                                            Social Work



                                                                  «interface»
                                                                  Social Work



                                                                                VA Intranet



4004
4005                                                         Figure: 3.1-102
4006


       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
4007   3.1.76 Spinal Cord Dysfunction
4008   The Spinal Cord Dysfunction (SCD) package, a component of VistA, is a software product that permits the
4009   identification and tracking of patients with a spinal cord dysfunction due to trauma or disease and the medical
4010   resources utilized during their treatment. The programs and files support the of a local and national registry for
4011   patients with a spinal cord dysfunction. The package also provides clinical, administrative, and ad hoc reports for
4012   medical center use.
4013
4014   The SCD package accesses several other VistA files, which contain information concerning diagnosis, prescriptions,
4015   lab tests, radiology exams, hospital admissions, and clinic, visits. This allows your clinical staff to take advantage of
4016   the wealth of clinical data supported through VistA.
4017
4018   The SCD package accomplishes the following:
4019
4020   Uploads patient data to the National SCD Registry. The National Registry is used to provide VA-wide review of
4021   patient demographics, clinical aspects of disease, and resource utilization involved in providing care to patients.
4022
4023   Provides a variety of management reports for local use, including aggregate statistical reports by care type, patients
4024   lost to follow-up, frequency of visits, and volume of lab tests and prescriptions per patient.
4025
4026   The ad hoc reporting capability provides the users with the ability to design their own custom reports.
4027
4028   Several functional measures/scales are provided with the package (CHART, FAM, DIENER, DUSOI) in addition to
4029   the FIM and the Self Report of Function. For multiple sclerosis patients, two measures/scales are available (the
4030   KURTZKE and the EDSS). Each of these scales/measures allows patient progress to be tracked over time.
4031
4032   Functional Description
4033    Allows efficient entry of data into the local registry and outcome modules.
4034    Provides a watch list of those patients currently not being seen at the medical center.
4035    Tracks the utilization of resources used during treatment.
4036    Extracts data on outpatient visits, inpatient activity, drugs, radiology, and lab tests specified by the SCD Expert
4037      Panel (EP) and the SCD Advisory Board.
4038    Transports local data to the National SCD database at Austin, Texas.
4039




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-1
4040
4041                                                        Figure: 3.1-103
4042
4043   Spinal Cord Dysfunction - (Component diagram)
                                           cmp Spinal Cord Dysfunction



                                               Spinal Cord Dysfunction



                                                       «interface»
                                                       Spinal Cord        National Registry
                                                       Dysfunction

                                                                              HL7




4044
4045                                                        Figure: 3.1-104
4046
4047   3.1.77 STS-Standards & Terminology Services
4048   Standards & Terminology Services (STS) is responsible for organizing, formalizing, and maintaining the terminology
4049   of the Veterans Health Administration (VHA). Currently, terminology is used in the Department of Veterans Affairs
4050   (VA) Electronic Medical Record (EMR) system known as Veterans Health Information System and Technology



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap       Page 3-1
4051   Architecture (VistA). There are many implementations of VistA throughout the world. Each implementation has its
4052   own set of reference files that support clinical care of veterans. This reference information is non-uniform and can
4053   create a lot of confusion when comparing a patient’s medical record from one site to another. STS is making these
4054   files uniform throughout the enterprise, and is facilitating semantic and computational interoperability.
4055
4056   The processes of standardizing the terminology lead to the creation of the VHA Terminology (VHAT). VHAT
4057   encompasses reference information for many clinical domains including Vital Signs, Allergy, Text Integration
4058   Utility (TIU) document titles, Immunizations, and Medication Routes of administration. STS maintains VHAT
4059   through ongoing evaluation of feedback from domain experts. STS also sends regular updates to each VistA
4060   system.
4061
4062   Standards & Terminology Services (STS) is the authoritative source for clinical and administrative data standards for
4063   the Veterans Health Administration.
4064
4065   Standards & Terminology Services (STS) VA Enterprise Terminology Service Version 10 User Interface (UI) includes
4066   workflows that have systematic instructions for authoring and deploying terminology content. The manual is for users
4067   of the VA Enterprise Terminology Services (VETS) who perform the following tasks:
4068   – Author Content
4069   – Review and update functions performed by Domain Reviewers
4070   – Deployment functions performed by Testing Coordinators and other authorized Deployers
4071
4072   VETS is a suite of products that deliver standardized terminology content for use across the VA enterprise; including
4073   VistA and Clinical Data Repository/ Health Data Repository (CHDR).
4074        – The database used to house the terminology content served by VETS is the VA Terminology Server (VTS).
4075        – VETS includes three types of terminology content, all are viewable in the Terminology Browser:
4076                – VHA Terminology (VHAT): a standardized terminology created and maintained for VA applications.
4077                      It contains concepts that are unique to the VA as well as concepts that have been derived from
4078                      authoritative sources such as Systematized Nomenclature of Medicine, Clinical Terms (SNOMED
4079                      CT) or International Classification of Diseases, Clinical Modification (ICD-9-CM).
4080                – Standard Code Systems (SCS): data retrieved from Standard Development Organizations that are
4081                      authoritative sources.
4082                – Map Sets: links between terminologies to support VA business needs. Map Sets may be created
4083                      internally, adopted from a standard, or from another entity.
4084   • Terminology Deployment Services (TDS) is the tool used by STS to manage and deploy VETS content.
4085   • 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-1
4086
4087                                                      Figure: 3.1-105
4088
4089   3.1.78 Data Standardization
4090   Standard reference terminology is critical to the Department of Veterans Affairs’ (VA) plan to share computable and
4091   interoperable health information across VA and with non-VA partners. Standardized terminology will enable all sites
4092   in the VA health system to speak the same language, and will ensure that data not only crosses from system to
4093   system, but retains the same meaning. The data will also be computable within the Department of Defense (DoD),
4094   should the patient seek treatment at one of their facilities. When data is computable and interoperable, it is not only
4095   viewable from other sites, but functions seamlessly in automated processes such as drug-drug and drug-allergy order
4096   checks and other clinical decision support.
4097
4098   Efforts are underway to include other health care partners, including participation in the National Health Information
4099   Network. Access to complete and accurate health information for a veteran at any site supports patient safety, and
4100   enables informed clinical decision-making, personalized patient care, and improved population health.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
         class Data Standardization

             Name:      Data Standardization
             Package:   Data Standardization
             Version:   Oct 2011                         Data Standardization
             Author:    OSEHRA




                                   PDM v1.0                       Rad/Nuc Med               Clinical
                                                                  v5.0                      Reminders v2.0




                                   PDM                 Radiology/ Nuclear Medicine             CPRS: CR




4101                                                                                                                Figure:
4102                                                          3.1-106
4103
4104   3.1.79 Terminology Services
4105   The foundation of STS’s terminology services is the Terminology Model. The model conceptually defines each
4106   standard term in a clear and unique way by describing the properties, attributes, designations, and relationships for
4107   each standard concept. Modeling the terminology in this way and maintaining the model over time adds clarity and
4108   richness to the standards, and is a distinct advantage over merely providing lists of approved terms.
4109
4110   Standards & Terminology Services is also responsible for the deployment of standard terms across the enterprise.
4111   The deployment service establishes and maintains consistent standard reference files across all VistA databases.
4112   The standardization process remains responsive to the needs of end users and patients through the New Term
4113   Rapid Turnaround (NTRT) process, which allows new terms to be requested from the field. After clinical terminology
4114   requests are approved by domain-specific teams of subject matter experts, new terms are deployed to all VistA
4115   databases. Similarly, the NTRT process is used to inactivate terms which are not longer part of the standard. This
4116   prevents end users from continuing to select inactivated terms, while maintaining the historical accuracy of the
4117   patient record.
4118
4119   Administrative data is standardized via deployment of standard reference tables. This includes data sets such as
4120   demographics, zip codes, area codes, religions, and eligibility status. Standards & Terminology Services also utilizes
4121   standards from external Standards Development Organizations (SDOs), such as Systematized Nomenclature of
4122   Medicine – Clinical Terminology (SNOMED CT®), International Classification of Diseases – 9th edition – Clinical
4123   Modification (ICD-9-CM), Current Procedural Terminology (CPT), and other code sets. These are kept up-to-date by
4124   the Lexicon described in more detail below. STS also provides terminology mediation for cross agency
4125   interoperability efforts, such as the Clinical/Health Data Repository (CHDR) and Laboratory Data Sharing Initiative
4126   (LDSI) projects with DoD.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
                 class Terminology Serv ices

                    Name:      Terminology Services
                    Package:   Terminology Services                Terminology Serv ices
                    Version:   Oct 2011
                    Author:    OSEHRA




                                                ICD-9-CM                                             CPT




4127
4128                                                       Figure: 3.1-107
4129
4130   3.1.80 Surgery
4131   The Surgery package is designed to be used by Surgeons, Surgical Residents, Anesthetists, Operating Room
4132   Nurses and other surgical staff. The Surgery package is part of the patient information system that stores data on the
4133   Department of Veterans Affairs (VA) patients who have, or are about to undergo, surgical procedures. This package
4134   integrates booking, clinical, and patient data to provide a variety of administrative and clinical reports.
4135
4136   Features:
4137   Surgery package:
4138   • Allows a surgeon to generate requests for surgical procedures.
4139   • Allows operating room scheduling managers to assign operating rooms and time slots and generates operating
4140       room schedules.
4141   • Allows for the rescheduling or cancellation of operative procedures.
4142   • Facilitates entry of information specific to an individual surgical case (e.g., staff, times, diagnoses, complications,
4143       anesthesia).
4144   • Provides for on-line entry of data inside the operating room during the actual operative procedure.
4145   • Generates patient records and nurse reports.
4146   • Produces management reports (e.g., Annual Report of Surgical Procedures, Attending Surgeons Report, Nurse
4147       Staffing Report, and Anesthesia Management).
4148   • Produces quarterly and annual reports for VA Central Office.
4149   • Provides secured access to lists of cancellations and the Morbidity and Mortality Report.
4150   • Extracts data necessary to monitor risk management issues.
4151   • Provides additional checks for Transfusion Error Risk Management.
4152   • Includes a generic Health Level Seven (HL7) interface for use with commercial Automated Anesthesia
4153       Information Systems.
4154   • Includes an interface to the Patient Care Encounters (PCE) software that allows ambulatory procedure workload
4155       information to be transmitted to the National Patient Care Database (NPCD) at Austin.
4156   • Allows for on-line electronic signature of the Nurse Intraoperative Report and the Anesthesia Report.
4157
4158   Surgery: Risk Assessment
4159


       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-1
4160   The Risk Assessment module of the Surgery software provides medical facilities a mechanism to track information
4161   relating to both surgical risk and operative mortality. This information, once downloaded to the VA national database,
4162   supports a program of total quality improvement in Surgery in VHA.
4163
4164   The National Surgical Quality Improvement Program (NSQIP) was established to develop distributions of observed-
4165   to-expected (O/E) mortality and morbidity ratios (risk-adjusted outcomes) across facilities for all operations, for eight
4166   major sub-specialties, and for cardiac surgery. At each of VA’s medical facilities performing surgery, a Surgical
4167   Clinical Nurse Reviewer, under the direction of the Chief of Surgery, collects risk and outcome data. All patients
4168   undergoing major surgery requiring general, spinal, or epidural anesthesia are assessed. Completed non-cardiac
4169   assessments are electronically transmitted to the Hines, IL Center for Cooperative Studies in Health Services
4170   (CCSHS), while cardiac assessments are transmitted to the Denver Cardiac Coordinating Center for data analysis.
4171
4172   At these centers, models are continually developed and enhanced for the major surgical subspecialties and
4173   procedure-specific cardiac surgeries. Managerial reports are prepared at the coordinating centers to provide Chiefs
4174   of Surgery with their own risk-adjusted data compared to the VA national averages.
4175
4176   Features:
4177   Risk Assessment module:
4178   • Provides for entry of non-cardiac assessment information including pre-operative information, laboratory test
4179       results, operation information, and intraoperative and post-operative occurrences.
4180   • Provides for entry of cardiac assessment information, including clinical information, cardiac catheterization and
4181       angiographic data, operative risk summary data, cardiac procedures requiring cardio-pulmonary bypass, and
4182       intraoperative and post-operative occurrences.
4183   • Creates a Surgery Risk Assessment report on each patient assessed.
4184   • Transmits completed Surgery Risk Assessments to Hines CCSHS and Denver Cardiac Coordinating Center.
4185   • Lists Surgery Risk Assessments by categories, including complete, incomplete, and transmitted assessments,
4186       as well as lists of major surgical cases and all surgical cases.
4187   • Generates a monthly Surgical Case Workload Report.
4188   • Prints follow-up letters to patients 30 days after a procedure.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-1
4189
4190                    Figure: 3.1-108
4191




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
4192   Surgery - (Component diagram)
                      cmp Surgery

                                       Surgery




                                         «interface»
                                             SR                         Automated Anesthesia System
                                                                        via HL7




4193
4194                                                      Figure: 3.1-109
4195
4196   3.1.81 TBI-Traumatic Brain Injury
4197   There are no documents for this application at this point. (As of: 30 October 2009)




4198
4199                                                      Figure: 3.1-110
4200
4201   3.1.82 Virtual Patient Record
4202   There are no documents for this application at this point. (As of: 30 October 2009)




4203
4204                                                      Figure: 3.1-111
4205



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
4206   3.1.83 VistA Imaging System
4207   The VistA Imaging System is an extension to the VistA hospital information system that captures clinical images,
4208   scanned documents, motion images, and other non-textual data files and makes them part of the patient's electronic
4209   medical record. Electrocardiogram (EKG) waveforms can be displayed as part of the electronic medical record.
4210   Image and text data are provided in an integrated manner that facilitates the clinician's task of correlating the data
4211   and making patient care decisions in a timely, accurate way.
4212
4213   The system is designed to provide the treating physician with a complete view of patient data and, at the same time,
4214   allow consulting physicians to have access to the image and text data. It serves as a tool to aid communication and
4215   consultation among physicians -- whether in the same department, in different medical services, or at different sites.
4216
4217   The VistA Imaging System is unique in that management of the medical images is handled by the hospital
4218   information system, allowing very close integration of multimedia data with traditional patient chart information.
4219
4220   Clinical users can capture images during procedures or images can be added at a later time, for example during the
4221   creation of a report or progress note. Automatic image acquisition can be performed by DICOM gateways. Images
4222   can be acquired from commercial radiology Picture Archiving and Communications Systems (PACS) or directly from
4223   radiology devices. The transfer of patient demographic and order information to the commercial PACS or radiology
4224   device plays a key role in the ability to add these images to the patient’s online medical record.
4225
4226   VistA Imaging workstations located throughout the hospital capture and display a wide variety of medical images
4227   including:
4228   • Cardiology
4229   • Endoscopy (GI, pulmonary, cystoscopy, arthroscopy, bronchoscopy, etc)
4230   • Ultrasound (vascular, echo cardiology)
4231   • Microscopic (Surgical Pathology, Cytology, Autopsy, Hematology)
4232   • Surgery
4233   • Ophthalmology
4234   • Dental
4235   • Dermatology
4236   • Radiology images
4237   • Nursing
4238   • Podiatry
4239   • Scanned advanced directives, consent forms, and other documents
4240
4241   VistA Imaging VistARad diagnostic workstations are generally located in the Radiology Reading room and are used
4242   for softcopy reading of Radiology images. These workstations provide functions for the Radiologist to retrieve and
4243   display full-resolution images, associated Radiology reports, and update the Radiology exam status.
4244
4245   VistA Imaging is made up of the following components:
4246   • Core Infrastructure
4247   • Document and Ancillary Imaging
4248   • Film less Radiology
4249   • Telemedicine



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
4250
4251   Features:
4252   • Provides capture, display, manipulation, and management functions for a wide variety of medical images such
4253       as radiographs, sonograms, EKG tracings, gastroenterology studies, pulmonary bronchoscope exams, podiatry,
4254       dermatology, and ophthalmology images. VistA Imaging can store and display any sort of multimedia data,
4255       including digital images, motion video clips, graphics, scanned documents, and audio files.
4256   • Is integrated with CPRS, allowing users to view images automatically for a selected patient. When a user views
4257       a radiology report or progress note in CPRS, the associated images are easily available.
4258   • Provides a standard interface between VistA and commercial PACS systems.
4259   • Automatically acquires complete studies from DICOM-compliant modalities (CT, MRI, digital x-ray, ultrasound,
4260       etc), associates the studies with the correct patient and report, and stores the studies in VistA Imaging for
4261       inclusion in the electronic patient record.
4262   • Provides image file storage, management, and retrieval from magnetic and optical disk servers and supports
4263       data capture, storage, and retrieval over a local or wide area network (WAN).
4264   • 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-1
4265
4266                    Figure: 3.1-112
4267




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
4268   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



4269
4270                                                      Figure: 3.1-113
4271
4272   3.1.84 VistAWeb
4273   VistAWeb is an intranet web application used to review remote patient information found in VistA, BHIE (DoD), the
4274   Health Data Repository (HDR) databases, and the Nationwide Health Information Network (NHIN).
4275
4276   To a large extent, VistAWeb mirrors the reports behavior of the Computerized Patient Record System (CPRS) and
4277   Remote Data View (RDV). However, by permitting a more robust and timely retrieval of remote-site patient data,
4278   VistAWeb is also an enhancement to CPRS/RDV.
4279
4280   There are three ways to access VistAWeb. VistAWeb can be made available by adding it to the CPRS Tools Menu,
4281   and it can be selected as the default method of retrieving data from the Remote Data Available button in CPRS.
4282   These two methods are referred to as CPRS-spawned versions of VistAWeb. They are compliant with the Health
4283   Level 7 (HL7) Clinical Context Object Workgroup (CCOW) standards and therefore maintain context with the patient
4284   selected in CPRS. As a third option, VistAWeb can be accessed in a standalone mode by entering the uniform
4285   resource locator (URL) link (https://vistaweb.med.va.gov/) in the Internet Explorer address bar.
4286
4287   Note: Some links found in this user manual go to sites or pages found on the VA intranet. These sites or pages are
4288   not accessible from outside the VA network.
4289
4290   The standalone version of VistAWeb is connected to neither CPRS nor the clinical context management application.
4291   Standalone VistAWeb serves an important function for users who have been granted special access to multiple sites,
4292   such as for National Programs, Veterans Administration (VA) researchers, and others. VistAWeb was also made
4293   available more broadly, though temporarily, to assist clinical staff with the retrieval of patient information from the
4294   sites affected by damage caused by hurricane Katrina.
4295   To fully appreciate the data that VistAWeb presents to the user, it is important to know something about the HDR as
4296   one of the sources of that data.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
4297
4298                                                       Figure: 3.1-114
4299
4300   VistAWeb - (Component diagram)
4301
4302
                cmp VistAWeb


                        VistaWeb                       Bi-directional Health Information Exchange (BHIE)


                                                       National Health Information Network (NHIN)


4303
4304                                                       Figure: 3.1-115
4305
4306   3.1.85 VIST-Visual Impairment Service Team
4307   With this program VIS Teams are able to easily manage and track activities and services provided to blinded
4308   veterans in their service area. This program integrates several fields of patient data to produce a variety of reports.
4309   The VIST patient record printout can be used in place of VA Form (10-1371) and is a more versatile document than
4310   the card. Semi- annual AMIS reports can be run and veterans can be added or deleted from the rolls quickly.
4311
4312   Features:
4313   • Enhances the efficiency of the Visual Impairment Service Team programs.
4314   • Provides a way to easily track and manage activities and services provided to blinded veterans.
4315   • Provides a wide variety of reports based on patient data. Blinded veterans can be quickly added or deleted from
4316       the rolls.
4317
4318   The new Blind Rehabilitation V.5.0 will integrate all four segments of Blind Rehabilitation Service, which includes:
4319   • VA Headquarters and Visual Impairment Service Teams (VIST);
4320   • Blind Rehabilitation Outpatient Specialists (BROS); and,
4321   • Blind Rehabilitation Centers (BRC).



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
4322
4323                                                       Figure: 3.1-116
4324
4325   3.1.86 Vitals/ Measurements
4326   The Vitals/ Measurements application is designed to store in the patient's electronic medical record all vital signs and
4327   various measurements associated with a patient's hospital stay or outpatient clinic visit. Data entered can be
4328   accessed by several VistA (Veterans Health Information Systems and Technology Architecture) applications (e.g.,
4329   CPRS, Health Summary) that interface with the Vitals/ Measurements application.
4330
4331   The Vitals application is composed of two modules: Vitals and Vitals Manager. Each module is accessed separately
4332   through GUI executable icons on the user’s desktop. The Vitals module is used to enter patient data, and is assigned
4333   to clinical staff. The Vitals Manager module is used to manage the Vitals templates and abnormal values ranges, and
4334   is assigned to the Clinical Application Coordinator, package coordinator, and Information Resource Management
4335   Service (IRMS) staff.
4336
4337   A Dynamic Link Library (DLL) file is also provided to allow other applications to use the Vitals/Measurements GUI.
4338   See Appendix C for more information on the DLL.
4339
4340   GMV MANAGER is the only security key in this application. This key controls access to the Vitals Manager module.
4341   This key also allows a user to view/create/edit all other user’s templates in the Vitals Manager module; without this
4342   key the user can only view, create, or edit their own user templates. This key should be assigned to the package
4343   coordinator.
4344
4345   Functionality
4346   • Provides a GUI (Graphical User Interface) to make collecting and viewing of data easier. Additional information
4347      on GUI software is contained at the end of this chapter.
4348   • Supports documentation of a patient's vital signs (e.g., temperature, pulse, and respiration), and tracks a
4349      patient's height, weight, central venous pressure (CVP), circumference/girth and oxygen saturation via oximetry
4350      with supplemental oxygen information. Also supports documentation of detailed or positional blood pressures for
4351      a patient (for example, bilateral blood pressures taken in a sitting position).


       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
4352   •   Displays latest information on all of the patient's vitals/measurements in both metric equivalents and U.S.
4353       customary units (when appropriate) along with the date/time the information was obtained, and the name of the
4354       user who entered the information.
4355   •   Allows facilities to establish hospital-wide high and low values for most vital signs and measurements. Identifies
4356       abnormal values, those values outside the high and low range, on vitals/measurements reports.
4357   •   Allows users to record a reason for the omission of a patient's vitals/measurements (such as Patient on Pass).
4358   •   Associates qualifiers (alpha characters appended to the measurement's numeric value) to provide a more
4359       detailed description of the patient's vitals/ measurements.
4360   •   Contains online help windows to assist users. Online help is accessed through the Help menu at the top of the
4361       screen, or by pressing the F1 key on the keyboard.
4362   •   Displays graphic reports on workstation monitors, and provides a variety of printable reports. Reports can be
4363       printed for an individual patient or for multiple patients.
4364   •   Provides APIs that pass patient vitals/measurements information within a specific date range to the other VistA
4365       applications.
4366   •   Provides compliance with the Clinical Context Object Workgroup (CCOW) standard. The CCOW standard
4367       provides a way for applications to know which other applications are currently running, and which patients are
4368       selected in those applications.
4369   •   Supports an interface to vital signs monitor connected to the workstation.
4370
4371   Features:
4372    Contains a Graphical User Interface (GUI) to make editing and viewing of data easier.
4373    Supports documentation of a patient's vital signs (e.g., temperature, pulse, and respiration).
4374    Tracks a patient's height, weight, central venous pressure (CVP), circumference/girth, and oxygen saturation via
4375       oximetry with supplemental oxygen information.
4376    Supports documentation of detailed or positional blood pressures for a patient (i.e., bilateral blood pressures
4377       taken in a sitting, standing, and lying position).
4378    Associates qualifiers (alpha characters appended to the measurement's numeric value) to provide a more
4379       detailed description of the patient's vitals/measurements.
4380    Prints patient's cumulative measurements on the Vital Signs Record and the Cumulative Vitals Report.
4381    Displays latest information on all of the patient's vitals/measurements in both metric equivalents and U.S.
4382       customary units along with the date/time the information was obtained.
4383    Prints expanded vitals graphic report, which includes the patient's intake and output when present in the patient's
4384       database (refer to the Intake and Output application).
4385    Allows facilities to establish hospital-wide high and low values for each vital sign or measurement.
4386    Identifies abnormal patient values on vitals/measurements reports (those values outside the high and low range).
4387    Prints the following patient measurements in a linear graphic format when using a Kyocera F-800A or HP
4388       compatible (programmable) printer:
4389           o Temperature and pulse.
4390           o Blood pressure.
4391           o Weight.
4392           o Pulse oximetry and respiration.
4393           o Pain.
4394    If reports are printed on a dot matrix printer, plotted data values are not connected by a line.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
4395      Supports the archiving and purging of patient measurements, which are no longer required on the production
4396       account, through FileMan.
4397      Passes patient vitals/measurements information (numeric values only) within a specific date range to the Health
4398       Summary application.
4399      Records a reason for the omission of a patient's vitals/measurements.




4400
4401                                                    Figure: 3.1-117
4402
4403   3.1.87 Womens Health
4404   The Women’s Health (WH) software provides tracking functionality for procedures of particular interest to women
4405   patients (e.g., screening mammogram). The software provides a full range of breast and gynecologic cancer
4406   screening and tracking functions. The intended users of the software are primarily WH coordinators and case
4407   managers. Providers may use selected patient management and report options.
4408




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-1
4409   This software is based on the Indian Health Service (IHS) Resource and Patient Management System (RPMS)
4410   Women’s Health software V. 2.0, and modified from suggestions provided by the VISTA Women’s Health Technical
4411   Advisory Group (TAG).
4412
4413   Main Features
4414   The Women’s Health software is composed of three main modules: Patient Management, Management Reports, and
4415   Manager’s Functions.
4416
4417   Patient Management is the portion of the software used to manage individual patient care, that is, their procedures,
4418   due dates and correspondence. Under the Patient Management menu it is possible to maintain patient data such as
4419   the date of the next PAP smear, colposcopy or mammogram, the patient's pregnancy and her EDC (due date), as
4420   well as the patient's current PAP regimen. It is also possible to track the patient's individual procedures: the date
4421   performed, the provider and clinic, the results or diagnosis, etc. Notifications (letters and phone calls) may also be
4422   tracked. A file of form letters has been included in the software, and these letters may be edited and personalized for
4423   a clinic's particular needs. Reminder letters can be queued months in advance of a future appointment, then printed
4424   and mailed out shortly before the tentative appointment.
4425
4426   Management Reports is the portion of the software used to print epidemiological reports such as the number of
4427   women who received a mammogram for the selected time period, or the number of patients having abnormal PAP
4428   results during a selected time period. Under the Management Reports menu it is possible to produce lists of patients
4429   who are past their due dates for follow-up procedures. It is also possible to store program statistics by date for later
4430   comparison of program trends and progress.
4431
4432   Manager’s Functions is that portion of the software that provides the ADPAC with a set of utilities for configuring the
4433   software to the specific needs of the site. It also provides utilities for other program needs, such as customizing
4434   tables, making special edits to patient data (e.g., pregnancy log, PAP regimen log), printing notification letters,
4435   running error reports, and documenting laboratory results. By using the File Maintenance options under the
4436   Manager’s Functions menu, it is possible to maintain site specific parameters such as the text of form letters, the
4437   types of notifications and their synonyms, how and when letters get printed, and several defaults relating to dates.
4438
4439   Patients, Procedures, and Notifications
4440   There are primarily three distinct data sets within the WH application and they can be categorized as patient,
4441   procedure, and notification related.
4442
4443   Patients refer to the women in the program register. Data stored for each patient includes demographic data, the
4444   patient's case manager, the current or next cervical and breast treatment need and its due date, the patient's PAP
4445   regimen along with the date it began, and other data. This type of data is referred to as the patient's case data.
4446
4447   Procedures refer to any of the diagnostic and therapeutic tests, exams, or other interventions tracked by the
4448   software. The table of procedure types includes PAP smear, colposcopy, mammogram, LEEP, cone biopsy, ECC,
4449   and others. The results or diagnosis associated with the gynecologic procedures are chosen from a table of
4450   Bethesda-consistent terminology. Mammogram results use the American College of Radiology (ACR) terminology.
4451




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
4452   Notifications refer to any type of communication or correspondence with the patient, such as first, second and third
4453   letters, certified letters, phone calls, messages left, etc. Notifications, which take the form of letters, fall into two
4454   categories: results letters and reminder letters. Result letters inform the patient of the findings of a recent procedure
4455   and are queued to print immediately. Reminder letters inform the patient of the need to schedule her next
4456   appointment and are queued to print at some time several weeks or months in the future.
4457
4458   Selected reports that look at the due dates of patients' treatment needs (using both the procedure and notification
4459   data sets) provide a comprehensive mechanism for guarding against losing patients to follow-up.
4460
4461   The Basic Patient Management Loop
4462   The function of the Women’s Health software is best understood in terms of the Basic Patient Management Loop.
4463   The loop is a sequence of events that occur over and over again during a patient's health care cycle.
4464
4465   This software uses the concept of procedures and notifications being open and closed. Procedures and notifications
4466   will become delinquent if they are not closed by the ‘Complete by (Date)’ field found in the notification and procedure
4467   screens. If a procedure or notification is not closed by its due date, this will be an indicator that the patient may be
4468   ‘lost’ to follow-up. Generally, a procedure is closed when the results or diagnosis for that procedure are entered. A
4469   notification is closed either at the time it is printed (as in the case of a results letter) or when the patient returns for
4470   her next appointment (as in the case of a reminder letter).
4471
4472   Summary
4473   In summary, Women’s Health is largely a patient management tool for tracking the breast and gynecologic treatment
4474   needs of women, the procedures they receive, and the communications between healthcare staff and women
4475   regarding their treatment and follow-up. The software also provides some program-wide epidemiological reports
4476   which are of use to clinicians and program administrators.




       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                 Page 3-1
4477
4478                    Figure: 3.1-118
4479
4480




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
4481   3.2 Financial-Administrative
4482   Financial and Administrative Systems manage portfolios for the core legacy systems, aids in the
4483   planning, development, and implementation of enterprise-wide projects, and provides billing and patient
4484   records management solutions to our internal customers and end users, which results in a positive
4485   experience for our most prized customer, the Veteran.
4486
4487   The MFS portfolio focuses on:
4488       Patient Financial Services Systems
4489       Fee Basis Claims Processing
4490       Decision Support Systems
4491       Core Financial Logistics Systems
4492       Health Revenue Center
4493       HIPAA
4494       Future Integration with Commercial Applications
4495




       www.oserha.org                               OSEHR System-Architecture, Product Definition and Roadmap    Page 3-1
                                                                                                                       AR V.3.7



       class Financial-Administrativ e Install-Dependencies and DBIA-Associations

              Name:       Financial-Administrative Install-Dependencies and DBIA-Associations
              Package:    Financial-Administrative
              Version:    Oct 2011
              Author:     OSEHRA                                       Record
                                                                                                       DBIA
                                                                      Tracking
                                                                                                                               ADT/Registration
                                                                                           ADT/Registration V.5.3                                        Integration
                                                                            DSS                                                                          Agreement

                                                                                                                             DBIA, V1.5

                                                                                                                                        GCS V.2.0

                                                                                                                             GCS                     Library
                                                       CPT


                                                                                                                   GCS V.2.0        GCS V.2.0          DBIA
                                                     CPT V.5.0


                                    DBIA             Fee Basis
                    DRG                                                                                       AR
                                                                                      DBIAs


                                                                                                                      DBIA                 IFCAP V.5.0
                                                                                                     IFCAP V.5.0
                                                                                                                                                                             DBIA#186, V2.0
                                                                                  IFCAP V.4.0
                                                        DBIA                                                  IFCAP

                                                                                   PFOP    DBIA
                                                                                                                      DBIA
                                                                                                                                              DBIA
                    DBIAs                                                                        DBIA
                                                    DBIAs

                                                                            ECS V.2.0                                    Equipment/                                    EAS
                                                                                                ECS
                                                                                                                       Turn-In Request

                                                                                                               DBIA
                                                                                                                             DBIA

                                                                                                IFCAP V.4.0                                                            DBIA
                                        IB V.2.0                 IB V.2.0
                                                                                                                                    AEMS/MERS




                                                                                                IB

                                                             DBIA

                                                                                                                                       IB V.2.0                         IB V.2.0
                               Wounded Inj ured                HINQ
                                and Ill Warriors

                                                                      HINQ V.4.0
                                                                                                 IB V.2.0
                                                                                                                              DBIA
                                MAS-Medical
                PAID                                           AMIE
                                Administration
                                  Serv ice

                                                                       AMIE v?                                                                       IVM V.2.0
              PAID V.4
                                   MAS V.5.0
                                                                                                                                        IVM                            HEC
              ASISTS                  OS                       CAPRI                              ECME

                                                                                          Visit Tracking V.2.0



            QMIM                      ROI                        VSS                          Visit Tracking                         Police and                        PR
                                                                                                                                      Security




             AICS                     FFP                        IR                       Clinical Monitoring                         ICD-9-CM
                                                                                                                                                                   VIC/PICS
                                                                                                System



4496
4497                                                                                Figure: 3.2-1
4498
4499




       www.oserha.org                                                               OSEHR System-Architecture, Product Definition and Roadmap                                                 Page 3-1
4500   `Financial-Administrative - (Package diagram)




4501
4502                                           Figure: 3.2-2
4503
4504



       www.oserha.org                          OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
4505   3.2.1 AR-Accounts Receivable
4506   This Accounts Receivable (AR) software has resulted from a separation of Accounts Receivable functions from the
4507   Integrated Funds Distribution, Control Point Activity, Accounting and Procurement (IFCAP) package. It allows Fiscal
4508   Service to manage the debt collection process at a VA facility.
4509
4510   The Accounts Receivable package automates the Fiscal functions related to the management of Accounts
4511   Receivable, and is integrated with the Integrated Billing (IB) package process of preparing patient Bills on the UB-92.
4512   The Accounts Receivable package is also integrated with the National Roll-Up database.
4513
4514   The system must be running the following software to successfully operate AR Version 4.5. Versions running must be
4515   those stated or later:
4516        • KERNEL Version 7.1
4517        • VA FileMan Version 20
4518        • MAS Version 5.3 (PIMS)
4519        • IFCAP Version 5.0
4520        • IB Version 2.0
4521        • Generic Code Sheet 2.0
4522   Currently, the Integrated Billing (IB) package interfaces with AR [package] routines, files and utilities. AR also
4523   interfaces with the IB package.
4524
4525   With this version of AR, it is necessary to be running IFCAP for generation of documents to FMS and site parameter
4526   information.




4527
4528                                                       Figure: 3.2-3



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-1
4529
4530




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
4531   AR-Accounts Receivable - (Component diagram)
4532
                         cmp AR-Accounts Receiv able



                               AR-Accounts Receiv able


                                              «interface»                 National Roll-Up
                                                RCNR*                     Database




                                              «interface»
                                                                          National Roll-Up
                                              PRCANRU                     Database



4533
4534                                                   Figure: 3.2-4
4535
4536




       www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap   Page 3-1
4537   3.2.2 ASISTS-Automated Safety Incident Surveillance Tracking System
4538   The ASISTS software package stores data on accidents causing injuries and illnesses reported via the Report of
4539   Incident. The employee may choose to apply for compensation using the Federal Employee's Notice of Traumatic
4540   Injury and Claim for Continuation of Pay/Compensation (CA-1) when the incident is an injury and the Notice of
4541   Occupational Disease and Claim for Compensation (CA-2) for an illness.
4542
4543   Statistical reporting is performed on incidents occurring nationwide by extracting pertinent Report of Incident data
4544   from facilities and transmitting it to the ASISTS National Database (NDB). Reports are periodically generated from
4545   the NDB to identify systematic trends and to support prevention programs concerning front line health care worker
4546   exposure to bloodborne pathogens.
4547
4548   The ASISTS package provides the capability to electronically transmit CA-1 and CA-2 data to the Department of
4549   Labor (DOL). Federal Law requires that these forms be submitted within 14 days after the employee submits a claim
4550   for an accident or illness. The data is collected at each facility and is then transmitted to DOL via the Austin
4551   Automation Center (AAC). The transmission of each completed form is under the control of workers’ compensation
4552   personnel at each facility.
4553
4554   ASISTS has three major goals.
4555   •     Better tracking of employee injuries and illnesses ASISTS computerizes the Report of Incident as well as the
4556   OWCP CA-1 and CA-2 forms. These reports help improve the ability to trend and analyze accidental injuries and
4557   illnesses, thus helping to prevent future incidents from occurring.
4558   • Reduce exposures to bloodborne pathogens from needlesticks, sharps, or body fluids ASISTS instantly notifies
4559   Occupational Health and other medical personnel when the employee reports an incident involving a bloodborne
4560   pathogen exposure, so that proper tests and treatment can be initiated. The data concerning exposure to bloodborne
4561   pathogens will be collected in a national database to identify national trends, training needs, and best practices for
4562   the benefit of all employees at every VA medical center.
4563   •      Reduce worker compensation costs ASISTS facilitates a case management approach to preventing future
4564   incidents and provides better management of workers' compensation claims. Through automation, the incident
4565   reporting process will be more accurate and be processed in a more timely fashion.
4566
4567   Features:
4568   •       Electronic signature is used extensively throughout this program. All three forms (VA Form 2162, CA-1, and
4569   CA-2) require appropriate signatures including that of the employee for the CA-1 and CA-2, which is used when
4570   electronically transferring the date to the Department of Labor.
4571   •         Bulletins alert employee health and infection control of any exposures to blood borne pathogens. The
4572   employee's supervisor, the safety officer, Human Resources Management, and union representatives are notified of
4573   every incident. Electronic signatures trigger bulletins from the employee to the supervisor and union representatives
4574   and from the supervisor to the safety officer, alerting the recipient of action that should be taken.
4575   •     Every medical center employee has access to a menu structured specifically to the level of his/her involvement
4576   in the process: employee health, supervisor, safety officer, union representative, workers’ compensation personnel,
4577   and employee.
4578   •        The graphical user interface (GUI) for ASISTS facilitates the input and processing of accident reports and
4579   claims and improves the reporting functionality, including a revised OSHA and Needlestick log and graphical
4580   representation of the incident reports.



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-1
4581   •       Future versions will include a comprehensive employee health module for tracking and following numerous
4582   health issues.
4583




4584
4585                                                    Figure: 3.2-5
4586




       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap         Page 3-1
4587   ASISTS-Auto Safety Incident Surveillance Tracking System - (Component diagram)
4588
        cmp ASISTS-Auto Safety Incident Surv eillance Tracking System



               ASISTS-Automated Safety Incident
                 Surv eillance Tracking System




                                          «interface»              Dept of Labor (DOL) via Austin Automation Center (AAC)
                                             OOPS
                                                                   ASSISTS National Database

                                                                   Other Mail Groups




4589
4590                                                        Figure: 3.2-6
4591
4592   3.2.3 AICS-Automated Information Collection System
4593   The encounter form is a paper form designed specifically for outpatient visits. It is used both to display relevant
4594   patient data for use during the visit, such as demographics, allergies, and problems; and to collect data about the
4595   visit, such as procedures and tests performed. Its primary focus is clinical and to collect data for the Ambulatory Care
4596   Reporting Project. It also has other purposes such as collecting data necessary for billing.
4597
4598   The AICS package contains all the software necessary to design, edit, and assign encounter forms to clinics; print
4599   forms for appointments with patient data; and print with or without patient data for patients without an appointment.
4600   The software enables collection of outpatient clinical and administrative data; and provides a more organized, less
4601   obtrusive method of data collection to the clinician and supporting clerical staff.
4602
4603   AICS is a hybrid system designed to use commercial software for the scanning and image processing of forms.
4604
4605   Features:
4606   • Provides a form design utility that allows creation of attractive and easy to use forms for each clinic.
4607   • Allows forms to be designed to print with patient data displayed, such as patient demographics, insurance
4608       information, allergies, clinical reminders that are due and active problems.
4609   • Allows for the creation of forms to collect data such as procedures, diagnoses, problems, providers, progress
4610       notes, vital signs, and Patient Care Encounter (PCE)-related data such as exams, health factors, patient
4611       education, skin tests, and immunizations.
4612   • Provides a print manager that allows all clinic-specific forms to print with the encounter form for an appointment.
4613       The print manager also provides a setup system that, once accomplished, no longer requires daily user
4614       intervention.
4615   • Provides an import/export utility that makes it easier for sites to exchange forms they have already created.
4616   • 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-1
4617   •   Manual data entry options are available to allow data to be key entered by a clerk and passed to PCE to be
4618       stored.
4619




4620
4621                                                        Figure: 3.2-7
4622
4623   3.2.4 AMIE-Automated Medical Information Exchange
4624   The Automated Medical Information Exchange (AMIE) module facilitates the electronic interchange of veteran
4625   information between Veteran Benefits Administration (VBA) Regional Offices (ROs) and VA medical facilities. The
4626   comprehensive module provides an accurate audit trail to track most requests for information. The module is
4627   composed of two components: Facility administrative options and VBA Regional Office options. Each area has
4628   individual items to maintain daily, and its own reports to print. RO staff access VA medical facility computers through
4629   VA national telecommunications network, and exercise their options on each local medical facility’s system as
4630   necessary.
4631
4632   Features
4633   •     Provides access to local databases for identification of a veteran’s admission, discharge,
4634   outpatient treatment, patient care, and other information that may require adjudicative actions.
4635   •     Reduces overpayments previously caused by lost, misrouted, or improperly processed admission notifications.
4636   •    Provides on-line status determinations of pending compensation and pension examinations (requesting,
4637   scheduling, tracking, and updating results).
4638   •      Provides RO on-line access to the local databases for the confirmation of the propriety of payments based on
4639   hospitalization.
4640   •     Improves timeliness of the RO benefits adjustment processing.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
4641   •      Allows medical centers to electronically access sections of the Physicians Guide for Disability Evaluation
4642   Examinations.
4643   •   Provides tracking of insufficiently completed compensation and pension examinations.




4644
4645                                                        Figure: 3.2-8
4646
4647   3.2.5 Clinical Monitoring System
4648   The heart of the Clinical Monitoring System package is in building monitors using conditions and groups for patient
4649   auto enrollment.
4650
4651   The main function of this software is to capture data for patients meeting specified conditions. All monitors within the
4652   framework of this software are ultimately based upon patient related data. In order to capture data, you create
4653   monitors that run nightly. These nightly runs "auto enroll" (or capture) the patients defined by the monitors.
4654
4655   This system looks at what happened yesterday in VistA. It can capture such items as ward, treating specialty, SSN,
4656   age, etc. For a more extensive list of items, use the Data Element File Inquire option within the Outputs Menu of the
4657   Monitoring System Manager Menu. Data elements available for capture vary depending on the conditions you select
4658   when building monitors.
4659
4660   Conditions are provided with the Clinical Monitoring System package. Examples of conditions include ON WARD,
4661   READMISSION, MAS MOVEMENT TYPE, PREVIOUS DISCHARGE, etc. You may use the Condition File Inquire
4662   option to obtain information on selected/all conditions. The information provided will describe the condition; tell you
4663   what questions will be asked when using a condition; tell you when you must define a group for the condition, and list
4664   the other data that is available for capture.
4665
4666   Each condition chosen for a monitor brings up a set of questions pertaining to it. For example, if you choose the AGE
4667   condition, you will be asked age ranges. Some conditions require a group be defined such as a group of wards, drug



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
4668   classes, MAS movement types, etc. Patients captured by the monitors are called "fall outs". With each condition
4669   used, there is a list of other data that can be captured when a patient becomes a “fall out” that might include items
4670   such as ward, admission date, attending, etc.
4671
4672   The monitors can be queued to run nightly, or manually run, one or more at a time. Each monitor has an "ON/OFF"
4673   switch, an "UNDER CONSTRUCTION" or "FINISHED" status, and START and STOP dates so that running it can be
4674   tightly controlled.
4675
4676   Features:
4677   • Provides the user with the ability to design a monitor that will auto enroll cases that meet the user's defined
4678       criteria/conditions from VistA.
4679   • Allows the user to set time frames for computing percentages and tracking findings between time frames.
4680   • Has the ability to alert users when important thresholds or dates are met.
4681   • Provides a mechanism to add site-developed conditions and data elements and routines such as site-designed
4682       worksheets to the software. MUMPS programming is a required part of site-specific enhancement.
4683   • Provides mechanisms for controlling the disk space and CPU time resources used by the Clinical Monitoring
4684       System.
4685   • Allows the user to manually enter cases.




4686
4687                                                       Figure: 3.2-9
4688
4689   3.2.6 CAPRI-Compensation and Pension Records Interchange
4690   Compensation and Pension Record Interchange (CAPRI) is an information technology initiative to improve service to
4691   disabled veterans by promoting efficient communications between the Veterans Health Administration (VHA) and
4692   Veterans Benefits Administration (VBA). Online access to medical data enhances the timeliness of the benefits
4693   determination. The CAPRI software acts as a bridge between the VBA and VHA information systems. It offers VBA
4694   Rating Veteran Service Representatives and Decision Review Officers help in building the rating decision
4695   documentation through online access to medical data. It offers VHA Compensation & Pension (C&P) staff an easy,
4696   standardized way of reporting C&P Examination results.
4697
4698   Using CAPRI, VBA employees will have a standardized, user-friendly method to rapidly access veterans' electronic
4699   medical records throughout the VA. Initially developed specifically for VBA, the utility of CAPRI has been expanded to
4700   other user groups that include VHA, Office of the Medical Inspector, OI, Research, Veteran Service Officers, and



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
4701   others. One of the primary features of CAPRI is the Compensation and Pension Worksheet Module (CPWM) which is
4702   used by VHA C&P providers and staff. CPWM provides clinical users access to exam templates and tools that are
4703   used to document C&P examinations.
4704
4705   Features
4706   • Demographics
4707           o Load new patients into VistA system.
4708           o View patient demographics.
4709           o Report patient address changes to VHA.
4710   • C&P Examination Functionality
4711           o Add/Edit C&P exam request.
4712           o Create an insufficient exam request.
4713           o Individual and cumulative pending exam tracking.
4714           o Request VAF 7131 information.
4715           o VA Regional Office reports.
4716           o AMIS 290 report.
4717           o Automatic Mailman bulletins to AMIE mail groups.
4718           o All standard AMIE worksheets are available in template form.
4719           o Automatic sending of completed exam requests.
4720           o Ability to save template work in progress and finish later.
4721           o Ability for site to review exams before releasing it to VBA.
4722           o Multiple templates can be merged into a single exam.
4723   • Patient Records Navigation
4724           o View health summaries.
4725           o View appointment lists.
4726           o View progress notes.
4727           o View discharge summaries.
4728           o View consult requests and results.
4729           o View cumulative vitals.
4730           o View active medications.
4731           o View lab reports.
4732           o View imaging.
4733           o View procedures.
4734           o View FHIE/DoD data, if available.
4735




       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap       Page 3-2
4736
4737                                                      Figure: 3.2-10
4738
4739   3.2.7 CPT-Current Procedural Terminology
4740   Current Procedural Terminology (CPT) codes are used for reporting medical services and procedures performed by
4741   clinicians. The purpose of the code is to provide a uniform language that will accurately describe medical, surgical,
4742   and diagnostic services, thereby providing an effective means for reliable nationwide communication among
4743   physicians, patients, and third parties.
4744
4745   This system of terminology is the most widely accepted nomenclature for the reporting of clinical procedures and
4746   services under government and private health insurance programs.
4747
4748   The CPT software includes all CPT codes document outpatient services for reimbursement and workload purposes
4749   as determined by the American Medical Association and the Healthcare Common Procedure Coding System
4750   (HCPCS) from the Centers for Medicare and Medicaid Services (CMS). These codes may also be used to report
4751   inpatient services in certain instances.



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
4752
4753   Features
4754   • Provides annual updates for CPT and HCPCS codes.
4755   • Provides several reports to display new, revised, or inactivated codes.
4756   • Supplies detailed descriptions of CPT and HCPCS codes.
4757
4758   International Classification of Diseases, Clinical Modification (ICD-9-CM)
4759   The International Classification of Diseases, Clinical Modification (ICD-9-CM) is a clinically-modified statistical
4760   classification system that arranges diseases and injuries into groups according to established criteria. It is based on
4761   the ICD-9, which was designed for the classification of morbidity and mortality information for statistical purposes,
4762   and published by the World Health Organization (WHO). These codes provide an effective means of communication
4763   between physicians, patients, and third parties.
4764
4765   Lexicon service provides the software to update the ICD files. ICD–9-CM consists of the following components:
4766   • A tabular list containing a numerical list of disease code numbers.
4767   • An alphabetical index to the disease entries.
4768   • A classification system for surgical, diagnostic, and therapeutic procedures as defined by WHO.
4769   • Use of ICD-9-CM codes is approved by Centers for Medicare and Medicaid Services (CMS).
4770
4771   Updates to these codes are released in the Federal Register by CMS in May/June of each year. These code updates
4772   include changes to the codes and code narratives. An electronic version of the updates is released by CMS in
4773   September, which must go into effect on October 1st of each year. CMS has a benchmark of 30 days beyond the
4774   effective date of October 1st for implementing these updates.




4775
4776                                                       Figure: 3.2-11
4777
4778   3.2.8 DSS-Decision Support System Extracts
4779   Decision Support System Extracts (DSS) V3.0 provides a means of exporting data from selected Veterans Health
4780   Information Systems and Technology Architecture (VistA) modules to a Decision Support System (DSS) resident in
4781   the VA Austin Information Technology Center (AITC).
4782
4783   This transfer is accomplished through a set of extract routines, intermediate files, audit reports, a transmission
4784   routine, and a purge routine. Data from VistA packages is stored by the extract routines in the intermediate files,



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
4785   where it is temporarily available for local use and auditing. The data is then transmitted to the AITC, where it is
4786   formatted and uploaded into commercial software. After the data has been successfully uploaded into the commercial
4787   software, it is purged from the intermediate files.
4788
4789   The DSS Extracts V3.0 software includes the following functionalities:
4790          o DSS Extract field additions and modifications
4791          o DSS Menu additions, modifications and deletions
4792          o New DSS reports and report modifications
4793          o Implementation of the new and/or deleted extracts




4794
4795                                                      Figure: 3.2-12
4796
4797   3.2.9 DRG-Diagnostic Related Group Grouper
4798   The DRG Grouper is a "black box" utility with standalone functionality and can be called by other VISTA applications.
4799   The DRG Grouper package contains two options:
4800   • DRG Grouper - Used to compute and display the Diagnosis Related Group (DRG) for a patient based on that
4801        patient's diagnoses and any operations/procedures performed.
4802   • ICD Code Inquiry - Allows the user to display information for a selected diagnosis or operation/ procedure code.
4803
4804   This version of the DRG Grouper is based on the current Medicare Grouper requirements as defined by the Health
4805   Care Financing Administration (HCFA) contained in the annual update from 3M Health Information Systems. The
4806   same DRG Grouper is used by the Austin Automation Center (AAC).
4807
4808   DRG Components




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
4809   The DRGs are defined as a manageable, clinically coherent set of patient classes that relate a hospital case mix to
4810   the resource demands and associated costs experienced by the hospital. There are 511 DRGs associated with the
4811   DRG Grouper. Each represents a class of patients deemed medically comparable and requiring similar amounts of
4812   resources for care.
4813
4814   The DRGs may be calculated for both registered VA patients and non-VA patients. Except for Transfer DRGs, the
4815   system does not store the DRG compiled for each patient. DRGs are recalculated each time the DRG Grouper option
4816   is utilized. If data entered is insufficient for the DRG Grouper to function, the DRG will not be computed and will be
4817   displayed as "UNGROUPABLE". A message such as "Grouper needs to know if patient died during this episode!" will
4818   appear to inform you what missing data is required.
4819
4820   Classifying DRGs
4821   The actual process of classifying the patients into one of the 511 DRGs is done by the DRG Grouper using the
4822   following information:
4823   • Age
4824   • Sex
4825   • Diagnosis codes
4826   • Operation/procedure codes
4827   • Discharge status
4828
4829   The patient's age and any secondary diagnoses the patient had are used to determine whether the patient's stay had
4830   significant and contributing complications and/or co-morbidities. The DRG Grouper accepts one primary diagnosis
4831   and unlimited secondary diagnoses and operations/ procedures.
4832
4833   Features
4834   • Provides annual updates that conform to the latest release of the commercial grouper.
4835   • Functions within or apart from other modules.
4836   • Supplies detailed descriptions of DRGs, diagnostic codes, and operation/procedure codes.
4837   • Accepts one primary diagnosis and multiple secondary diagnostic codes and operation/procedure codes.
4838   • Displays weighted work unit values as well as national and local high and low trim point values for each DRG




4839
4840                                                      Figure: 3.2-13
4841



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
4842   3.2.10 ECME-Electronic Claims Management Engine
4843   The Electronic Claims Management Engine (ECME) generates electronic claims in National Council for Prescription
4844   Drug Programs (NCPDP) V. 5.1 format, based on the Outpatient Pharmacy V. 7.0 workflow. ECME:
4845    Allows pharmacy claims processing staff to submit, resubmit, and reverse electronic claims;
4846    Provides reports for end users and management on claims status, transaction history, and system configuration
4847        standings;
4848    Allows Automated Data Processing Application Coordinator (ADPAC) and Information Resources Management
4849        Service (IRMS) staff to configure ECME to pharmacy site specifications.
4850
4851   ECME claims processing begins when events within Outpatient Pharmacy V. 7.0 meet specific criteria, based on
4852   Integrated Billing (IB) V. 2.0 determination, that indicate the system should generate an electronic claim. To build a
4853   claim through ECME, several conditions must be met. First, the patient must be registered and have pharmacy
4854   prescription insurance coverage. Second, the patient must be a non-service connected patient or, if service
4855   connected, the prescription must not be for the service connected condition. The patient must not have an
4856   environmental indicators condition. Finally, the drug must be billable.
4857
4858   Logic embedded within ECME manages the creation of the electronic claim, which requires integration with IB V. 2.0,
4859   Pharmacy Data Management, and National Drug File (NDF) V. 4.0. ECME also generates claims during
4860   Consolidated Mail Outpatient Pharmacy (CMOP) V. 2.0 processing for prescriptions that meet billing requirements
4861   and which are suspended for CMOP fills.
4862
4863   The Veterans Health Administration (VHA) developed ECME software in order to comply with the Health Insurance
4864   Portability and Accountability Act (HIPAA) of 1996 and updated it to comply to the HIPAA rule of 2009, which requires
4865   health care providers to electronically transmit outpatient pharmacy prescription claims to payers in the NCPDP
4866   format and to receive responses on a real-time basis. ECME is derived from the Point of Sale (POS) Application
4867   developed by the Indian Health Service (IHS) and is assigned to the BPS namespace.




4868
4869                                                      Figure: 3.2-14



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
4870
4871




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
4872   ECME-Electronic Claims Management Engine - (Component diagram)
4873
        cmp ECME-Electronic Claims Management Engine



               ECME-Electronic Claims
                 Management Engine


                               «interface»                  Austin Information Technology Center
                                  BPS




4874
4875                                                    Figure: 3.2-15
4876
4877   3.2.11 AEMS/MERS-Engineering
4878   The Engineering package, otherwise known as Automated Engineering
4879   Management System/ Medical Equipment Reporting System (AEMS/MERS) was released on a national basis in
4880   1985. In September of 1988, Engineering Service and the Office of Acquisition and Materiel Management (A&MM)
4881   jointly decided that the Engineering Equipment file should become a shared resource. This version of Engineering
4882   includes all data elements required for establishing and maintaining Integrated Supply Management System (ISMS)
4883   nonexpendable equipment records.
4884
4885   This version of the Engineering package frequently invokes VA Kernel Version 6.5 or later and VA FileMan Version
4886   18.0 or later for device selection, task queuing, data entry, and data presentation.
4887
4888   Functional Description
4889   The DHCP Engineering package consists of nine (9) separate but interrelated
4890   modules.
4891           1. Work Order and MERS
4892           2. Project Planning
4893           3. Project Tracking
4894           4. Equipment Management
4895           5. Space/Facility Management
4896           6. Program Management
4897           7. 2162 Accident Reporting
4898           8. Assign (Transfer) Electronic Work Orders
4899           9. IT Equipment Tracking
4900
4901   Work Order and MERS
4902   The Work Order and MERS module generates control numbers for Engineering work requests and provides a means
4903   for assigning work requests to specific Engineering shops, assigning personnel to work orders, and charging work
4904   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-2
4905   Although preventive maintenance inspections are scheduled and recorded using the Equipment Management
4906   module, the actual PM work orders that constitute a PM worklist are physically stored in the Work Order file. Special
4907   options exist for displaying incomplete work orders and for transferring electronic work orders (work requests typed
4908   into DHCP by end-users and not by Engineering) from a "receiving area" to a working shop.
4909
4910   Project Planning
4911   The Project Planning module provides enter/ edit options for information that appears on the 5-Year Plan for each
4912   project; information required for forms VAF 10-1193; VAF 10-1193a; and NRM, Minor, and Minor Misc. Prioritization
4913   Scoring Sheets.
4914
4915   The Approval of Project Application option controls the Chief Engineer's and VAMC Director's sign off on the project
4916   application. The security key ENPLK001 controls the Chief Engineer's approval. The security key ENPLK002 controls
4917   the VAMC Director's approval. The Chief Engineer must sign off before the VAMC Director. Both must approve
4918   before the project application can be transmitted electronically to higher approval authorities.
4919
4920   The Report/Print Menu options provide print-outs of the reports and forms required by project planning. The
4921   Electronic Transmission Menu contains options for electronic transmission of the 5-Year Plan and Project Application
4922   data elements.
4923
4924   Project Tracking
4925   The Project Tracking module is used to record significant events during construction and non-recurring maintenance
4926   projects when the management of such a project has been delegated to the facility. Selected data elements are
4927   extracted from the Construction Project file and electronically transmitted to the Regional Construction Office and
4928   VACO. In this way, up-to-date project tracking information is made available to all interested parties with a minimum
4929   of data entry.
4930
4931   The content of the most recent electronic project progress report is always available for reference. Printouts of
4932   progress reports will include an asterisk beside data that differs from what was previously reported. If progress
4933   reports are directed to a CRT, changes will be highlighted.
4934
4935   Equipment Management
4936   The Equipment Management module contains the options to maintain inventory and preventive maintenance
4937   information, print bar code labels, download control programs to portable bar code readers, upload data from
4938   portable bar code readers to DHCP, and to manage CMR (Consolidated Memoranda of Receipt).
4939
4940   Equipment records generally exist for non-expendable personal property, building service equipment, and for
4941   equipment that is classified as expendable from the materiel management point of view but which must be
4942   periodically inspected by Engineering. These inspections are necessary to satisfy the requirements of JCAHO (Joint
4943   Commission on the Accreditation of Healthcare Organizations) and/or other regulatory bodies. The Equipment
4944   Management module includes all options necessary for establishing and maintaining a comprehensive preventive
4945   maintenance program. Bar coding is now an integral part of the equipment management strategies.
4946
4947   The reports available through the Equipment Management module include:
4948   • Repair histories,



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
4949   •   CMR listings,
4950   •   Aggregated repair histories (by Equipment Category),
4951   •   Warranty expiration listings,
4952   •   Equipment replacement listings,
4953   •   Equipment with high failure rates,
4954   •   Preventive maintenance workload (by shop).
4955
4956   The Equipment Management module is tightly coupled to the Work Order module. Equipment histories are
4957   automatically updated as work orders are closed out. Redundant data entry is avoided whenever possible.
4958
4959   Although entries in the equipment repair histories are most commonly made by the system when work orders are
4960   closed out, users can also make entries without going through the Work Order module. Equipment records to be
4961   updated by direct posting may be selected individually or they may be contained in a VA FileMan sort template. If a
4962   sort template is used, it must begin with "ENPOST."
4963
4964   Program Management
4965   The Program Management module contains options for site-specific population and/or maintenance of files used in
4966   the Engineering package. This option is only available to the Engineering Applications Manager or Engineering Site
4967   Manager. It is where the various lists are established and maintained. The Engineering Employee file and the
4968   Equipment Category list must be maintained on a continuing basis. Populated copies of the Equipment Category file
4969   are available from your supporting ISC upon request.
4970
4971   Space/Facility Management
4972   The Space/Facility Management module is used to maintain data on physical locations within the host facility (usually
4973   a VA Medical Center). Data elements include square footage; wall, ceiling and floor finishes; window types and
4974   treatments; and other architectural features. This module also provides control of locks and keys throughout a facility.
4975   Bar coded location labels are printed from the Space file based on room number. Facilities that intend to take
4976   advantage of the bar code features in the Equipment Management module should insure that the Building file is
4977   completely current and that the Space file contains at least a room number (including building and division, if
4978   applicable) for each physical location. The proper format for a room number (which must be unique and
4979   unambiguous) is Room-Building-Division. Most single division facilities will need to enter only Room-Building.
4980
4981   2162 Accident Reporting
4982   The 2162 Accident Reporting module collects the data elements of VA Form 2162 so that accidents and on-the-job
4983   injuries can be aggregated and analyzed by Service/ Section, cause of accident, nature of accident, etc.
4984
4985   Assign (Transfer) Electronic Work Orders The Assign (Transfer) Electronic Work Orders option was developed to
4986   facilitate the process of transferring electronic work orders from the receiving area(s) to a working shop. Users may
4987   also disapprove electronic work orders when necessary. In such a case, the COMMENTS field is automatically
4988   mailed to whoever entered the work order, along with the information that their request has been disapproved.
4989
4990   IT Equipment Tracking
4991   The IT Equipment Module allows IT personnel to view and update the non-
4992   expendable equipment inventory for IT equipment. It allows IT staff to assign



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
4993   responsibility for IT equipment to individuals and allows individuals to sign
4994   electronic hand receipts for the assigned equipment.
4995
4996   IT equipment is identified based on the CMR (EIL) field. If an equipment item is ona CMR with IT TRACKING equal
4997   to YES, the equipment is considered tracked IT equipment. The CMR File Enter/Edit [ENCMR] option can be used by
4998   Acquisition & Materiel Management (A&MM) to edit the IT TRACKING field.
4999
5000   Only tracked IT equipment can be edited using the Inventory Edit (IT) option. All tracked IT equipment is expected to
5001   be assigned to individual IT owners. The IT Equipment Tracking module is tightly coupled with the Equipment
5002   Management module.




5003
5004                                                        Figure: 3.2-16
5005
5006   3.2.12 EAS-Enrollment Application System
5007   Enrollment Application System (EAS) is currently a single module application. It facilitates the processing of the 10-
5008   10EZ Application for Health Benefits, which has been transmitted to the VHA site from the On-Line 10-10EZ web-
5009   based software.
5010
5011   This 10-10EZ module allows site staff with enrollment and registration responsibilities to review all data entered by a
5012   veteran on the electronic 10-10EZ form before committing the data to the site database. It also provides a basic
5013   tracking mechanism in order to follow the progress of the veteran’s application and respond to specific inquiries.
5014
5015   Features
5016    Automatically receives incoming 10-10EZ data transmissions from the Web-based application into a VistA
5017        holding file.
5018    Provides a List Manager interface that allows the enrollment/registration staff to:
5019   Match the Applicant with an existing Patient record when appropriate.
5020   Review all 10-10EZ data and perform corrections as needed.
5021   Print the 10-1 0EZ form with data in order to send to the veteran for signature.



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
5022   Verify that the veteran has signed the 10-10EZ.
5023    Commits 10-10EZ data to the VistA Patient database in preparation for further enrollment and/or registration
5024        activities.
5025    Responds to customer (e.g., veteran) inquiries as to the status of a 10-10EZ Application.
5026    Provides an audit trail of all significant actions performed in processing a 10-10EZ Application as a basis for
5027        management reports.
5028    Retains a copy of any original Patient database data elements overwritten by incoming 10-10EZ data elements.
5029




5030
5031                                                      Figure: 3.2-17
5032
5033   3.2.13 Equipment/ Turn-In Request
5034   The Equipment Request/ Turn-In Module Version 1.0, will provide support to a variety of administrative activities in
5035   your medical center concerning your non-expendable equipment requests and any equipment turn-ins.
5036
5037   Functionally, the Equipment/Turn-In module has several organizational elements that use different components of
5038   the software.
5039   • Requestor
5040   • Consolidated Memorandum of Receipt (CMR)
5041   • Personal Property Manager (PPM)
5042   • Engineering
5043   • Other Concurring Officials
5044   • Equipment committee
5045   • Warehouse



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
5046
5047   Each organizational element has a different function with some overlapping components. Each of these elements
5048   interact and rely upon each other for the smooth flow and completion of equipment requests and turn-ins.
5049




5050
5051                                                      Figure: 3.2-18
5052
5053   3.2.14 Event Capture
5054   The Event Capture GUI software provides a consistent, event driven, windows style, user interface for Event
5055   Capture. The GUI captures all the utilization data that is presently available in Event Capture.
5056
5057   The Event Capture GUI software provides a mechanism to track and account for procedures and delivered services
5058   that are not handled in any other VistA package. The procedures and services tracked through Event Capture are
5059   associated with the following:
5060   • The patient to whom they were delivered
5061   • The provider requesting the service or procedure
5062   • The DSS Unit responsible for delivering the service
5063
5064   DSS Units typically represent the smallest identifiable work unit in a clinical service at a medical center and are
5065   defined by the VAMCs. A DSS Unit can represent any of the following:
5066   • An entire service
5067   • A section of a service
5068   • A small section within a section
5069   • A medical equipment item used in patient procedures
5070
5071   For every DSS Unit, each of the following must be defined:
5072   • Service - The service associated with the DSS Unit.
5073   • Cost Center - Fiscal identifier for the service using the particular DSS Unit (Cost Centers are defined in detail in
5074       the MP4-Part V Appendix B of the Fiscal Service cost manuals.)


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5075   •   Medical Specialty - The specialty section associated with the DSS Unit.
5076
5077   Functions of the Software
5078   Event Capture with all patches installed provides the following functions:
5079   • Allows each VAMC to utilize the software for its own resource/costing needs
5080   • Implements DSS Units
5081   • Assigns user access
5082   • Allows single and batch data entry for patient procedures
5083   • Generates reports for workload and other statistical tracking
5084   • EC*2*25 is the first ECS GUI patch. It:
5085      o Provides a Graphical User Interface to the ECS application.
5086      o Allows user to upload patient encounter data to Event Capture from a spreadsheet.
5087      o Allows user to switch between CPRS and ECS via the use of a hot button in the tools menu of either
5088           application.




5089
5090                                                      Figure: 3.2-19
5091
5092




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5093   3.2.15 Fee Basis
5094   A veteran is authorized Fee Basis care if s/he is legally eligible for such care and VA facilities are not feasibly
5095   available to meet the patient's medical needs. The authorization may be for non-VA hospitalization, community
5096   nursing home care, short term care, ID card status for ongoing outpatient care, or for home health services which
5097   authorize home health visits only. Veterans authorized Fee Basis care may be reimbursed for:
5098   • Travel expenses from their home to the fee provider
5099   • Prescription services in emergent situations
5100   • Non-VA hospitalization and outpatient care
5101
5102   Following are the main features of the Fee Basis package.
5103   • Ability to perform the entire fee for service process from entering patient authorizations and vendors to
5104       transmitting completed batch data to Austin for payment.
5105   • Quick, easy, and accurate access to a patient's payment history.
5106   • Completion of previously repetitive actions.
5107   • Efficient administration of the Hometown Pharmacy program.
5108   • Ability to set up authorizations for Community Nursing Home and Contract Hospital, and process payments for
5109       services provided.
5110   • Processing of payments ancillary to Contract Hospital and unauthorized inpatient claims.
5111   • Establishing a fee schedule and a pricer check for payment of medical claims.
5112
5113   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
5114   integrated with the 1358 module of IFCAP. When outpatient batches are released for payment, there will be a posting
5115   to the appropriate 1358. For inpatient batches, the estimated amount from the VA Form 10-7078, as well as the
5116   actual amount, will be posted to the 1358 when batches are released for payment. The Fee Basis package interfaces
5117   with the ADT (Admission-Discharge-Transfer) DHCP module of the PIMS (Patient Information Management System
5118   (formerly MAS)) package to provide users access to registration data entered through ADT options. It also integrates
5119   with the IB (Integrated Billing) package for patient insurance data. Integration with CPT V. 5.0 allows for entry of
5120   modifiers for CPT codes. Integration with the Patient Treatment File (PTF) allows for the creation of Non-VA PTF
5121   Records.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5122
5123                    Figure: 3.2-20
5124




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5125   Fee Basis - (Component diagram)
5126
                           cmp Fee Basis

                                            Fee Basis




                                                «interface»
                                                    FB                          Austin Pricer System




5127
5128                                                       Figure: 3.2-21
5129
5130   3.2.16 FFP-Fugitive Felon Program
5131   The purpose of Patch DG*5.3*485 is to provide the functionality in support of PL 107-103, Section 505.
5132
5133   Public Law (PL) 107-103, Section 505, prohibits provision of certain benefits to veterans or their dependents that are
5134   classified as fugitive felons. This law requires VA to provide current address information, upon written request, to any
5135   Federal, State, or local law enforcement official, if s/he:
5136   • Provides information required to fully identify the person
5137   • Identifies the person as being a fugitive felon
5138   • Certifies that apprehending such person is within the official duties of such official
5139
5140   This project software provides the following functionality for VHA implementation:
5141   • Adds several fields to the VISTA Patient File to store the Fugitive Felon Flag and track when the flag was
5142       entered and removed
5143   • Creates a new security key to control access to the Fugitive Felon Flag and the associated menu options
5144   • Provides menu options that allow users to set and clear the Fugitive Felon Flag, and to print the various reports
5145       associated with the new fields
5146   • Displays user alert from Scheduling and Registration options




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
5147
5148                                                      Figure: 3.2-22
5149
5150   3.2.17 GCS-Generic Code Sheet
5151   The Generic Code Sheet package is a Decentralized Hospital Computer Program (DHCP) software module which
5152   manages the input, editing, deletion, and transmission of code sheets from a local hospital computer system to a
5153   centralized computer system as defined by the code sheet.
5154
5155   The Generic Code Sheet package contains a code sheet file, GENERIC CODE
5156   SHEET (#2100), to be used to define field definitions to support the code sheets. The field definitions describe the
5157   type of data to be stored in the actual code sheet. The fields can be arranged in an input template in the order they
5158   will be used to create the code sheet.
5159
5160   Once the code sheet data has been created, the code sheets can be marked for batching. Batching the code sheets
5161   will group like code sheets together for transmission. When the code sheets are transmitted, all code sheets within
5162   the batch will be transmitted in the same VA MailMan message. The exception to this is the Financial Management
5163   System (FMS) code sheets. When the FMS code sheets are created they are queued for transmission using the
5164   GENERIC CODE SHEET STACK file (#2100.1), thus bypassing the batching process. The code sheets are
5165   transmitted from the stack file by a background VA TaskManager job which can be run every 2 hours, 3 hours, etc.
5166   as specified by the systems manager.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5167
5168                    Figure: 3.2-23
5169
5170




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5171   3.2.18 HEC-Health Eligibility Center
5172   Health Eligibility Center (HEC) v. 1.0
5173
5174   Description:
5175   The Health Eligibility Center (HEC) supports VA's health care enrollment system while providing centralized eligibility
5176   verification and determination services. This office supports VA by verifying veterans' eligibility and processing
5177   enrollment applications. The HEC supports, coordinates, and implements VHA's financial assessment process,
5178   consolidating financial eligibility determinations for VA health care.
5179
5180   The HEC also:
5181   • Conducts VHA's income verification process for veterans whose financial assessments exempt them from medical
5182   care co-payments
5183   • Validates Social Security numbers from the Social Security Administration
5184   • Verifies income from the Internal Revenue Service and the Social Security Administration
5185   • Receives information from VBA to determine Veterans’ eligibility and enrollment assignment
5186   • Implements information system enhancements to support CBO vision of application, eligibility and enrollment
5187   processing
5188   • Assists in the maintenance of the Enrollment Database by performing data management functions focused on
5189   improving the integrity of veterans' personal, eligibility, and financial information
5190   • Is the authoritative source and Data Steward for Demographic, Eligibility, and Enrollment data. This does not
5191   include Patient Identity elements.
5192   • Provides Business oversight to all software products related to Registration, Eligibility and Enrollment.
5193
5194   The HEC recently deployed Enrollment System Redesign (ESR) version 3.0, the HealtheVet replacement system for
5195   the current product known as HEC Legacy. This expert system gathers information obtained from VistA, VBA, and
5196   the HEC staff to determine and communicate verified medical benefits eligibility and enrollment (E&E) information for
5197   all veterans and beneficiaries. For every exception where the expert system process cannot make a determination,
5198   “cases” are created for human intervention. HEC staff utilizes ESR to manage these “cases” to completion so that
5199   verified E&E can be determined.
5200
5201   The HEC, located in Atlanta, GA, receives patient-reported Means Test data from the VistA 1.0 Income Verification
5202   Match (IVM) module. HEC compares the extracted data with earned and unearned income data retrieved from Social
5203   Security Administration (SSA) and Internal Revenue Service (IRS). Patients with reported income in the mandatory
5204   category, but whose actual income has been proven to be above that level, will have their eligibility for health care
5205   changed to the discretionary category and are subject to back billing.
5206
5207   The HEC sends the updated demographic and insurance information to the medical facilities for upload. The IVM
5208   module allows the HEC data to be compared with locally collected data and selectively uploaded. Local revenue staff
5209   may then send healthcare claims to insurance companies for treatment rendered to patients who had not previously
5210   reported health insurance coverage. Updated and verified income information from the HEC is automatically
5211   uploaded upon receipt at each VA facility, which updates the veteran’s eligibility for health care and creates co-
5212   payment charges for previous episodes of care.
5213
5214   Programming Language:



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5215   J2EE
5216   Spring Framework
5217   Struts Framework
5218   Hibernate Framework
5219   JRules
5220
5221   Deployment Infrastructure:
5222   WebLogic Server
5223
5224   Depends On:
5225   VistA 1.0
5226   FileMan
5227   Income Verification Match (IVM)
5228   MailMan
5229   VistA 1.5
5230   Person Service Identity Management (PSIM)
5231   VA Enrollment System (VES)
5232   External Entities
5233   Social Security Administration (SSA)
5234   Internal Revenue Service (IRS)
5235
5236   The following entities depend on Health Eligibility Center (HEC):
5237   VistA 1.0
5238   Research pending
5239   External Entities
5240   Social Security Administration (SSA)
5241   Internal Revenue Service (IRS)
5242   VistA 1.5
5243   Person Services Identity Management (PSIM)
5244   Master Patient Index (MPI)
5245   Centralized Data Repositories
5246   Administrative Data Repository (ADR)
5247
5248   For more information, reference:
5249   VA Software Document Library (VDL): http://www.va.gov/vdl/application.asp?appid=143
5250   Office of Enterprise Development (OED) Project Repository:
5251   HEC Redesign – Version 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=504
5252   HEC Redesign – Version 2 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=602
5253   HEC Redesign – Version 3 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=737
5254   HEC VistA Enhancements (HVE) Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=843
5255   HEC HL7 Upgrade Phase 1 Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=359
5256   Enrollment System Redesign (ESR) – Version 3.0 Project Notebook:
5257   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=884
5258   Enrollment System Redesign (ESR) – Version 3.1 Project Notebook:



       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5259   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1174
5260   Enrollment System Redesign (ESR) – Version 3.2 Project Notebook:
5261   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1275
5262   Enrollment System Redesign (ESR) – Version 3.3 Project Notebook:
5263   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1286
5264   Enrollment System Redesign (ESR)-V4.0 IVM Workflow Project Notebook:
5265   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1030
5266   Enrollment VistA Changes (EVC) Early Release Project Notebook:
5267   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1009
5268   Enrollment VistA Changes (EVC) Release 1 Project Notebook:
5269   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=951
5270   Enrollment VistA Changes (EVC) Release 2 Project Notebook:
5271   http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=982
5272   Enrollment Priority 8 Enhancements Project Notebook: http://tspr.vista.med.va.gov/warboard/anotebk.asp?proj=1292
5273   VistA Enrollment Database Standards and Procedures:
5274   http://tspr.vista.med.va.gov/warboard/ProjectDocs/HEC_Redesign_V1/HEC%20Redesign%20Database%20Stds%2
5275   0&%20Procs.doc#_Toc517162753
5276   Enrollment System Redesign Project Overview:
5277   http://tspr.vista.med.va.gov/warboard/ProjectDocs%5CEnrollment_System_Redesign_Ver_3.0%5CESR%20Overvie
5278   w%208-23-2005.pdf
5279   Corporate Databases Monograph (2009): http://vaww.va.gov/NDS/CorporateDatabasesMonograph.asp
5280   Health Eligibility Center (HEC) Homepage: http://vaww.va.gov/hec/
5281




       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap          Page 3-2
5282
5283                                                      Figure: 3.2-24
5284
5285   HEC-Health Eligibility Center - (Component diagram)
5286
                                cmp HEC-Health Eligibility Center

                                       «interface»
                                                                     HL7 Error Messages to
                                           HL7
                                                                     VAMCs

5287
5288                                                      Figure: 3.2-25
5289
5290   3.2.19 HINQ-Hospital Inquiry
5291   The Hospital Inquiry (HINQ) module provides the capability to request and obtain veteran eligibility data via the VA
5292   National Telecommunications Network. Individual or group requests are sent from a local computer to a remote
5293   Veterans Benefits Administration (VBA) computer where veteran information is stored. The VBA network that
5294   supports HINQ is composed of four computer systems located in regional VA payment centers.
5295   HINQ interfaces with other modules to allow users to make eligibility requests. An on-line suspense file stores
5296   requests for later transmission and records HINQ responses, thus creating a log of HINQ activity.
5297



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
5298   The HINQ module provides facilities with the ability to obtain veteran eligibility information quickly, accurately, and
5299   efficiently, allowing medical center personnel to act expeditiously on patient requests for medical treatment and other
5300   benefits. Additionally, returned HINQ data may be loaded directly into the local Patient file through various screens.
5301   The screens display both the data in the HINQ message and what is currently in the Patient file for comparison.
5302
5303   Features
5304   • Sends on-line requests individually and forwards multiple requests in a batch mode.
5305   • Tracks and updates various requests from customer.
5306   • Establishes ‘real-time’ links between VHA and VBA computers to service time-of-the-essence requests.
5307   • Processes routine requests in background, allowing the requester to perform other tasks.
5308   • Alerts the requester when responses are received from VBA computers.
5309   • Alerts the requester when there is a discrepancy found between the returned HINQ information and what is in
5310       the Patient file.
5311   • Provides the capability to update returned HINQ data directly into the Patient file.




5312
5313                                                       Figure: 3.2-26
5314
5315




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
5316   HINQ-Hospital Inquiry - (Component diagram)
5317
                cmp HINQ-Hospital Inquiry



                      HINQ-Hospital Inquiry



                                  «interface»                   Veterans Benefits Administation (VBA) via
                                     DVB                        Austin Automation Center (AAC)



5318
5319                                                       Figure: 3.2-27
5320
5321   3.2.20 ICD-9-CM
5322   The International Classification of Diseases, Clinical Modification (ICD-9-CM) is a clinically-modified statistical
5323   classification system that arranges diseases and injuries into groups according to established criteria. It is based on
5324   the ICD-9, which was designed for the classification of morbidity and mortality information for statistical purposes,
5325   and published by the World Health Organization (WHO). These codes provide an effective means of communication
5326   between physicians, patients, and third parties.
5327
5328   Lexicon service provides the software to update the ICD files. ICD–9-CM consists of the following components:
5329    A tabular list containing a numerical list of disease code numbers.
5330    An alphabetical index to the disease entries.
5331    A classification system for surgical, diagnostic, and therapeutic procedures as defined by WHO.
5332    Use of ICD-9-CM codes is approved by Centers for Medicare and Medicaid Services (CMS).
5333
5334   Updates to these codes are released in the Federal Register by CMS in May/June of each year. These code updates
5335   include changes to the codes and code narratives. An electronic version of the updates is released by CMS in
5336   September, which must go into effect on October 1st of each year. CMS has a benchmark of 30 days beyond the
5337   effective date of October 1st for implementing these updates.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
5338
5339                                                     Figure: 3.2-28
5340
5341   3.2.21 IFCAP-Integrated Funds Distribution, Control Point Activity, Accounting, and Procurement
5342   Integrated Funds Distribution, Control Point Activity, Accounting and Procurement (IFCAP) module automates a
5343   spectrum of VA financial activities. VA employees use IFCAP to manage budgets, order goods and services,
5344   maintain records of available funds, determine the status of a request, compare vendors and items to determine the
5345   best purchase, record the receipt of items into the warehouse, and pay vendors. IFCAP automates the written
5346   regulations and policy for VA funding and procurement, which define the actions taken on requests for goods and
5347   services as formal transactions, orders, and payments.
5348
5349   Features
5350        Allows users in different services to view the same document on-screen.
5351        Automates funds distribution, request for goods and services, purchase order, funds obligation, and the
5352           receipt process.
5353        Standardizes funds management. Automatically generates yearly budget elements for IFCAP control points.
5354        Maintains year-to-date balance for control points. Integrates service-level requisitions and facility
5355           administrative activities, and updates service-level records.
5356        Shares vendor and item master data to eliminate duplicate input and promote user accuracy.
5357        Affixes processing status to each request at each step in the ordering cycle. Enhances security with the use
5358           of a unique electronic signature code for each user required to authorize an action.
5359        Sets an encoded value based on key fields from each record signed.
5360        Transmits financial and inventory data to VA central accounting and inventory systems.
5361        Updates IFCAP records automatically with central accounting system data.
5362        Provides various reports that give the current status of any request, a service fund balance, data required
5363           for budget analysis, and a listing of requests sorted according to control point specifications.
5364        Enables electronic transmission of purchase orders to vendors through Electronic Data Interchange (EDI).
5365        Updates purchase order status automatically.
5366        Enables authorized users to purchase goods using Electronic Data Interchange (EDI) process for total
5367           electronic processing between vendor and buyer.
5368        Supports the ordering of goods under contract from specific vendors via delivery orders.
5369        Supports the payment for goods/services via the government purchase card and the subsequent on-line
5370           reconciliation.


       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap           Page 3-2
5371          Transmits Federal Procurement Data System (FPDS) data to the Austin Information Technology Center
5372           (AITC) to support enterprise level tracking of procurement history.
5373          Supports monthly management analysis activities by transmitting inventory and purchase order activity data
5374           to the Clinical Logistics Report Server at AITC.
5375          Supports, via a graphical tool, the reviewing of purchase order activity and other logistical data within
5376           IFCAP; and the export of that data to MS Excel spreadsheets for further analysis.
5377          Supports both the identification of items by their National Item File number (NIF #) and the standardized
5378           naming of Items through an interface between IFCAP and the National Item File.
5379          Transmits inventory and purchase order activity data to the Clinical Logistics Report Server on a monthly
5380           basis for management analysis.
5381
5382   · Inventory management features:
5383         Defines desired stock levels of items.
5384         Automatically generates (autogen) replenishment orders.
5385         Dispenses goods to supported services or end users.
5386         Identifies items via bar code technology.
5387         Supports communication of inventory information between a secondary inventory point and its associated
5388            automated supply cabinet(s).
5389         Produces reports displaying inventory level, distributions, and dollar values.
5390         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-2
5391
5392                    Figure: 3.2-29
5393




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5394   IFCAP - (Component diagram)
5395
        cmp IFCAP



               IFCAP-Integrated Funds Distribution, Control Point
                    Activ ity, Accounting, and Procurement

                                                          «interface»
                                                             PRC                    Austin (LOG,GSA,DLA)

                                                                                    DynaMed

                                                                                    Finacial Management System (FMS)




5396
5397                                                      Figure: 3.2-30
5398
5399   3.2.22 Incident Reporting
5400   The Incident Reporting module supports VHA policy by compiling data on patient incidents. It organizes the data into
5401   defined categories for reporting and tracking at medical facility level and for transmission to the National Quality
5402   Assurance Database for Headquarters review and tracking.
5403
5404   Features
5405   • Provides options to simplify the setup of the software.
5406   • Allows for the entry of all required incident information plus descriptive data and actions taken on all reportable
5407       and/or locally defined incidents.
5408   • Prints out a Pseudo 10-2633 Incident Worksheet.
5409   • Provides an ad-hoc reporting mechanism that uses VA FileMan modifiers for sorting or printing the following data
5410       fields:
5411            Patient                               Type of Death
5412            Patient ID                            Level of Review
5413            Date of Admission                     Date of Incident
5414            Patient Type                          Incident Case Status
5415            Ward/Clinic                           Severity Level
5416            Treating Specialty           Fall Assessment Score
5417            Service                      Person Reporting the Incident
5418            Responsible Service          Patient Diagnosis
5419            Medication Errors                     Medical Center Action
5420            Case Number                           Incident Description
5421            Incident                              Pertinent Information
5422            Incident Location                     National Case Status




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5423
5424                                                      Figure: 3.2-31
5425
5426   3.2.23 IVM-Income Verification Match
5427   The Income Verification Match (IVM) module is designed to extract patient-reported Means Test data and transmit it
5428   to the Health Eligibility Center (HEC) located in Atlanta, Georgia. IVM allows Veterans Health Administration (VHA) to
5429   accurately assess a patient’s eligibility for health care when the eligibility criterion is income-based.
5430
5431   IVM electronically transfers patient income and demographic data for eligible veterans whose VA health care is
5432   based on income and for whom a Means Test has been completed. It also sends automatic updates if pertinent
5433   patient data is edited at the medical center.
5434
5435   As part of this process, HEC compares the extracted data with earned and unearned income data retrieved from
5436   Social Security Administration (SSA) and Internal Revenue Service (IRS). Patients with reported income in the
5437   mandatory category, but whose actual income has been proven to be above that level, may have their eligibility for
5438   health care changed to the discretionary category and are subject to back billing.
5439
5440   The HEC sends the updated demographic information to the medical facilities for upload. The IVM module allows the
5441   HEC data to be compared with locally collected data and selectively uploaded. As a result of the income verification
5442   process performed by the HEC, an updated means test is transmitted to the VA facility, which updates the veteran’s
5443   eligibility for health care and creates co-payment charges for previous episodes of care. The software provides
5444   inquiries and reports that track all IVM activity.
5445
5446   Features
5447    Transmits data for basic demographics, next-of-kin, income, temporary address, eligibility, guardian, military
5448       service, and employer information to the HEC for patients who are entered into the VAMC database.
5449       Automatically transmits an updated message if this information is changed.
5450    Allows the HEC to query the medical facility for the most up-to-date patient information.
5451    Allows updated demographic and insurance information from the HEC to be uploaded into the patient’s record.
5452    Automatically loads updated income information from the HEC (including IVM Converted financial tests) and
5453       updates the veteran’s eligibility for health care.
5454    Allows generation of status inquiries, statistical Means Test, and data transmission reports.
5455



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5456
5457                    Figure: 3.2-32
5458
5459




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5460   IVM-Income Verification Match - (Component diagram)
5461
                             cmp IVM-Income Verification Match



                                    IVM-Income
                                  Verification Match




                                        «interface»
                                            IVM                        Health Eligibility Center




5462
5463                                                      Figure: 3.2-33
5464
5465   3.2.24 IB-Integrated Billing
5466   Following is an overview of the major functions of the Integrated Billing software, excluding the Encounter Form
5467   functionality. That information can be found in the IB User Manual, Encounter Form Utilities Module.
5468
5469   The release of Integrated Billing (IB) version 2.0 introduces fundamental changes to the way MCCR-related tasks are
5470   done. This software introduces three new modules: Claims Tracking, Encounter Form Utilities, and Insurance Data
5471   Capture.
5472
5473   There are also significant enhancements to the two previous modules, Patient Billing and Third Party Billing. IB has
5474   moved from a package with the singular purpose of identifying billable episodes of care and creating bills, to a
5475   package responsible for the whole billing process through to the passing of charges to Accounts Receivable (AR).
5476   Functionality has been added to assist in capturing patient data, tracking potentially billable episodes of care,
5477   completing utilization review (UR) tasks, and capturing more complete insurance information.
5478
5479   This version of IB has been targeted for a much wider audience than previous versions.
5480    The Encounter Form Utilities module is used by MAS ADPACs or clinic supervisors to create and print clinic-
5481       specific forms. Physicians use the forms and consequently provide input into their creation.
5482    The Claims Tracking module is used by UR nurses within MCCR and Quality Management (QM) to track
5483       episodes of care, do pre-certifications, do continued stay reviews, and complete other UR tasks.
5484    Insurance verifiers use the Insurance Data Capture module to collect and store patient and insurance carrier-
5485       specific data.
5486    The billing clerks see substantial changes to their jobs with the enhancements provided in the Patient Billing and
5487       Third Party Billing modules.
5488




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
5489   Patient Billing
5490    automates billing of pharmacy, inpatient, nursing home care unit (NHCU), and outpatient copayments; inpatient
5491       and NHCU per diem charges; and passing charges to Accounts Receivable (AR).
5492    automatically exempts patients who are eligible for VA Pension, Aid and Attendance, or House Bound benefits
5493       from the Medication Copayment requirement.
5494    provides for manual assignment of hardship exemptions from the copayment requirement and the ability to track
5495       those exemptions.
5496    integrates with the checkout functionality released in the PIMS V. 5.3 package. Patients who claim exposure to
5497       Agent Orange and environmental contaminants, and who are treated for conditions not related to this exposure,
5498       are billed automatically.
5499    allows patient charges to be added, edited, or deleted if there is no automated charge or the automated charge
5500       is incorrect.
5501    creates subsistence charges for CHAMPVA patients and passes to Accounts Receivable. This functionality will
5502       not be activated until the AR package releases a patch that allows AR to process CHAMPVA receivables.
5503    allows Means Test billing data to be transmitted between facilities in conjunction with PDX V. 1.5.
5504    automatically creates Means Test charges when a verified Means Test is electronically received from the Income
5505       Verification Match (IVM) Center.
5506
5507   Third Party Billing
5508    automates the creation of third party billing forms (UB-82, UB-92, HCFA-1500), allowing for the entry, editing,
5509       authorizing, printing, and canceling of bills.
5510    provides the ability to add prescription refills and prosthetic items to bills.
5511    expands the UB-92 functionality to include ability to add/edit all unlabeled form locators (except 49), additional
5512       diagnosis, some occurrence spans, and value codes.
5513    provides a check-off sheet (can be replaced by the Encounter Form depending on local needs) that can be
5514       printed in a variety of site configurable formats to be used in clinics to identify CPT codes.
5515    allows the transfer of CPT codes between the billing screens and the SCHEDULING VISITS file.
5516    provides reports to identify billable episodes of care, patient and insurance inquiries, and statistical data.
5517    provides the ability to create CHAMPVA bills. You will not be able to pass them to Accounts Receivable until the
5518       AR package releases a patch that allows AR to process CHAMPVA receivables.
5519    provides an employer report, which lists uninsured patients who are employed.
5520    allows printing of all authorized bills in user-specified order.
5521    provides an Automated Biller which will automatically generate reimbursable insurance bills for inpatient stays,
5522       outpatient visits, and prescription refills. Through the use of site parameters, sites can specify what types of
5523       events are billed using the Automated Biller.
5524    provides an expanded HCFA-1500 claim form to include inpatient bills, user-specified charges, and multiple
5525       pages.
5526    provides an addendum sheet to HCFA-1500 claim form to list the bill's prescription refills and prosthetic items.
5527
5528   Insurance Data Capture
5529    stores multiple addresses (main mailing, outpatient claims, inpatient claims, prescription claims, appeals,
5530       inquiries) for each insurance carrier.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
5531      provides insurance company-specific billing parameters so bills can reflect local insurance company
5532       requirements.
5533      provides the ability to establish group plans which will be pointed to by each patient with a policy attached to the
5534       plan. This saves re-entry of the same policy data for each patient.
5535      stores annual benefits associated with group plans.
5536      provides tools to maintain and/or clean up the INSURANCE COMPANY file.
5537      allows patient insurance information to be updated and verified.
5538      stores benefits used by a patient, such as deductibles and lifetime maximums.
5539      provides an insurance worksheet for use by the insurance verifier.
5540
5541   Claims Tracking
5542    provides the ability to track billing information concerning inpatient visits, outpatient visits, prescription refills,
5543       prosthetics, and fee basis visits from time of event until payment.
5544    provides a pending review (to do ) list.
5545    introduces an Admission Sheet which can be placed in the front of the inpatient chart and used to document
5546       concurrent reviews.
5547    provides the feeding mechanism for automated bill preparation of third party bills.
5548    provides tracking of those cases requiring utilization review by VA Central Office (VACO) Quality Management
5549       (QM) office based on Interqual criteria.
5550    provides tracking of those cases where the insurance company requires reviews.
5551    provides tracking of appeals and denials.
5552    provides U/R management reports.
5553
5554   Additional Functionality
5555    purges data from selected IB files.
5556    provides the medical centers flexibility in implementing the package functionality through site parameters.
5557    provides the ability to enter new billing rates and VA pension income thresholds.
5558    produces management reports to provide workload, productivity, statistical, and historical data.
5559
5560   Related materials include the IB User Manual, Encounter Form Utilities Module; IB Technical Manual; Package
5561   Security Guide; Installation Guide; and Release Notes. The Technical Manual assists the site manager in
5562   maintenance of the software. The Package Security Guide provides information concerning security requirements for
5563   the package. The Installation Guide provides assistance in installation of the package while the Release Notes
5564   describe modifications and enhancements to the software that are new to this version.
5565
5566   Features
5567    Tracks events requiring insurance company reviews from the time of the actual event until final payment is
5568       resolved.
5569    Provides the ability to setup insurance companies and insurance plans and to store all relevant data associated
5570       with each of the group or individual plans.
5571    Provides the ability to enter and maintain each patient’s insurance data.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
5572      Automates the creation of bills for patient charges for prescriptions, inpatient and outpatient co-payments, and
5573       long term care co-payments. For medication co-payments, it tracks charges billed to a veteran at all sites to
5574       ensure that the annual maximum billing cap is not




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
5575
5576                    Figure: 3.2-34
5577




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5578   3.2.25 Integrated Patient Funds
5579   The PFOP system is a computerized program that manages the private finances of Veterans Administration patients.
5580   The material to be stored in this system is the same information you’ve probably recorded on VA Form 10-1083, the
5581   Patient Account Card. Once installed, the PFOP system will accept information that you enter into your computer
5582   terminal, eliminating the need to record information on the form.
5583
5584   This package includes options used to enroll patients in the system; options used to process system transactions;
5585   and options used to print reports about system transactions. The PFOP system accepts information about only those
5586   patients who are REGISTERED WITH YOUR HOSPITAL. Only after Medical Administration Services REGISTERS a
5587   patient -- in other words, ADMITS a patient to your hospital and ENTERS the patient into the Patient file -- will you be
5588   able to enroll the individual in the PFOP System.
5589
5590   The Personal Funds of Patients (PFOP) System automates a number of patient funds tasks - from enrolling new
5591   patient accounts, for example, to processing account transactions and printing reports about account transactions.
5592   What the system does, essentially, is electronically manage the private finances of VA hospital patients.
5593
5594   The objective of PRPF*3.0*15 (Diagnostic Patch 15) is to allow sites to diagnose and resolve as many issues as
5595   possible before they migrate from VistA legacy Personal Funds of Patients (PFOP) to the Veterans Personal Funds
5596   System (VPFS). Install and use Diagnostic Patch 15 well in advance of your actual data migration date to allow time
5597   to run the diagnostic routine, review the reports, and make corrections in the M environment repeatedly to narrow
5598   down the count of errors. Although it is desirable, you do not need to cleanse your data 100%. It is important,
5599   however, to correct any data that violates the rules imposed by the FileMan data dictionary’s input transform for a
5600   field. Such data errors could cause the migration process to fail. For example, if the input transform says a field must
5601   be between 3 and 30 characters, but the actual data is 40 characters, this error should be corrected.
5602
5603   Functional Description
5604   The PFOP system electronically manages money held for patients hospitalized at VA facilities. The system’s
5605   foundation is the Patient Funds account. Essentially, the Patient Funds account operates much like a checking
5606   account; however, the money in a Patient Funds account does not accrue interest and, in some cases, restrictions
5607   limit the amount of cash patients may withdraw in a given time period. While using the PFOP system, you’ll perform
5608   tasks that closely resemble the banking activities required to maintain checking accounts. Along with your
5609   supervisory duties, you’ll be called upon to perform the three basic PFOP system functions that follow.
5610
5611   Establish Patient Funds Account
5612   A Patient Funds account can be opened for any individual listed in both the Patient file (# 2) and the Patient Funds
5613   file (# 470). Your facility’s Patient file stores the patient name, social security number, pertinent addresses used by
5614   the PFOP system, and any additional medical information about a patient. Your facility’s Patient Funds file stores
5615   data associated with the PFOP system (e.g., account balance, restrictions, etc.).
5616
5617   Post Transactions
5618   You may electronically post deposits to Patient Funds accounts and post withdrawals from Patient Funds accounts.
5619   You will also have on-line access to the current balances of all Patient Funds accounts and to all of the transactions
5620   involving those accounts.
5621



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
5622   Reconcile Accounts and Reports
5623   Several reports are provided that can be used to help reconcile accounts with Fiscal Service. When generating these
5624   reports, you’ll be able to select any one of several formats designed to meet the needs of a variety of users.
5625
5626   Features
5627    Shares patient account data to eliminate duplicate input and promote accuracy.
5628    Records deposits and withdrawals.
5629    Promotes security with the use of unique electronic signature codes.
5630    Allows withdrawal restrictions for designated patients.
5631    Allows users (e.g., patient funds clerk and agent cashier) to view the same information on-line.
5632    Allows reconciliation of patient funds records with Fiscal Service.
5633    Provides varied reports with the current status of patient accounts, summary transaction information, restriction
5634       lists, and suspense files.
5635




5636
5637                                                         Figure: 3.2-35
5638
5639   3.2.26 Library
5640   The purpose of the Library package at the local VA Medical Center is to facilitate the automation of manual serial title
5641   check-in and distribution, the integration of scattered data into a single title record, and the extension of on-line staff
5642   access to holdings and services.
5643
5644   The purpose of the Library package on FORUM is to maintain centralized data integrity and to allow for the request of
5645   Interlibrary Loan items.
5646
5647   Library V. 2.5 provides support to a variety of administrative activities in a VA Medical Center concerning serials. As
5648   the name implies, the Librarians will be the greatest users of this software and will reap the greatest benefits.
5649   Patients can also benefit from the Library package through Interlibrary Loan.
5650
5651   Functionally, the Library module has three organizational elements that reside as different components of the
5652   software. The three functional components are:
5653   • Interlibrary Loan on FORUM



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                Page 3-2
5654   • Serials Authority Files on FORUM
5655   • Serials Processing at local medical center libraries
5656
5657   Library Package on FORUM
5658   The FORUM module of the Library package serves several major needs.
5659   1) Maintain basic serial information
5660   2) Allow interlibrary loan of materials
5661   3) Maintain listings of networked audiovisuals
5662
5663   The first feature of the programs on FORUM allow the National Librarians to input and maintain consistent
5664   information on serials. Serial titles are entered specifying pertinent information about the serial such as title,
5665   frequency of issue, etc. Once the serial has been entered into the Library module on FORUM, the local medical
5666   center libraries have the capability of obtaining that information by requesting information about serial titles to be
5667   transmitted to their local files for utilization.
5668
5669   The second feature on FORUM is the ability to request interlibrary loan of materials from one local medical center to
5670   another. Holdings for each library station are maintained on FORUM for this purpose and for updating the National
5671   Library of Medicine's SERHOLD data for their interlibrary loan module, DOCLINE.
5672
5673   Library Package at Local VAMCs
5674   The Library package module at local VA medical centers serves several major needs; checking in serials,
5675   maintaining local holding records, and renewal of serials material. Please review the Library package User Manual
5676   for more information about this module of the Library package.
5677
5678   The Serials Module provides automation of the data needed to manage these collections, exact bibliographic
5679   identification of the item; data on costs, vendors, numbers of copies; the ability to assign routings to titles and
5680   generate the routing slips automatically; a two-key check-in process to speed up the daily workload; and numerous
5681   reports for claims, holdings lists, and statistics.
5682
5683   Journal and magazine titles tend to change name and frequency very often. A major problem with V. 1.2 was the
5684   inability to keep current the database forming the bibliographic record of the serials titles at the local site. For sharing
5685   purposes, it is also important that all libraries use the same form of a serials title.
5686
5687   The significant effort in V. 2.5 has been to devise a method to keep the bibliographic database at the local site always
5688   up-to-date. This has been accomplished by linking a similar, constantly edited file on FORUM to the local site
5689   modules via network mail. When a change is made in a title record at the FORUM level, it can be downloaded to the
5690   local level, where it will overwrite the old bibliographic record without altering any of the specific local data such as
5691   holdings or check-in information. Downloaded records will also carry predication patterns as they are added or
5692   modified. Prediction patterns significantly speed up the daily check-in process.
5693
5694   These major changes in functionality are concentrated in Section E - LTS - Library Title Setup. Other changes in
5695   functionality are found in the following sections.
5696    Section P - HSF - Hospital Service file where the ability to edit this file has been removed.
5697    Section S - CHE - Check-In with information about the predicting ability and the effect of the initialization process



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                 Page 3-2
5698       on titles.
5699
5700   Features of Serials Control module:
5701    Creates a local serials database.
5702    Provides acquisition and retention information.
5703    Provides purchasing and vendor information.
5704    Provides holdings information and shelving location information.
5705    Categorizes by type and subject.
5706    Provides check-in with next issue prediction.
5707    Generates routing slips.
5708    Tracks materials returned from routing.
5709    Displays check-in history.
5710    Generates 20 management reports (e.g., listings, monthly check-in statistics, monthly routing statistics, tracking
5711       of unreturned routed issues, missing issue reports for claiming replacements or reports, etc.).
5712    A centrally produced Title Authority file, a database of over 9,477 serials titles owned by VALNET (VA Library
5713       Network) libraries, was preloaded with standard bibliographic data and provided as a part of this module.




5714
5715                                                       Figure: 3.2-36
5716
5717   3.2.27 Occurrence Screen
5718   The Occurrence Screen package is a fully integrated system which is compatible with V. 7.0 of Kernel and V. 19 of
5719   VA FileMan.
5720
5721   The objectives of the package are to increase efficiency in the documenting of occurrences, permit better trend
5722   analysis, and provide a consistent format for stored data to be used for QM review at the regional and national levels.
5723
5724   There are two major components of this package: the automated capture of occurrences for screening and the
5725   automation of the review process. The software contains programs that do the following.
5726


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
5727   Auto Enrollment
5728   Daily running of the auto enrollment routines populates the Occurrence Screen data base. Auto enrollment is
5729   performed by the Clinical Monitoring System. For further information, please see the Clinical Monitoring System
5730   Technical Manual.
5731
5732   Manual Enrollment
5733   Provides for manual enrollment into the data base of occurrences not captured by the auto enrollment due to data not
5734   being available in the system at this time.
5735
5736   Worksheets
5737   Produces copies of Clinical, Peer, Management, Committee, and worksheets to use in the review process.
5738
5739   Standard reports
5740   Produces reports for trend analysis, including the mandated Semi-Annual report of occurrences.
5741
5742   Ad Hoc reports
5743   Permits the creation of Ad Hoc reports by building sort and print templates on the fly.
5744
5745   This software supports the Occurrence Screening process as described in the VHA (Veterans Health Administration)
5746   circular. It gathers and manipulates data for the following Occurrence Screens.
5747    Readmission within 10 days (Screen 101.1)
5748    Admission within 3 days following unscheduled Ambulatory Care visit (Screen 102)
5749    Return to OR in same admission (Screen 107)
5750    Death (Screen 109)
5751
5752   Provisions are made within the package for the addition of other hospital-specific screens. National screens that
5753   were discontinued through policy changes are listed in the package as "Inactive" but may be made "Local" to
5754   reactivate them. They are as follows:
5755   1. Readmission within 14 days. (Screen 101)
5756   2. Admission within 3 days following Ambulatory Care surgery procedure. (Screen 103)
5757   3. Admission or ASIH from VA Nursing Home Care Unit.
5758            a. Within 14 days of discharge from Acute Care. (Screen 104.1)
5759            b. To Psychiatry Service. (Screen 104.2)
5760   4. Transfer from Intermediate Medicine.
5761            a. Within 14 days of transfer from Acute Care. (Screen 105.1)
5762            b. To Psychiatry Service. (Screen 105.2)
5763   5. Transfer to a Special Care unit within 72 hours of a surgical procedure. (Screen 106.2)
5764   6. Transfer to a Special Care Unit within 72 hours of transfer from a Special Care Unit. (Screen 106.1)
5765   7. Cardiac or respiratory arrest. (Screen 108)
5766
5767   Functional Description
5768   The Occurrence Screen package is a component of the Quality/ Risk Management sub-system within the VistA
5769   (Veterans Health Information Systems and Technology Architecture) system. It is designed to be used as a tool to
5770   accomplish the following.



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap          Page 3-2
5771      Automate the gathering of Occurrence Screen data. This is accomplished by a daily running of the automatic
5772       enrollment routine, which captures screens 101.1, 102, 107 (when site is using the VistA Surgery package) and
5773       109. Refer to the Overview section above for a listing of types of justified exceptions that are excluded by the
5774       software. There is provision for the manual entry of screens if they cannot be or were not auto enrolled from
5775       data currently available in the VistA system.
5776      Provide for the inclusion of hospital-specific screens within the program. These screens must be entered
5777       manually. It also allows continued tracking of the screens that are no longer required.
5778      Automate the creation of clinical, peer, management, and committee worksheets. The findings and/or actions of
5779       the previous review levels can be printed.
5780      Facilitate the tracking of occurrences by means of various tracking reports. An ad hoc report feature is included
5781       for use in trend analysis.
5782      Produce the Semi-Annual Summary of Occurrence Screening.
5783
5784   Features
5785    Provides automatic identification of patients for the following occurrences:
5786           o Readmission within 10 days
5787           o Admission within three days following unscheduled Ambulatory Care visit
5788           o Return to operating room in same admission
5789           o Death anywhere in medical facility, except DNR (Do Not Resuscitate)
5790    Allows for quick entry of exceptions.
5791    Provides a tracking and reporting system (ad hoc) for all screens.
5792    Produces worksheets for clinical, peer, management, and committee-level review.
5793    Tracks patient occurrences through peer and management-level reviews to final disposition.
5794    Relates quality of patient care with provider-specific information.
5795    Tracks problems by provider, systems, and equipment.
5796    Provides required Summary of Occurrence Screening.
5797    Compiles numerous reports, including:
5798           o Occurrences by Service
5799           o Review Level Tracking
5800           o Patients Awaiting Clinical Review
5801           o Delinquent Reviews
5802           o Adverse Findings
5803           o System/Management/Equipment Problems
5804           o Occurrence Screen Service Statistics
5805           o Ad Hoc Report




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5806
5807                                                      Figure: 3.2-37
5808
5809   3.2.28 Patient Representative
5810   This package has three main functions:
5811   • The primary function is the collection and transmission of Time and Attendance (T&A) Report data. The
5812        purpose of this function is to provide an electronic means by which biweekly payroll data can be collected,
5813        processed and transmitted to the Department of Veterans Affairs' Austin Automation Center (AAC) in Austin,
5814        Texas, for the generation of personnel payroll checks. The users accomplish their tasks with seven menus:
5815        Payroll Supervisor Menu, Payroll Main Menu, Timekeeper Main Menu, T&A Supervisor Menu, T&AOT/
5816        Supervisor Menu, Employee Inquiry/ Reports Menu and Employee Menu. These menus are assigned to
5817        authorized users who are responsible for entering,processing or transmitting time and attendance report data to
5818        the AAC.
5819
5820       Any employee with access to the DHCP system may use this package to make leave requests or view their own
5821       leave balances. The manual provides the users with the information necessary to view, enter, and edit time and
5822       attendance report data. The purpose of the time and attendance (T&A) portion of the software is to collect,
5823       process and transmit data necessary to pay employees. The package allows all time and attendance report data
5824       to be posted via a terminal and applies coded payroll rules to "decompose" this posted data into an 8B record for
5825       transmission to the Austin Automation Center (AAC). The target audience includes all employees since any
5826       employee may have access to the station's DHCP system and can make an electronic leave request. The hard
5827       copy time and attendance report has been eliminated.
5828
5829   •   The secondary function is to receive and store employee master record data. The purpose of this function is
5830       to create an employee database which will be available to Payroll and Personnel users for viewing and local
5831       reporting needs. A regularly updated employee database will be used to create a paperless time and attendance
5832       report "stub" record (i.e., the first 32 characters of an 8B record). The users may view the employee master
5833       record data by means of two menus; the Employee Inquiry Menu (sub-menu) designed for Payroll users and the
5834       Employee Inquiry Reports/ Menu designed for Personnel users.
5835
5836       The package includes a continuously updated employee master record database. Payroll and Personnel users
5837       are the target audience for this database. They are able to view, but not change this data. Employee master
5838       record data from the AAC is stored at the station and updated regularly. The purpose, scope and target audience



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
5839       for this portion of the software remains the same. The employee master record database rather than a biweekly
5840       8B download is used to create a time and attendance report stub record.
5841
5842   •   The third function is a module that creates an Education Tracking database featuring programs or classes with
5843       multiple attendees and reasons for attending these programs or classes.
5844
5845       This database is made up of each individual employee's program or class attended and all associated data
5846       including: program or class name and supplier, type of media used for presentation, agency to place where
5847       employee or student is from,purpose of the training, a category or name for a desired grouping of program or
5848       classes, type of training (mandatory inservice, continuing education or other training), mandatory review group (if
5849       a required class), financial agency and cost(if government funded), accreditation board (if continuing education)
5850       and employee or student expense (if any or all funding is provided by the employee or student).
5851
5852       The AAC sends employee master record data to the station where it will be stored and updated regularly. The
5853       AAC will generate five types of employee data downloads. They are: Initial, Edit and Update, Payrun, Transfer,
5854       and Separation. This data will be transmitted through MailMan to the station where it will bestored in the PAID
5855       EMPLOYEE (#450) and/or PAID PAYRUN DATA (#459) file. Payroll users will be able to view payroll-related
5856       data in these two files. Personnel users will be able to look at personnel-related data in the PAID EMPLOYEE
5857       file,only.
5858
5859   Features:
5860
5861   Enhanced Time and Attendance:
5862    Timekeepers can enter and edit employee’s time, view data for current and prior pay periods, and view time card
5863      status for each employee.
5864    Payroll can view processing status of T&Ls, locate uncertified or incomplete timecards.
5865    Payroll may also manage T&L units by enter/edit of supervisors, timekeepers and employees.
5866    Payroll may view pay period data, master records, and accounting data for employees.
5867    Payroll can create searches of master record and accounting data for custom local reports.
5868    The payroll supervisor transmits all payroll data to Central PAID in Austin and monitors transmission status.
5869    The system automatically builds and updates employee records with Central PAID data.
5870    Authorized personnel may display and search master record and accounting data for all employees.
5871    Employees may submit electronic leave requests and view leave balances, status of requests, and service
5872      records.
5873    Supervisors can approve electronic requests and timecards and view employee leave reports.
5874
5875   Education Tracking:
5876    Creates a class database with pertinent class information: class name, presenter, location, purpose, category,
5877      type, mandatory review group, sponsoring agency, cost, accrediting organizations, employer/student expenses,
5878      contact hours, etc.
5879    Contains a class registration component that limits class registrants by number or service.
5880    Credits class participation to individual attendee records and allows attendance corrections.
5881    Provides site-configurable mandatory training groups, accrediting organizations, presentation media, supplier
5882      demographics, and class purpose.


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
5883      Contains reports, such as a calendar of events, a registration roster, service-based class, and a variety of
5884       employee training reports.




5885
5886                                                    Figure: 3.2-38
5887
5888




       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap          Page 3-2
5889   Patient Representative - (Component diagram)
5890
                    cmp Patient Representativ e



                           Patient Representativ e




                                          «interface»
                                             QAC
                                                                       Austin Automation Center




5891
5892                                                  Figure: 3.2-39
5893
5894




       www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5895   3.2.29 PAID-Personnel and Accounting Integrated Data
5896




5897
5898                                               Figure: 3.2-40
5899
5900




       www.oserha.org                             OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
5901   PAID-Personnel and Accounting Integrated Data - (Component diagram)
5902
                            cmp PAID-Personnel and Accounting Integrated Data



                               PAID-Personnel and
                                   Accounting
                                 Integrated Data


                                         «interface»
                                            PRS
                                                                         Austin Automation Center




5903
5904                                                       Figure: 3.2-41
5905
5906   3.2.30 Police and Security
5907   The V. 1.0 Police & Security software package provides an automated system of procedures that generates the
5908   necessary reports and other forms of records pertinent to the VA Police and Security Service (VA Police) operation.
5909   In most instances, a single data entry procedure will create the permanent record, as well as generate statistical data
5910   necessary to produce a variety of management level reports.
5911
5912   By statutory provisions, the Secretary of Veterans Affairs (VA) is responsible for the protection of patients, visitors,
5913   employees, protection of property, and the maintenance of law and order on property under the charge and control of
5914   the Department of Veterans Affairs. This responsibility is subsequently delegated to the Deputy Assistant Secretary
5915   for Security and Law Enforcement who provides program guidance and assistance to the VA Police located at each
5916   VA Medical Center (VAMC). The primary function of the VA Police is to prevent crime on VA property.
5917
5918   The role of the VA Police Officer is crime prevention, preliminary investigation of crimes, apprehension, legally
5919   correct handling of suspected offender(s), and the transfer of suspected offender(s) to appropriate authorities. This
5920   package is designed to assist the VA Police Officers in accomplishing these goals.
5921
5922   The ESP MASTER NAME INDEX file (#910) serves as the primary repository file for the storage of names,
5923   addresses, and other demographic data for all persons who come in contact with the VA Police during normal
5924   operations.
5925
5926   National Upward Reporting includes transmitting the Monthly Crime Report through MailMan to Central Office. The
5927   local office will be able to send a Uniform Offense Report (UOR) to VACO through MailMan to facilitate meeting the
5928   48 hour notification requirement on specific types of investigations.
5929
5930   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-2
5931
5932   Daily Operations Journal Module
5933   The Daily Operations Journal module provides a system for storage and retrieval of information currently being
5934   manually placed on the VA Police Daily Operations Journal (VA Form 10-1433) and Continuation Sheet (VA Form
5935   10-1433A).
5936
5937   Evidence/Property Module
5938   The Evidence/Property module provides a system to record and retrieve information contained on the Evidence
5939   Property Custody Record (VA Form 10-3524). The electronic record of this information allows the formation of the
5940   required Evidence Property Log and other necessary documentation in a faster manner than the current manual
5941   methods. This module contains several report options for management purposes.
5942
5943   Package Management Module
5944   There are several files contained within the program that should only be altered sporadically once the package has
5945   been fully implemented. This is accomplished through the options in this module.
5946
5947   Quick Name Check Module
5948   The Quick Name Check module allows for the retrieval of stored information for a selected person(s) from files in
5949   several different modules and displays the information. The Quick Name Check option displays any data on file for
5950   an individual, such as vehicle registrations, demographics, wants and warrants, violations, offenses, and previous
5951   investigative involvements.
5952
5953   Criminal Statute Module
5954   The primary menus assigned throughout this program can look at or print any criminal offense code and its definition
5955   within the ESP OFFENSE CODES file (#915). This file is referenced by any “Offense Committed” question
5956   throughout the various modules of the program. Its use is expanded to include an on line lookup in order to
5957   determine the legal wording of each particular criminal offense. It is necessary for each local field station to add any
5958   local medical center, city, county or state ordinances under which they can place criminal charges to the ESP
5959   OFFENSE CODES file.
5960
5961   Training Records Module
5962   The Training Records module provides a system for storing information about training completed by staff members
5963   assigned to VA Police and Security Service. The accumulation of this data allows for the printing of training records
5964   for documentation purposes, as well as management planning for funding justifications.
5965
5966   Uniform Crime Reports Module
5967   The Uniform Crime Reports module accesses selective data from entries in the Offense Report and Violations
5968   modules. This data will be assembled into a standardized report format for the VA Police Chief to document the
5969   numbers and types of criminal incidents occurring at the medical center. The Uniform Crime Report is a greatly
5970   expanded version of the Automated Management Information System (AMIS) report. It provides a much more in
5971   depth record of the type of criminal activities which occur, as well as recording dollar values for investigations dealing
5972   with loss and recovery factors. The Uniform Crime Reports module downloads and transmits the Uniform Crime
5973   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-2
5974   statistical data from all VAMCs will provide important information at the national level to the Deputy Assistant
5975   Secretary for Security and Law Enforcement regarding program planning strategies.
5976
5977   Offense Reports Module
5978   The Offense Reports module facilitates the entry of data normally contained on the VA Police Uniform Offense
5979   Report, Investigative Notes, and Case Log. It will also facilitate entry of data from preparatory documentation
5980   assembled during a criminal investigation. By entering the data into the Offense Reports Module, the VA Police
5981   Officer will be creating an electronic record of his investigation that will be readily retrievable for future use. At the
5982   same time, the software package will be assembling statistical data for creating trend studies and other beneficial
5983   management tools.
5984
5985   Vehicle Registrations Module
5986   The Vehicle Registrations module records all information necessary for the maintenance of the VA Police Vehicle
5987   Registration program. The information contained within this module is highly beneficial to those VAMCs operating a
5988   Ride Sharing Program. Because of the diverse complexity of operations throughout the VAMCs, ranging from single
5989   building high-rise complexes to large expanded-campus style facilities, this module also contains a system of
5990   miscellaneous registration files that can be used at the discretion of the individual VA Police Chief.
5991
5992   Violations Module
5993   The Violations module allows for the entry of all violation information contained on US District Court Violations
5994   Notices and Courtesy Warnings issued by VA Police Officers at the medical center. This module generates several
5995   types of management tracking reports.
5996
5997   Wants & Warrants Module
5998   The Wants & Warrants module is used to record any data pertinent to individuals currently under any type of criminal
5999   proceedings. This includes individuals with outstanding warrants, summons, court commitments, or other types of
6000   legal documentation. This module provides a flag notification to officers on duty that the individual in question is
6001   wanted, has been involved in some prior serious physical altercation, or other incident that can require additional
6002   preparation, or requires caution when being approached. The Wants & Warrants module contains several print
6003   options for maintaining list of persons currently in an active want or detained status.
6004
6005   Daily Activity Module
6006   The Daily Activity module provides a method for VA Police Officers to enter specific activities that occurred during
6007   their tours of duty and the time required to complete these activities. This module also allows a VA Police Officer to
6008   create an entry of his or her activities and combine them with the entries of other VA Police Officers. This information
6009   helps the Chief of VA Police to justify and plan the patrol activities of the VA Police and Security Service.
6010
6011   Features
6012    Serves as the repository file for the names, addresses, and other demographic data of persons who come in
6013       contact with the VA Police and Security staff.
6014    Allows for the retrieval and display of stored information for a selected person.
6015    Stores electronic data normally entered on the VA Police Uniform Offense Report, Investigative Notes, Case
6016       Log, and other documentation assembled during an investigation.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap                Page 3-2
6017      Contains all violation information on US District Court Violations Notices and Courtesy Warnings issued by VA
6018       Police Officers at the medical facility.
6019      Assembles selective data into a standardized report format documenting the numbers and types of criminal
6020       incidents that are occurring at the site.
6021      Records information necessary for the Vehicle Registration program.
6022      Records any data pertinent to individuals currently under any type of criminal proceedings or other legal
6023       restraining document.
6024      Provides a system to record all information contained on the Evidence Property Custody Record (VA Form 10-
6025       3524).
6026      Allows each police officer to record the specific activities performed during a shift and the time required to
6027       complete the activities.
6028      Stores all information relative to training completed by staff members assigned to the Police and Security
6029       Service.
6030      Stores all information entered on the VA Police Daily Operations Journal (VA Form 10–1433) and Continuation
6031       Sheet (VA Form 10-1433a).
6032      Transmits Monthly Crime Reports and selected Offense Reports through Mailman to VA Headquarters.
6033      Produces supervisory management, quality management, and crime trend studies; a standardized Uniform
6034       Offense Report, Uniform Crime Report, and Evidence Register Report; and Case Progress Notes and Case
6035       Assignment Register.




6036
6037                                                     Figure: 3.2-42
6038
6039   3.2.31 Quality Management Integration Module
6040   The QM Integration Module (often called the QAQ routines) contains utilities that are common to some or all of the
6041   QM software packages. Utilities that you may recognize are as follows.
6042   • The date selector is found within many of the reports options. It lets the user choose the date range that is
6043        needed for the report.
6044   • The group selector lets the user select more than one item to print or view at a time. This reduces the number of
6045        key strokes needed to produce a specific outcome.
6046   • The Ad Hoc Report Generator uses basic VA FileMan sort and print modifiers and adds the capability of building
6047        macros (often termed templates) for those reports that are routinely required.



       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
6048   •   The audit file builds an audit trail for each record in the QM packages. You can see the contents of the audit file
6049       in the Occurrence Screen software by using the Audit File Inquiry option. In other software, the audit trail is
6050       accessible to the IRM staff through VA FileMan.
6051
6052   •   The QM Integration Module links the QM software through a QM Manager menu.
6053
6054   The Combined Site Parameters Edit option should be used whenever any new package is installed. Refer to the user
6055   documentation for each individual QM software package for suggestions on menu management.




6056
6057                                                        Figure: 3.2-43
6058
6059   3.2.32 Record Tracking
6060   The prompt availability of patient records is an essential ingredient in the delivery of quality medical care. Lack of
6061   access to vital patient history contained in these records may lead to life-threatening situations.
6062
6063   The VA Record Tracking system is a comprehensive software package, written to aid file activities in assuring
6064   optimum availability of these records to a broad range of users within and outside the facility. Functions which were
6065   previously done manually have been computerized, promoting greater efficiency, uniformity and accuracy.
6066   Demographic record information is now available on-line to a broad range of users as well as a variety of reports
6067   which have been included to assist management in workload analysis and quality assurance.
6068
6069   The system has been designed so that it may be used in conjunction with bar code technology, further enhancing
6070   efficiency and accuracy. The Record Tracking system uses VA FileMan and integrates with the Radiology and PIMS
6071   packages in performance of its functions.
6072
6073   This package was originally designed for use in tracking Medical Administration and/or Radiology records. A great
6074   deal of flexibility has been built into the system so that it may be custom-tailored to meet the needs of practically any
6075   file activity.
6076
6077   Features:
6078    Uses bar code technology, prints bar code labels for the charts, and uses bar code equipment to charge records.
6079    Displays informational bulletins when a record is checked into a file room.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
6080      Bulletins may include the following information: pending requests for the record, the record has previously been
6081       flagged as missing, loose filing exists, the patient is currently an inpatient, or the record is being checked into a
6082       file room other than its home.
6083      Offers a complete system for maintenance and control of records that may be used with ease in any type of file
6084       setting.
6085      Produces a variety of reports associated with the module that may be used to assist management in workload
6086       analysis and control of records.
6087      Creates pull lists to provide requests for records in conjunction with clinic scheduling and record retirement.
6088




6089
6090                                                        Figure: 3.2-44
6091
6092   3.2.33 ROI-Release of Information Manager
6093   The Release Of Information System (ROI) is a Document Storage Systems, Inc. (GUI) application that is designed to
6094   provide health care facilities with an intuitive, user friendly Windows interface for end-users to use to request patient
6095   medical record information.
6096
6097   The ROI Manager is an application that uses "RPC Broker" technology that permits the facility users to retrieve
6098   clinical data within the VistA System. The user can work offline of VistA and only administrator functions will be
6099   active. The ROI Manager Encounter System database is linked to the VistA System database that stores registered
6100   patient documentation. These databases are “in sync” with each other and reduce data entry time because certain
6101   data fields are automatically populated (or filled-in) ensuring data accuracy.
6102
6103   The ROI system tracks requests for privacy act information for patients receiving
6104   treatment at VA facilities.
6105




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
6106
6107                                                      Figure: 3.2-45
6108
6109   3.2.34 VIC/PICS-Veteran Identification Card
6110   The Veteran Identification Card (VIC) replaces the embossed data card as a means of identifying veteran patients
6111   entitled to care and services at Department of Veterans Affairs (DVA) health care facilities.
6112
6113   The replacement VIC displays a larger color photograph of the veteran and the veteran’s name. There is no
6114   embossed information on the card. A VistA print option provides labels with the patient’s identifying information. The
6115   labels can be affixed to medical record forms in lieu of using the embossed cards to imprint this information when
6116   pre-printed forms are not available.
6117   A color photograph of the veteran is taken at the local medical center using the Patient Image Capture Software
6118   (PICS) on a Clinical Context Object Workgroup (CCOW) enabled workstation. The photograph is sent to the local
6119   VistA Imaging server, making it available to the Computerized Patient Record System (CPRS) and other VistA
6120   applications. The photograph and VistA patient data is also transmitted to the National Card Management Directory
6121   (NCMD) in Silver Spring, MD (a repository of VIC data).
6122
6123   Once the Health Eligibility Center (HEC) has verified the patient’s eligibility, the veteran has been assigned an
6124   appropriate enrollment status, and also assigned a national Integration Control Number (ICN), the VIC data and
6125   images are transmitted to the external card print vendor using secure protocols. The external card print vendor
6126   creates the VIC cards and mails them to the veterans. For homeless veterans, the external card print vendor mails
6127   the cards to the appropriate medical center, which then issues the cards to those veterans.
6128
6129   Features
6130   • Veteran’s picture, name, and care type (i.e., service connected) on card face as well as POW and Purple Heart
6131       status as appropriate.
6132   • Magnetic stripe on card encoded with the patient’s name, social security number, date of birth, sex, patient type,
6133       veteran status, and service-connected indicator.
6134




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
6135
6136                    Figure: 3.2-46
6137
6138




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
6139   VIC/PICS-Veteran Identification Card - (Component diagram)
6140
                           cmp VIC/PICS-Veteran Identification Card



                                VIC/PICS-Veteran
                                Identification Card



                                       «interface»
                                           DG
                                                                     National Card Management
                                                                     Diretory (NCMD)



6141
6142                                                      Figure: 3.2-47
6143
6144   3.2.35 VSS-Voluntary Service System
6145   The Voluntary Service System (VSS) software is the first application to be developed in the current VistA Migration
6146   effort. VSS is a national-level application replacing the site-based Voluntary Timekeeping System (VTK). VTK has
6147   been used for many years at VA medical centers to track and manage the hours of service contributed by volunteers
6148   and volunteer organizations.
6149
6150   To improve data collection and reporting, users interact directly with a national, centralized database. Consolidated
6151   national reporting no longer requires data transmissions back and forth between sites and the Austin Information
6152   Technology Center (AITC). Direct access to data provides instantaneous updates and up-to-minute reporting for all
6153   users. Central Office administrators and voluntary staff thus have broader and more reliable data for managing
6154   volunteer services.
6155
6156   The VSS application helps voluntary staff accomplish their tasks more easily through a Web-based graphical user
6157   interface. Users at the local and national level are able to generate a wider array of reports about volunteers and
6158   sponsoring organizations. In addition, volunteers are able to log their own hours and print meal tickets themselves at
6159   secure log-in “kiosks.”
6160
6161   Features
6162   • Provides multi-lingual interaction with volunteers during log-in.
6163   • Supports and enhances security for multiple division facilities.
6164   • Displays/prints entire master record for a single volunteer.
6165   • Provides local printing of address labels and telephone lists.
6166   • Reduces workload required to input mass award code changes.
6167   • Prints individual meal ticket for volunteer after Auto Log-in.
6168   • Provides real-time national reporting of data for all stations.
6169




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
6170
6171                                                       Figure: 3.2-48
6172
6173   3.2.36 Wounded Injured and Ill Warriors
6174   This document is in response to the action item developed by the Wounded, Ill, and Injured Senior Oversight
6175   Committee, Support and Care for the Wounded - Task Force, under Line of Action (LOA) #8 Pay Management, to
6176   develop a tool to provide accurate and timely personnel and health related data to the Defense Finance and
6177   Accounting Service (DFAS) supporting adequate maintenance of pay and entitlements for all wounded warriors. This
6178   document specifies the Technical and Security Guide for the Interim Solution which will satisfy this requirement. It is
6179   envisioned that a future solution will be fully automated and is described below.
6180
6181   Currently, the Department of Defense’s (DoD) Wounded Warrior Pay Management Program (WWPMP) has identified
6182   pay issues for Active Duty Service Members who are admitted to non military medical treatment facilities due to
6183   combat-related injuries. Veterans Health Administration (VHA) often provides inpatient and outpatient health care
6184   services to Active Duty Service members. The Department of Defense/Defense Finance and Accounting Service
6185   (DoD/DFAS) has experienced difficulty in keeping accountability for this population and the lack of accurate
6186   accountability may adversely impact the pay of Service Members.
6187
6188   In the fall 2007, through a collaborative effort between the Department of Veterans Affairs (VA), VHA and DoD/DFAS
6189   VA and VHA agreed to provide defined data elements to DoD/DFAS to facilitate tracking of Active Duty Service
6190   Members admitted to inpatient VA facilities. In February 2008 a Memorandum of Understanding (MOU) by and
6191   between VA and VHA and DoD/DFAS was executed. The MOU established the authorities and agreement for the
6192   exchange of information relating to admission to and discharge from inpatient VA health care facilities of Active Duty
6193   personnel. A copy of the executed MOU is enclosed in Appendix A. This agreement is consistent with and supports
6194   the mission of the VA/DoD Joint Executive Council to improve the quality, efficiency and effectiveness of the delivery
6195   of pay benefits to service members admitted to inpatient VA services.
6196
6197   There were two (2) solutions conceived during the conceptualization of how these requirements could be met. The
6198   first is the Interim solution, which can be put into service in a short period of time, but has the drawback of being
6199   more labor intensive. The Interim Solution is the focus of this Technical Manual and Security Guide. The second
6200   solution, named the Future solution will eliminate all manual processes, sending the records to a central server which
6201   will collect and transmit them automatically to the DoD/DFAS on a periodic basis. The Future solution will not be
6202   started until the Interim Solution is implemented and analyzed. The Interim Solution requires a weekly data collection



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
6203   process at each VA inpatient facility of Active Duty Service Members admitted and discharged. DoD/DFAS requires
6204   a complete list of all Active Duty patient admissions/ discharges within the VA. Appendix B provides a detailed list of
6205   the data requirements. Each VA inpatient facility will transmit its list of Active Duty inpatients by secure email to the
6206   central collection facility. The approved/ released list is then sent to the VA collecting repository at the central
6207   collecting facility, via a secure Vista mail server. Each facility’s transmission is collected into one list by a VA
6208   coordinator specifically trained to perform this function. The list of all Active Duty Service Members admitted to or
6209   discharged from inpatient VA facilities is then transmitted to the DoD/DFAS via an encrypted email to a secure
6210   DoD/DFAS mailbox. This address has been provided to the VA and VHA by DoD/DFAS. The report, as defined in
6211   Appendix B and detailed in Section Format Transmissions to DFAS (page 24) will include the Active Duty Service
6212   Member’s first name, middle name or initial, last name, and social security number, and his/her admission date and
6213   time and/or discharge date and time and the facility identification number.
6214
6215   Note: Facilities that do not have any admissions and/or discharges during the reporting period are required to submit
6216   an email stating that there were no admissions and/or discharges.
6217
6218   It is assumed that the Interim Solution will be accomplished as follows:
6219          A patch delivered to the Vista ADT software.
6220          Training of designated staff at each facility
6221          Deployment of patch following a several week testing period.




6222
6223                                                        Figure: 3.2-49
6224
6225   3.3 Infrastructure
6226   Common Services team develops and maintains the underlying software infrastructure supporting both
6227   legacy and current veteran health-related applications. Though largely transparent to end users,
6228   Common Services provides essential infrastructure elements such as identity management, security,
6229   message routing, transformation, and data transport for clinical and administrative applications. Core
6230   common services are addressed through three programs: Identity Management, Security and Other
6231   Common Services, and Messaging and Interface Services.
6232
6233



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
       class Infrastructure




                      EELS                    STK               MDWS                E3R               FatKAAT




                                                                                                     VA FileMan

                                        Standard Files
                    Surv ey Generator                       National Patch       KAAJEE
                                          and Tables
                                                                Module




                          KDC                               Kernel Toolkit         Kernel              Kernel
                                                                              Toolkit-Parameter     Toolkit-Patch
                                                                                     Tools             Monitor




                         MailMan         XML Parser             CIRN              Inpatient         MPI-Master
                                           (VistA)                                                 Patient Index
                                                                                                     (AUSTIN)




                       Registration       HL7 (VistA          Laboratory            NDBI               Kernel
                                          Messaging)




                      OE/RR-Order        New Person,          CPRS:ART           Pharmacy         DSM for OpenVMS
                      Entry/Results     3/6/16/20 Killer                                                AXP
                        Reporting            Patch




                     Open VMS AXP            SQLI                MPI                RPC
                                                                                                        CMT




                      Context Vault      Patient Merge          KIDS              TaskMan              VDEF




                                            SAGG                                                       Name
                              HDI                                                                  Standardization
                                                           Kernel Unw inder     List Manager




                              NHE          ZSLOT                                    PDX                 IFR
                                                           M-to-SQL Product




                                             RUM               SSO/UC            NOIS
                      M-to-M Broker                                                                     VistALink




                         FMDC




6234
6235                                                        Figure: 3.3-1



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
6236   3.3.1 CMT-Capacity Management Tools
6237   The Capacity Management Tools software application provides fully automated support tools developed by Capacity
6238   Planning Service. It entails the daily capture of the following data from participating sites:
6239   • VistA Health Level Seven (HL7) Workload Information—VistA HL7 workload data is summarized and transmitted on
6240   a weekly basis.
6241   • VistA Timing Data—Timing data is summarized and transmitted on a daily and weekly basis.
6242   Data collected is automatically transferred via network mail (i.e., VistA MailMan) to the Capacity Planning National
6243   Database. The data is displayed graphically on the Capacity Planning Statistics Web page located at:
6244   http://vista.med.va.gov/capman/Statistics/Default.htm
6245
6246   The Veterans Health Administration (VHA) developed the Capacity Management Tools software in order to obtain
6247   more accurate information regarding the current and future VistA HL7 workload data at VA sites.




6248
6249                                                       Figure: 3.3-3
6250
6251   3.3.2 Duplicate Record Merge
6252   Kernel Toolkit (Duplicate Record Merge: Patient Merge) is a Kernel Installation and Distribution System (KIDS)
6253   software release. It requires a standard VistA operating environment in order to function correctly.
6254
6255   Patient Merge provides an automated method to eliminate duplicate patient records within the VistA database. It is an
6256   operational implementation of the Duplicate Resolution Utilities, which were released to the field with Kernel Toolkit
6257   (Patch XT*7.3*23).
6258



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
6259   The overall process consists of three major subject areas: 1) the search for and identify potential duplicate record
6260   pairs, 2) the review, verification, and approval of those pairs, and 3) the merge process.
6261
6262   The search and identification of potential duplicate records performs comparisons on key patient traits in the
6263   centralized Person Service Identify Management (PSIM) database. The goal of PSIM is to provide an authoritative
6264   source for persons’ identity traits throughout the Veterans Health Administration (VHA). The Initiate Probabilistic
6265   Search Implementation in PSIM adds advanced search capabilities to improve the overall matching process during
6266   Search, Add and Update processes. The advanced search capabilities also provide enhanced capabilities for Identity
6267   Management Data quality (IMDQ) case workers who perform patient identity management data quality tasks.
6268
6269   PSIM determines that a pair of patients is a duplicate, or potential duplicates. Potential duplicates are further
6270   reviewed by the Identity Management Data Quality team (IMDQ). If a pair of patients is determined to be duplicates,
6271   and if both patients are known at a VistA site, the patient pair is added to the local VistA DUPLICATE RECORD file
6272   (#15). An email is sent to members of the mail group found in the DUPLICATE MANAGER MAIL GROUP field of the
6273   record associated with patients, in the DUPLICATE RESOLUTION file (#15.1). Once a potential duplicate pair has
6274   been identified, the process of verifying record pairs begins.
6275
6276   The review and verification process includes two levels of review. The primary reviewer, initially seen as an MAS
6277   responsibility, performs a review of patient demographic information. The primary reviewer initially determines if the
6278   pair represents a duplicate record. If so, the primary reviewer selects the merge direction. If data from ancillary
6279   services is present, notification (via MailMan message or alert – or both) is sent to those designated as ancillary
6280   reviewers. A site may determine reviewers based upon their business practices. Reviewers determine whether the
6281   record pair is a duplicate, not a duplicate (so that subsequent processing need not occur), or that they are unable to
6282   determine the status. Where appropriate, reviewers may mark data to be overwritten. Those record pairs that are
6283   determined to be verified duplicates are marked as such and are then available for approving to be merged.
6284
6285   The intent of the approval step is to ensure that a conscious decision will be made in taking verified duplicate record
6286   pairs and making them available for a merge process. All verified record pairs, or selected pairs, can be approved.
6287   The approval step follows a site defined waiting period. Reviewers are responsible for approving verified duplicates.
6288
6289   The merge process is available for initiation by IRM personnel. All approved record pairs are included in a merge
6290   process when scheduled. The merge process is a lengthy process that is recommended for off-peak hours. Utilities
6291   are available for pausing and restarting the merge process. The merge process merges verified duplicate records in
6292   the following order: first, files that require special handling, then the primary file, then the resolution of pointers. The
6293   resolution of pointers for the primary file or any of those involving special processing involves three phases. The first
6294   two phases permit identification of entries requiring modification based on their IENs (DINUMed) or by cross-
6295   references and are fairly rapid. The third phase involves all other pointers and can be lengthy. Several special
6296   processing routines have been written to handle those database entries that point to the PATIENT file (#2) in an
6297   unusual manner. Entries for each special processing routine have been made in the PACKAGE file (#9.4) multiple,
6298   AFFECTS RECORD MERGE field (#20). A stub record is maintained in order to disallow reuse of PATIENT file (#2)
6299   internal entry numbers.
6300




       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap                 Page 3-2
6301   Concurrent with the merge, entries are made in a new global for each record making up the pair. The entries are
6302   intended to provide a "before-merge" image. However, please note that the merge is a non-reversible process. Once
6303   the pair of records is merged, there is no automated way of undoing the process.
6304
6305   The application has been written to support multiple parallel jobs (threads - as specified by the site) during the merge
6306   process. However, decreased overall processing time is exchanged for increased system utilization.




6307
6308                                                        Figure: 3.3-4
6309
6310




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
6311   3.3.3 E3R-Electronic Error and Enhancement Reporting
6312   There are no documents for this application at this point. (As of: October 30, 2009)
6313




6314
6315                                                        Figure: 3.3-5
6316
6317   3.3.4    EELS-Enterprise Exception Log Service
6318
6319   There are no documents for this application at this point. (As of: October 30, 2009)




6320
6321                                                        Figure: 3.3-6
6322
6323   3.3.5 FatKAAT
6324   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-2
6325                                                                                                                 Figure: 3.3-7
6326
6327   3.3.6 VA FileMan
6328   VA FileMan is a database management system (DBMS) with powerful Application Program Interfaces (APIs) and
6329   provides useful utilities for application developers. VA FileMan can be used as a database management system for
6330   data entry and output and its DBS calls are utilized in application packages with tools like Filegrams, auditing,
6331   archiving, and statistics.
6332   • Database Management System (DBS)—As a database management system (DBS), VA FileMan supports the
6333   entering, editing, printing, searching, inquiring, transferring, cross-referencing, triggering, and verifying of information.
6334   It includes special functions to create new files, modify an existing file, delete entire files, re-index files, and create or
6335   edit templates.
6336   • Application Program Interfaces (APIs)—As an application program interface (API), the Database Server routines
6337   manage interactions between the application software and the database management system "silently," that is,
6338   without writing to the current device. Package developers use DBS calls to update the database in a non-interactive
6339   mode. Information needed by the VA FileMan routines is passed through parameters rather than through interactive
6340   dialogue with the user. Information to be displayed to the user is passed by VA FileMan back to the calling routine in
6341   arrays. This separation of data access from user interaction makes possible the construction of alternative front-ends
6342   to the VA FileMan database (e.g., a windowed Graphical User Interface [GUI]).
6343   • Utilities—As a set of utilities, VA FileMan provides tools like the Filegram, which is a tool that moves file records
6344   from one computer to another; archiving, which is a tool that stores data onto an offline storage medium; auditing,
6345   which is a tool that tracks changes to data in a field or to the file's structure (the data dictionary); and statistics, which
6346   is a tool that accumulates totals and subtotals of individual fields.
6347
6348   Programmers and non-programmers use VA FileMan alike. VA FileMan can be used as a stand-alone database or
6349   as a set of application utilities. In either mode, it is used to define, enter, and retrieve information from a set of
6350   computer-stored files, each of which is described by the data dictionary.
6351   VA FileMan is a public domain software package and is widely used in clinical, administrative, and business settings
6352   in the United States and abroad.
6353
6354   Standalone VA FileMan




       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap                  Page 3-2
6355   VA FileMan is designed to be used either with Kernel or as a standalone application running under a variety of
6356   implementations of ANSI standard M. If VA FileMan is used without Kernel, the basic DBMS features of VA FileMan
6357   all work as described in the manuals. However, there are some features (e.g., bulletin-type cross references, print
6358   queuing, and Filegrams) that do not work without portions of Kernel. Whenever Kernel is needed to support a
6359   particular VA FileMan feature, that fact is mentioned in the manuals.
6360
6361   The installation of VA FileMan 22.0 is not integrated with the installation of Kernel. The VA FileMan Installation Guide
6362   contains instructions on how to install VA FileMan, both for standalone sites and for sites running Kernel.
6363
6364   NOTE: The Kernel Toolkit (Duplicate Record Merge: Patient Merge) application brings a new browser setup.
6365   XDRBROWSER1 is specifically designed to work with Patient Merge. It is a modified version of the VA FileMan
6366   Browser.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
6367
6368                     Figure: 3.3-8
6369
6370




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
6371   3.3.7 FMDC-FileMan Delphi Components
6372   The FileMan Components for Delphi applications make it easy for developers to work with VA FileMan data in Delphi
6373   applications. The components encapsulate the details of retrieving, validating and updating VA FileMan data within a
6374   Delphi application. This saves you from creating your own custom remote procedure calls (RPCs) when you need to
6375   access VA FileMan data.
6376
6377   The FileMan Delphi Components also include special enhanced features such as complete server-side error
6378   checking and data dictionary help.
6379
6380   If you're already familiar with Delphi, the time needed to develop an application to edit a set of VA FileMan fields
6381   using the FileMan Delphi Components is comparable to the time needed to create the same application using VA
6382   FileMan's roll-and-scroll ScreenMan interface.
6383
6384   The FileMan Delphi Components provide three types of components:
6385   • Data Access Components are invisible to the user, but contain the functionality for calling the server to find,
6386       retrieve, validate, and file data. Each of the data access components encapsulates the functionality of one or
6387       more VA FileMan Database Server (DBS) calls.
6388   • Custom Dialogues are like mini-applications you can include in your own application. The TFMLookUp custom
6389       dialogue makes it easy to perform lookups in files with large numbers of records.
6390   • Data Controls are visual controls users can interact with to change data values. For example, a TFMCheckBox
6391       control is good for editing "Boolean" two-value set of codes fields; a TFMMemo control is good for editing word-
6392       processing fields; and a TFMEdit control is good for editing free text fields. Data controls are directly populated
6393       by the data access components. Values are directly validated and filed from the controls by the data access
6394       components.
6395
6396   There are 17 FileMan Delphi Components, and each one has a variety of methods and properties that allow you to
6397   fine-tune its behavior. However, a basic approach to using them, involving only a subset of their properties and
6398   methods, is appropriate for most data editing situations.
6399
6400   To follow this basic approach: First, determine the set of fields you want to edit in your Delphi application. Then follow
6401   this Quick Start Guide to provide that access in your Delphi application.
6402
6403   The FileMan Delphi Components provide the following components for use in Delphi:
6404   1. TFMFiler
6405   2. TFMFinder
6406   3. TFMFindOne
6407   4. TFMGets
6408   5. TFMHelp
6409   6. TFMLister
6410   7. TFMValidator
6411   8. TFMLookUp
6412   9. TFMCheckBox
6413   10. TFMComboBox
6414   11. TFMComboBoxLookUp



       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
6415   12.   TFMEdit
6416   13.   TFMLabel
6417   14.   TFMListBox
6418   15.   TFMMemo
6419   16.   TFMRadioButton
6420   17.   TFMRadioGroup
6421
6422   The FileMan Delphi Components provide the following objects for use in Delphi:
6423    TFMErrorObj
6424    TFMFieldObj
6425    TFMHelpObj
6426    TFMRecordObj
6427
6428   The FileMan Delphi Components provide the following Pascal routines for use in Delphi:
6429    DeleteRecord
6430    LockNode
6431
6432   Referenced in FMDC-FileMan Delphi Components documentation.
6433
6434   Broker Development Kit. Provided with VISTA's RPC Broker software package, this contains the files necessary to
6435   connect to a VISTA M server from a Windows client.




6436
6437                                                      Figure: 3.3-9
6438
6439   3.3.8 Health Data Informatics
6440   The Health Data Informatics (HDI) package provides a basic method for seeding VHA Unique Identifiers (VUIDs) for
6441   reference data in existing VistA applications. A VUID is a meaningless number, which is automatically assigned to
6442   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-2
6443
6444   The HDI package will be used by each VistA site to seed VUIDs in their existing global files that contain reference
6445   data, such as drug names, names of known allergens, and so forth. These files have been grouped into domains,
6446   and each domain will be standardized separately. As each domain’s files are originally standardized, the HDI
6447   package is used to assign a VUID to each term or concept in the file. Subsequent standardization updates and
6448   maintenance on these files will be handled separately by the New Term Rapid Turnaround (NTRT) program.
6449
6450   Installation of this package anticipates the installation of domain-specific application patches, applied to any
6451   application(s) that make use of the standardized reference data files. Requirements documentation for each affected
6452   domain is separately available from Data Standardization. These application patches (e.g. GMRV*5.0*8) will, in
6453   general terms: change the data dictionary and global files to prevent modification of data; and modify existing data
6454   dictionary files to add additional fields, including the VUID field and fields for determining the current status of a term.
6455   The application patches will also modify user interfaces (both graphical and roll-and-scroll) to screen out all reference
6456   data whose status is ‘not active.’ Once these changes are in place, the application patch makes a procedure call to
6457   the HDI package, instructing it to seed the VUIDs and statuses for each reference term.
6458
6459   Once the Application Patch has been installed for the Data Domain, the Application post-initialization routine calls an
6460   API in the HDI package which creates an XML file for each of the files being standardized. The XML file includes the
6461   Term/Concept (.01 Field) from each of the files. Each XML file is then forwarded to the central server, FORUM. On
6462   the FORUM server, the XML file is compared with the standardized data from Enterprise Terminology Services
6463   (ETS). The data received from the facility is modified as follows: (1) FORUM sets a VUID value for every matching
6464   entry; (2) any unmatched local entries are assigned a VUID from a block of available numbers, and identified as
6465   inactive terms; and (3) any duplicate entries are identified as inactive terms. This information is then passed back to
6466   the facility as an XML file, which is used by the HDI package on the Facility Server to update the VistA files.
6467
6468   Once the Facility’s VistA files have been updated, a MailMan mail message is automatically sent to the Enterprise
6469   Reference Terminology (ERT) team. The ERT team will manually initiate a Master File Server (MFS) push through
6470   the Vitria Interface Engine (VIE), which will complete the file update with data for additional fields not modified by the
6471   HDI package. This ERT update relies on VUIDs as a key for inserting the standardized data. At this point, the facility
6472   is considered standardized for that particular VistA file.
6473
6474   Once the Facility’s VistA file is standardized, the Application patch may optionally invoke a post-processing routine
6475   through MFS—for example if there is a need to perform any necessary cleanup tasks on the standardized file. When
6476   the post-processing routine completes its processing, or if there was no post-processing routine, the Health Data
6477   Repository (HDR) Implementation managers are notified automatically via another MailMan message. This message
6478   notifies HDR that the site is ready to have VistA Data Extraction Framework (VDEF) triggers turned on, which
6479   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-2
6480
6481                                                       Figure: 3.3-10
6482
6483   3.3.9 Health Level Seven (HL7) (VistA Messaging)
6484   Patches
6485    HL*1.6*131
6486    HL*1.6*126
6487
6488   The Health Level Seven (HL7) software package provides an interface that allows DHCP applications to exchange
6489   healthcare data with other applications using the HL7 protocol.
6490
6491   The HL7 package consists of a set of utility routines and files that provide a generic interface to the HL7 protocol for
6492   all DHCP applications. The HL7 package can be divided into two parts:
6493   • Lower level* protocol support between sending and receiving applications
6494   • DHCP interface to the HL7 protocol
6495
6496   The DHCP Interface to the HL7 Protocol
6497   With the release of V. 1.6, DHCP HL7 supports several methods for interfacing to the HL7 protocol. The method
6498   established by v1.5 is still supported (for backwards compatibility), and a new method is introduced, as well as new
6499   routines,file structures,
6500   templates, menus, and options. There are some significant differences between the v1.5 and v1.6 interface methods,
6501   as shown in the following table.
6502
6503   v1.5 Interface Method / v1.6 Interface Method
6504    One sender and one receiver per message. / One sender, one or more receivers.
6505    Sender and receiver must be on different systems. / Sender and receiver can be on the same or different
6506       systems.
6507    Messages must go through a communications protocol. / Messages sent to applications on the same system
6508       do not have to go through a communications protocol.



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
6509      All messages are processed in the background. / Messages are processed in either the foreground or
6510       background, based on the priority assigned by sending/ receiving applications.
6511      No support for event points. / Event points are supported.
6512
6513   History of the VistA HL7 Package
6514   VistA HL7 is an implementation of an HL7 interface engine. It is an M-based software product that assists M-based
6515   VistA applications by providing a means for those applications to send and receive HL7 messages.
6516
6517   VistA HL7 does not provide tools to map VistA data directly to HL7 messages. It does provide a repository of
6518   supported HL7 transactions, connectivity between systems, and guaranteed delivery of messages using supported
6519   Lower Layer Protocols (LLPs). It supports point-to-point interfaces, publish and subscribe, and content-based
6520   dynamic routing.
6521
6522   [*Lower Level Protocol refers to a portion of the Open Systems Interconnect (OSI) model. The OSI model is divided
6523   into seven layers or levels. The lower levels (Layers 1 through 4) support the actual movement of data between
6524   systems. This includes the actual physical connection between the systems and the communications protocol used.]
6525
6526   M-based VistA applications can use VistA HL7 to interfac!
6527   e with any other system that also supports standard HL7 messaging, including many standalone medical devices,
6528   non-M-based applications on other systems, and VistA M-based applications running on a different VA facility's
6529   systems. As such, VistA HL7 acts as an Enterprise Application Integration (EAI) solution for VistA applications.
6530
6531   HL7 Standard Support
6532   VistA HL7 supports message transactions for each of the following versions of the HL7 standard:
6533   • 2.1 (HL7 standard publication date: 6/1990)
6534   • 2.2 (HL7 standard publication date: 12/1994)
6535   • 2.3 (HL7 standard publication date: 4/1997)
6536   • 2.3.1 (HL7 standard publication date: 5/1999)
6537   • 2.4 (HL7 standard publication date: 11/2000)
6538
6539   Evolution of VistA HL7
6540   The first released version of VistA HL7 was 1.5, and supported simple point-to-point HL7 transactions between VistA
6541   and a local COTS system using Hybrid Lower Layer Protocol (HLLP), and to other VA facilities using VA MailMan.
6542   The initial release of version 1.6 added the ability to "broadcast" a message to multiple recipients, and support for the
6543   X3.28 LLP. A continuing increase in the demand for additional messaging services has resulted in enhancements to
6544   HL 1.6, released through patches, including more complex message routing (dynamic addressing), and messaging
6545   using Minimal Lower Layer Protocol (MLLP) over TCP.
6546
6547   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,
6548   and provides significantly higher operating efficiency and the ability to operate with a substantially decreased system
6549   load. In addition, HLO has some enhancements in the way it provides support for building and parsing of HL7
6550   messages.
6551




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
6552   Since the early 1990’s, the VA has maintained a corporate membership with the Health Level Seven standards
6553   organization, and has been an active participant in the evolution of the HL7 standard. Application developers for
6554   VistA's Radiology, Pharmac!
6555   y, Lab, PIMS, and other packages have aggressively enhanced those packages to support HL7-defined event points.
6556   Examples include "patient registration," "admit a patient," "lab results available," and "place an order." When one of
6557   these event points occurs, the VistA application now generates a corresponding HL7 message, which VistA HL7
6558   distributes to all interested subscribers.
6559
6560   Overview and Background - HL Optimized (HLO)
6561   HLO is an optimized version of HL 1.6.
6562    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
6563      (#870).
6564    There are more than 30 new routines used by HLO, as opposed to approximately 200 routines in the existing HL
6565      1.6.
6566    The new namespace is HLO*.
6567
6568   HLO engine will co-exist with the existing HL 1.6 engine.
6569    Existing HL7 applications written for the HL 1.6 engine (HL 1.6 applications) can continue to run without
6570      modification.
6571    The conversion of existing HL 1.6 applications to HLO applications can be fairly straightforward, though testing
6572      of the application is essential.
6573    There is virtually no shared code between the HL 1.6 and HLO engines. Thus, modifications and enhancements
6574      of applications written for one HL7 engine can be made without extensive testing of the application being
6575      required on the other HL7 engine.
6576
6577   Goals of HLO:
6578    Improve the messaging throughput.
6579    Make it easier for application developers to use.
6580    Make the software more robust, less susceptible to bugs, and require minimal maintenance overhead.
6581
6582   The following HL7 patches are required before installation of HL*1.6*126:
6583   • HL*1.6*84
6584   • HL*1.6*118
6585
6586   Archiving
6587   There is no archiving in the HL7 software package.
6588
6589   Purging
6590   For purging, use the Purge HL7 MESSAGE TEXT File Entries [HL PURGE TRANSMISSIONS] option in the HL7
6591   Main Menu (HL MAIN MENU), which purges entries from the !
6592   HL7 MESSAGE TEXT file (#772). The purge will only delete entries that are at least seven days old.
6593




       www.oserha.org                                       OSEHR System-Architecture, Product Definition and Roadmap           Page 3-2
6594   The HL7 MESSAGE TEXT file (#772) contains a record of all outgoing HL7 transmissions and their statuses. The
6595   purge [HL PURGE TRANSMISSIONS] option purges all entries in the file that have been successfully transmitted
6596   and, optionally, those entries with a status of ERROR IN TRANSMISSION.
6597
6598   To purge entries with an error status, run the [HL PURGE TRANSMISSIONS] option directly from the menu, and
6599   answer YES at the "Purge entries that were not successfully transmitted?" prompt. Entries with an error status should
6600   be reviewed before purging.
6601
6602   It is recommended that this option be queued to run once a day as a background task in order to automatically purge
6603   entries that were successfully transmitted.




6604
6605                                                       Figure: 3.3-11
6606
6607   3.3.10 IFR-Institution File Redesign
6608   NOTE: Kernel is the designated custodial software application for the Institution File Redesign (IFR)-related software.
6609   Kernel Patch XU*8.0*206 is designated as the primary Kernel patch for the IFR software.
6610
6611   Originally, the IFR software was released to the field as Kernel Patch XU*8.0*126 but was re-released and is
6612   superseded by Kernel Patch XU*8.0*206. In addition, through the years subsequent IFR-related software patches
6613   have been released in order to continually maintain and update the IFR software.
6614


       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
6615   Master Files—What is the Problem?
6616   In an open-architecture healthcare environment, there often exists a set of common reference files used by one or
6617   more applications. These files are called "master files." The INSTITUTION (#4) and FACILITY TYPE (#4.1) files are
6618   two examples of Veterans Health Information Systems and Technology Architecture (VistA) master files. With the
6619   advent of VA-wide data exchange initiatives, such as Master Patient Index/Patient Demographics (MPI/PD), the need
6620   to maintain reliable and accurate data within these master files across all Veterans Health Administration (VHA) sites
6621   has become more apparent.
6622
6623   Currently, the VHA does not automate updates and synchronization of national entries in standard master files
6624   utilized VHA-wide. Each individual VHA site is responsible for updating and maintaining the INSTITUTION and
6625   FACILITY TYPE master files located at their site. Through time and due to many unforeseen circumstances, these
6626   master files no longer contain accurate, synchronized national data. Thus, there is a need to provide a mechanism to
6627   automatically maintain reliable, accurate, and synchronized national data within the INSTITUTION and FACILITY
6628   TYPE master files across all sites VHA-wide.
6629
6630   Purpose
6631   The Institution File Redesign (IFR)-related software (i.e., Kernel Patch XU*8.0*206) provides the mechanism to
6632   standardize national entries in VistA's INSTITUTION (#4) and FACILITY TYPE (#4.1) master files and automatically
6633   update and maintain synchronization of these files at all sites VHA-wide. It also provides the baseline software to
6634   maintain other master files in the future. Thus, Kernel Patch XU*8.0*206 ensures that the data in the INSTITUTION
6635   and the FACILITY TYPE master files is reliable, accurate, and consistent VHA-wide. This allows sites to easily
6636   establish data sharing relationships without the overhead of researching each other's INSTITUTION and FACILITY
6637   TYPE file's data. This in turn ensures that future CIO initiatives involving multi-site data exchange will operate more
6638   effectively and efficiently.
6639
6640   In addition, Kernel Patch XU*8.0*206 does not alter the currently existing procedures for the following:
6641   • Requesting a New Station Number—The Information Management Service (045A4) will continue to approve the
6642        official Station Numbers. Non-VA Institutions must receive a Station Number to be included in the Institution
6643        Master File; VISN directors will continue to request new Station Numbers from the Chief Network Officer (10N).
6644   • Austin Automation Center (AAC) Coordination Requirements—The coordination requirements currently placed
6645        on sites by the Austin Automation Center (AAC) are not affected by this patch. The Institution Master File (IMF)
6646        on FORUM will immediately be updated upon notification from the Information Management Service (045A4).
6647        That updated data will then be immediately transmitted to all local INSTITUTION files (#4) VHA-wide via the
6648        Master File Server (MFS). This patch does not require any additional coordination with the AAC. The same,
6649        current procedures will be followed when the AAC has not yet updated its tables to include new Station Numbers
6650        stored in the INSTITUTION file (#4).
6651   • National Data Base Integration (NDBI) Procedures—NDBI will create new integrated sites after a new Station
6652        Number has been added to the Institution Master File (IMF) on FORUM and that information has been
6653        transmitted VHA-wide. Subsequent procedures followed by NDBI will remain the same.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
6654
6655                    Figure: 3.3-12
6656



       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
6657   3.3.11 KAAJEE-Kernel Authentication & Authorization for Java 2 Enterprise Edition
6658   The Kernel Authentication and Authorization for Java (2) Enterprise Edition (KAAJEE) software was developed by
6659   Common Services Security Program.
6660
6661   Kernel is the designated custodial software application for KAAJEE; however, KAAJEE comprises multiple software
6662   and patches from several HealtheVet-VistA applications.
6663
6664   KAAJEE is not an application but a framework. It provides secure sign-on architecture for HealtheVet-VistA Web-
6665   based applications. These HealtheVet-VistA Web-based applications are able to authenticating against Kernel on the
6666   VistA M Server via an Internet Browser on the client workstation and a middle tier application server (e.g.,
6667   WebLogic). KAAJEE is designed to run on the WebLogic 9.2 and higher.
6668
6669   KAAJEE addresses the Authentication and Authorization (AA) needs of HealtheVet-VistA Web-based applications in
6670   the J2EE environment. Over the long term, the Department of Veterans Affairs (VA) wil
6671   l provide AA services to perform end-user Authentication and Authorization enterprise wide; however, in the interim
6672   period, OI has a choice to make as to which AA mechanism(s) would be the most effective. This applies both to the
6673   needs of the applications themselves, as well as in anticipation of an expected migration to the future AA solution.
6674
6675   Most major J2EE application servers (e.g., WebLogic 9.2 and higher and Oracle's 10g) allow enterprises to override
6676   the default source of AA and replace it with custom, enterprise-specific sources for AA.
6677
6678   KAAJEE authenticates against a VistA M Server first with Access and Verify codes via VistALink's AV connection
6679   spec (i.e., KaajeeVistaLinkConnectionSpec). After the user has been properly authenticated against a VistA M
6680   Server, KAAJEE dynamically creates a temporary username and password and populates this into a Structured
6681   Query Language (SQL) database via custom Security Service Provider Interfaces (SSPIs). This username and
6682   password is needed for the second level/phase/pass authentication for the J2EE container.
6683
6684   Currently, Kernel maintains the primary VistA and HealtheVet-VistA user store (i.e., NEW PERSON file [#200]),
6685   which provides both Authentication and Authorization (AA) services for all VistA and HealtheVet-VistA applications.
6686   By leveraging Kernel, KAAJEE authenticates and authorizes J2EE Web users by using Kernel's AA capabilities.
6687
6688   Some potential advantages to employing Kernel as the AA source include the following:
6689   • Provides a single point of user management for existing and new HealtheVet-VistA applications.
6690   • Allows the use of an existing credential—the Access and Verify code—for Authentication and Authorization,
6691      rather than introducing a new security credential.
6692   • Eliminates the need to maintain a mapping from WebLogic accounts to VistA M Server Kernel accounts.
6693   • Avoids an additional user store, which simplifies the migration to the future AA solution.
6694   • Partitions user authorizations by Vete!
6695   • rans Health Administration (VHA) site.
6696
6697   Some potential KAAJEE strategy limitations due to employing Kernel as the AA source include the following:
6698   • Kernel user accounts are not currently VA-wide; instead, they are facility-specific.
6699   • Users must have an active VistA M Server Kernel account on some VistA system. Not all users fit this
6700      requirement (e.g., Veterans Affairs Central Office [VACO] users).



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
6701   •   This strategy introduces a dependency on the M system's availability, to perform virtually any function in a J2EE
6702       application.
6703   •   Correlating a user at one VA facility with the same user at a different VA facility is not supported, given the
6704       current lack of an enterprise-wide VA person identifier (e.g., VA-wide Person Identifier [VPID]).
6705
6706   REF: KAAJEE does not currently use the Department of Veterans Affairs Personal Identification (VPID), since this
6707   field is not currently populated enterprise-wide.
6708
6709   The KAAJEE software provides a Kernel-based Authentication and Authorization (AA) service for all HealtheVet-
6710   VistA Web-based applications in the J2EE/ WebLogic environment.
6711
6712   Features
6713   KAAJEE provides the following high-level features and functionality:
6714   • Prompts users to enter their Access and Verify code when he/she attempts to access a protected application
6715       resource for the first time during a user session.
6716   • Validates the entered Access and Verify code against the M system/division selected by the user at logon.
6717   • Permits administrators to configure the display list of M systems, by division, against which an end-user can log
6718       in.
6719   • Returns all VistA M Server J2EE security keys and uses these as the basis for authorization decisions, as each
6720       security key is cached as a WebLogic group name. The KAAJEE SSPIs currently use an external Oracle 10g
6721       database to store this information for later authentication.
6722
6723   KAAJEE roles are defined by the list of roles in the web.xml file, VistA M Server J2EE security keys, and WebLogic
6724   group name!
6725   s found in your application's weblogic.xml file.
6726
6727   REF: For more information on groups and roles, please refer to Chapter 5, "Role Design/Setup/Administration," in
6728   this manual.
6729
6730   •   (optional) Maps J2EE security role names with security key role names. Through <security-role-assignment>
6731       tags (e.g., in weblogic.xml) the actual J2EE security role names can be different than the security key role
6732       names. This mapping is optional, because if the same names are used throughout, no <security-role-
6733       assignment> tags are required.
6734
6735   REF: For a sample spreadsheet showing a mapping between WebLogic group names (i.e., principals) with J2EE
6736   security role names, please refer to "Appendix B—Mapping WebLogic Group Names with J2EE Security Role
6737   Names" in this manual.
6738
6739   •   Transforms valid Access and Verify codes into a J2EE-compatible username (e.g.,
6740       "kaaj_DUZ_8888~CMPSYS_523") and password, and submits the information to the J2EE container. It then
6741       passes the submitted information to the KAAJEE SSPIs, which validate the username and makes that username
6742       the current user.
6743




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
6744   Application developers can use the HttpServletRequest.getRemoteUser servlet method to return demographic data,
6745   such as the KAAJEE-created username (e.g., "kaaj_DUZ_8888~CMPSYS_523").
6746
6747   REF: For more information on formatting J2EE usernames, please refer to the "J2EE Username Format" topic in
6748   Chapter 7, "Programming Guidelines," in this manual.
6749
6750   •   Calls the KAAJEE SSPIs when the J2EE container checks user roles, which checks the role cache for the given
6751       user, created at user login. This allows user authorizations to be managed on the VistA M Server, and yet have
6752       fast response time in the J2EE application.
6753   •   Provides user demographics information, which includes the selected Division at login, user VPID, user DUZ,
6754       and user Name, all which are available to the application after login via the Session object (cookie).
6755
6756   REF: For more information on the user demographics provided, please refer to the following:
6757   • "LoginUserInfoVO Object" topic in Chapter 7, "Programming Guidelines," in this manual.
6758   • VistALink and the HealtheVet-VistA documentation can be downloaded from the VHA Software Document
6759      Library (VDL) Web site:
6760   • http://www.va.gov/vdl/
6761   • Uses the SIGN-ON LOG file (#3.081) on the VistA M Server (i.e., the same M system used for user
6762      authentication) to track user logons and logoffs.
6763
6764   REF: For more information on the SIGN-ON LOG file (#3.081), please refer to the Kernel Systems Management
6765   Guide.
6766
6767   Security Service Provider Interfaces (SSPIs) can be used by developers and third-party vendors to develop security
6768   providers for the WebLogic Server environment. SSPIs allow customers to use custom security providers for securing
6769   WebLogic Server resources.
6770
6771   Security providers are modules that "plug into" a WebLogic Server security realm to provide security services to
6772   applications. They call into the WebLogic Security Framework on behalf of applications implementing the appropriate
6773   SSPIs from the weblogic.security.spi package to create runtime classes for the security provider.
6774
6775   Some of the WebLogic security providers and utilities include (descriptions taken from WebLogic Website):
6776   • WebLogic Authentication Provider—"Supports delegated username/password authentication, and utilizes an
6777      embedded LDAP server to store, edit, and list user and group information." NOTE: KAAJEE (Iteration 1) does
6778      not use WebLog
6779   • ic's embedded LDAP server. It uses an Oracle 10g database to store users and groups by using SSPIs.
6780   • WebLogic Identity Assertion Provider—"Supports certificate authentication using X.509 certificates."
6781   • WebLogic Principal Validation Provider—"Signs and verifies the authenticity of a specific type of principal, much
6782      as an Identity Assertion provider supports a specific type of token; therefore, you can use the WebLogic Principal
6783      Validation provider to sign and verify principals that represent WebLogic Server users or WebLogic Server
6784      groups."
6785   • WebLogic Authorization Provider—"Supplies the default enforcement of authorization for this version of
6786      WebLogic Server. Using a policy-based authorization engine, the WebLogic Authorization provider returns an
6787      access decision to determine if a particular user is allowed access to a protected WebLogic resource."



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
6788   •    WebLogic Role Mapping Provider—"Determines dynamic roles for a specific user (subject) with respect to a
6789        specific protected WebLogic resource for each of the default users and WebLogic resources."
6790   • WebLogic Auditing Provider—"Records information from a number of security requests, which are determined
6791        internally by the WebLogic Security Framework. The WebLogic Auditing provider also records the event data
6792        associated with these security requests, and the outcome of the requests."
6793   • WebLogic MBeanMaker Utility—This command-line utility takes an MBean Definition File (MDF) as input and
6794        output files to generate an MBean type, which is used to configure and manage the security provider.
6795   NOTE: For more information on the WebLogic security providers, utilities, and other related information, please visit
6796   the following WebLogic Websites:
6797   http://e-docs.bea.com/wls/docs92/secintro/archtect.html
6798   http://e-docs.bea.com/wls/docs92/secintro/terms.html




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
6799
6800                    Figure: 3.3-13
6801



       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
6802   3.3.12 Kernel
6803   Kernel is a vendor-independent applications development environment, as well as a run-time environment providing
6804   standard vendor-independent services to applications software. It is not an operating system, but a set of utilities and
6805   associated files that are executed in an M environment. Kernel is central to VA VistA software strategy, in that it
6806   permits any VistA software application to run without modification on any hardware/software platform that supports
6807   American National Standards Institute (ANSI) Standard M. All operating system-specific, M implementation-specific,
6808   or hardware-specific code is isolated to Kernel. Therefore, porting VistA to a new environment requires modification
6809   only to a handful of Kernel routines.
6810
6811   As a whole, Kernel provides a computing environment that permits controlled user access, presents menus for
6812   choosing from various computing activities, allows device selection for output, enables the tasking of background
6813   processes, and offers numerous tools for system management and application programming. Kernel also provides
6814   tools for software distribution and installation.
6815
6816   VistA users see the same user interface, regardless of the underlying system architecture, because VistA
6817   applications are built using Kernel facilities for signon, database access, option selection, and device selection. As a
6818   result, user interaction with the system is constant across VistA applications.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
6819
6820                    Figure: 3.3-14
6821
6822




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
6823   3.3.13 KDC-Kernel Delphi Components
6824   Kernel Components for Delphi v4.0, v5.0, v6.0
6825   This version of the Kernel Delphi Components provides programmers with the capability to develop and deploy new
6826   VISTA client/ server software using the Kernel Delphi Components in the 32-bit environment.
6827
6828   Please note that multiple installation procedures are provided in this guide. The Kernel Delphi Components have
6829   separate installations for the following target environments:
6830   • Programmer Client Workstations
6831   • VISTA M Servers
6832




6833
6834                                                     Figure: 3.3-15
6835
6836   3.3.14 Kernel Toolkit
6837   All Kernel Toolkit content will be moved to the appropriate Kernel manual, section, and chapter, except where noted
6838   below. Toolkit resides on the Kernel's Systems Manager Menu [EVE]
6839
6840   All of the combined Kernel/Kernel Toolkit manuals and standalone Kernel/ Kernel Toolkit manuals will now be located
6841   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-2
6842
6843   The Kernel Toolkit is a robust set of tools developed to aid the Decentralized Hospital Computer Program (DHCP)
6844   development community and Information Resources Management (IRM) in writing, testing, and analysis of code. It is
6845   a set of generic tools that are used by developers, documenters, verifiers, and packages to support distinct tasks.
6846
6847   The Kernel Toolkit provides utilities for the management and definition of development projects. Many of these
6848   utilities have been used by the San Francisco Information Systems Center (ISC) for internal management and have
6849   proven valuable. Kernel Toolkit provides many programming and system management tools, and interacts directly
6850   with the underlying MUMPS (Massachusetts General Hospital Utility Multi-Programming System) environment in
6851   many different ways.
6852
6853   Also included in Kernel Toolkit are the following tools provided by other ISCs, and supported by the San Francisco
6854   ISC, based on their proven utility:
6855    Multi-Term Look-Up (MTLU){ XE "Multi-Term Look-Up (MTLU)" }:
6856    Duplicate Resolution Utilities{ XE "Duplicate Resolution Utilities," }:
6857
6858   The Parameter Tools patch (XT*7.3*26) provides a method of managing the definition, assignment, and retrieval of
6859   parameters for VistA software applications.
6860
6861   VistA software applications are designed to be used in a variety of ways. Many aspects of hospital activity vary from
6862   one hospital to another and thus there are many possible ways software applications can be used that also vary from
6863   one institution to another. Each site has its own requirements—its own settings for each software application. IRM
6864   staff must modify the software parameters to fit their requirements.
6865
6866   Previously, each software application had its own files and options but no two software applications had the site
6867   parameters set up the same way or found in the same place. Thus, when a new software application was released,
6868   each site would have to look for the location where the settings were stored for that software. Next, they would have
6869   to look to see what settings were available and how to set them. Very little about the parameters was uniform from
6870   software to software.
6871
6872   With the Computerized Patient Record System (CPRS) software, the idea was born that a parameter file could be
6873   created to export with the software. The CPRS parameter file and parameter utility were subsequently modified to
6874   create a generic method of exporting and installing other VistA software applications. Most developers were willing to
6875   abandon previous methods and use this tool for software they were developing.
6876
6877   Parameter Tools was designed as a method of managing the definition, assignment, and retrieval of parameters for
6878   VistA software. A parameter may be defined for various levels at which you want to allow the parameter described
6879   (e.g., software level, system level, division level, location level, user level).
6880
6881   Patch XT*7.3*26 contains a developer toolset that allows creation of software parameters in a central location.
6882   Integration Agreements (IAs) 2263 and 2336 define the supported entry points for this application. Kernel Patch
6883   XU*8.0*201 allows KIDS to transport the parameters.
6884




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
6885   VistA Patch Monitor is being released in Kernel Toolkit Patch XT*7.3*98. This package is designed to assist package
6886   support and management personnel in keeping up with VistA patch requirements. It monitors patches as they arrive
6887   in the VistA MailMan, records pertinent data and then monitors them on a daily basis through automated processing.
6888
6889   This package will track only patches that are released from the National Patch Module on Forum. It will not track
6890   Class III patches, test patches or hand-entered patches from other sources due to its link with the Kernel Installation
6891   and Distribution System (KIDS) INSTALL file (#9.7).




6892
6893                                                        Figure: 3.3-16
6894
6895   3.3.15 Kernel Unwinder
6896   The Unwinder is a utility that is used in conjunction with the Protocol file (#101) to create modular building blocks for
6897   applications.
6898
6899   The Unwinder allows hierarchical traversing of menus, as found in Menu Management, and also the structuring of
6900   order protocols into independent, reusable modules. Each node becomes a "building block" from which more
6901   sophisticated modules may be built. For instance, the node "Order Shirt" may have as sub-items, "Get Size," "Get
6902   Color," "Get Style," and "Get Delivery Date." Each of these sub-items may, in turn, be used to build other modules.
6903



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
6904   Provisions have been made to allow additional building blocks to be placed at the item level of the node. Their
6905   purpose is to allow modifying actions to be executed and thus increase the flexibility of each module.




6906
6907                                                       Figure: 3.3-17
6908
6909   3.3.16 List Manager
6910   List Manager was originally developed as an interface for the Scheduling module of DHCP's MAS V. 5.2 package.
6911   Since then it has been used as an interface for a number of other applications, including Text Integration Utility and
6912   NOIS (National Online Information Sharing).
6913
6914   Core Functions
6915   List Manager provides a generic method of presenting lists of items to terminal users. Its core functions are:
6916   • Display a list of items.
6917   • Users can browse through the list.
6918   • Users can select one or more items from the list.
6919   • Users can execute an action for selected list items.
6920   • You can use List Manager recursively within an action.
6921                                                      Figure: 3.3-18
6922
6923




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
6924
6925   3.3.17 M-to-M Broker
6926   The VistA M-to-M Broker is a new implementation of the RPC Broker offering Client/ Server functionality resident
6927   solely within a VistA non-Graphical User Interface (GUI) environment. It enables the exchange of VistA M-based data
6928   and business rules between two VistA M servers, where both servers reside on local and/or remote VistA systems:
6929   • The requesting server functions in the capacity of a Client.



       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-2
6930   •   The server receiving that request functions in the capacity of a Server.
6931
6932   The Client/ Server roles of each server can vary depending on what point in time each VistA M server is making the
6933   request for data from its counterpart VistA M server.
6934
6935   All M-to-M Broker client and server routines are packaged in one KIDS build, Patch XWB*1.1*34, which will need to
6936   be installed on all VistA systems required for M-to-M Broker processing.
6937
6938   Scope
6939   The M-to-M Broker provides a new implementation of the RPC Broker enabling the exchange of VistA M-based data
6940   and business rules between two VistA M servers, where both servers reside on the same, or on different VistA M
6941   systems.
6942
6943   For the VistA Imaging Digital Imaging and Communication in Medicine (DICOM) Gateway, the M applications on
6944   separate VistA systems will be converted to use this new M-to-M Broker software to communicate to the main VistA
6945   Hospital Information System (HIS). This eliminates the need for Distributed Data Processing (DDP).
6946
6947   Background
6948   VistA Imaging requested the development of the M-to-M Broker to be used to communicate between the M client on
6949   the VistA Imaging DICOM Gateway and the M server on the main HIS.
6950
6951   The VistA Imaging DICOM Gateway architecture uses M software on a workstation to create associations between
6952   newly acquired images and computerized patient records. Before the development of the M-to-M Broker, the gateway
6953   system communicated with the main Hospital Information System using the DDP protocol, stored the acquired
6954   images on Microsoft Operating System (NT) file servers, and set database entries to reference them.
6955
6956   Problems with DDP (Distributed Data Processing):
6957   • Causes database inconsistencies
6958   • Lacks security
6959   • Bound to MAC addresses
6960   • Responds slow on a busy Hospital Information System and/or network
6961   • Runs very slowly in a Wide Area Network (WAN) environment because of inherent network latencies
6962
6963   WARNING: Because of the database inconsistency problem, incidents of matching images to the wrong patient
6964   occurred at one particular site.
6965
6966   DDP provides no security. M-to-M Broker uses many of the robust security features implemented by the VistA RPC
6967   Broker and Kernel software. These security features are transparent to the end-user and without additional impact on
6968   Information Resources Management (IRM).
6969
6970   About the Remote Procedure Call (RPC) Broker
6971   The RPC Broker (also referred to as "Broker") is a Client/Server system within VA's Veterans Health Information
6972   Systems and Technology Architecture (VistA) environment. It establishes a common and consistent foundation for




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap           Page 3-2
6973   Client/Server applications being written as part of VistA. It enables client applications to communicate and exchange
6974   data with M Servers.
6975
6976   The RPC Broker is a bridge connecting the client application front-end on the workstation (e.g., Delphi GUI
6977   applications) to the VistA M-based data and business rules on the server. It links one part of a program running on a
6978   workstation to its counterpart on the server.
6979
6980   INFORMATION: For information on the RPC Broker, documentation is made available online in Adobe Acrobat
6981   Portable        Document         Format          (PDF)      at the   following       Web       address:
6982   http://vaww.vista.med.va.gov/vdl/Infrastructure.asp#App23 .




6983
6984                                                       Figure: 3.3-19
6985
6986   3.3.18 MailMan
6987   NOTE: Installation of MailMan v8.0 requires that a site already have MailMan v7.1 installed and running, and that it is
6988   fully patched through at least MailMan Patch XM*7.1*198.
6989
6990   MailMan has many documented Application Program Interfaces (APIs). In addition to the "classic" APIs, additional
6991   APIs have been created to support other front ends to MailMan (e.g., a Graphical User Interface [GUI]). Where
6992   possible, existing MailMan code has been altered to use the latest APIs.
6993
6994   MailMan, the Department of Veterans Affairs (VA) electronic mail system, is a communications tool that provides
6995   electronic communication among users sharing computing facilities. A communications link can be made with cables,
6996   telephone lines, or satellite connections. In this manner, the networking of electronic mail on a large scale is made
6997   possible.
6998
6999   MailMan provides teleconferencing via chained responses. MailMan is the transport vehicle for most VistA
7000   applications. MailMan is also used to preserve copies of software and data. MailMan also has the ability to include
7001   non-textual data in messages (i.e., Multimedia). Network features allow users to construct dialogues for logging onto
7002   remote systems for mail delivery. Message actions allow users great flexibility in managing personal mail. Users can



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
7003   address mail to individuals and groups at local and remote sites, with the tedium of waiting for process completion
7004   being reduced by the system's background filer. In addition, the system has extensive online documentation, which
7005   can be printed to create a manual.
7006
7007   MailMan is designed to allow users to send and receive mail from individuals or groups. A message can take the
7008   form of a personal letter or a formal bulletin extracting data from VA FileMan. The text of messages is not difficult to
7009   edit, and the context can be made confidential in several ways. Surrogates can be appointed to read mail. Mail
7010   groups can be set up to allow each member to respond to a message and to view the replies, as in an informal
7011   committee meeting. Mail can be sorted, deleted, forwarded, queried, copied, revised, or printed. In addition, MailMan
7012   cross-references messages by subject and message number.
7013
7014   MailMan allows users to send, receive, copy, respond to, and organize electronic mail. It has entry points to allow
7015   other applications to trigger bulletins or send messages without user intervention. There is a communications facility
7016   (i.e., TalkMan) to allow users to automatically hook into the VA Wide Area Network(WAN) or modems. This feature
7017   connects the user to a remote domain, playing the script to that domain without displaying it to the user. It then
7018   informs the user that the connection was successful, and can capture whatever has been displayed to the user's
7019   terminal into a message called DIALOGUE CAPTURE.
7020
7021   An extended search for messages can be invoked at the "Message Action" prompt or as a stand-alone option. The
7022   extended search includes filters on the subject, sender, recipient, responder, the date sent, and text contents.
7023
7024   MailMan informs users of network delivery failures and their causes. Message characteristics including Closed,
7025   Confidential, Confirmation Requests, Information, and Scrambling can be carried across the network. Software
7026   security information for PackMan can also be conveyed on the network.
7027
7028   MailMan allows the transfer of any word-processing text from any VA FileMan file or message into a message or
7029   response. New documents are placed in a user's "IN" basket or to any other designated basket (e.g., based on mail
7030   filters).




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-2
7031
7032                                                         Figure: 3.3-20
7033
7034   3.3.19 MPI-Master Patient Index
7035   Master Patient Index/ Patient Demographics (MPI/PD) was developed to initialize active patients to the Master
7036   Patient Index (MPI) and to establish the framework for the sharing of patient information between sites. During the
7037   process of initialization to the Master Patient Index, each active patient received:
7038   • An Integration Control Number (ICN)
7039   • A Coordinating Master of Record (CMOR)
7040   • A Treating Facility List of sites where the patient is also known by this ICN
7041
7042   Each site becomes part of the network of sites that share key demographic data for patients via HL7 messaging.
7043   Master Patient Index VistA (MPI) and Patient Demographics (PD) were distributed and installed together. This
7044   manual covers the functionality of both packages.
7045
7046   The objectives of the MPI/PD VistA are to:
7047   • Create an index that uniquely identifies each active patient treated by the Veterans Administration.
7048   • Identify the sites where a patient is receiving care.
7049
7050   This is crucial to the sharing of patient information across sites.
7051
7052   Master Patient Index Patch MPI*1*40 constituted a change in the business process that updates the patient identity
7053   fields across VA facilities. Patch MPI*1*40 phased out the use of the facility Coordinating Master of Record (CMOR)
7054   concept, and introduced the Primary View methodology. Primary View is an enterprise view of the most current data
7055   for a patient based on authority scoring and the latest data rules.
7056
7057   History




       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap       Page 3-2
7058   MPI/PD was originally part of the Clinical Information Resource Network (CIRN) project. CIRN was to be a three-
7059   phase project consisting of Phase 1: Pre Implementation (site cleanup), Phase 2: Master Patient Index/Patient
7060   Demographics (Master Patient Index seeding for VHA-wide patient identification and patient demographics
7061   synchronization), and Phase 3: CIRN Clinical Repository. Master Patient Index/Patient Demographics is now a
7062   separate, independent package. Due to its beginnings, you will still notice references to CIRN (e.g., shared name
7063   and number spaces, file names, package terminology, etc.). The clinical repository is now a separate, independent
7064   project called Health Data Repository (HDR).
7065
7066   Distinguishing MPI (Austin) from MPI/PD (VistA)
7067   MPI (Austin) refers to the actual index located at the Corporate Data Center Operations (CDCO). MPI/PD (VistA)
7068   refers to the software that resides in VistA at sites and sends patient data to the MPI (Austin) and to other sites where
7069   a patient has been seen. These terms i.e., MPI (Austin) and MPI/PD (VistA) are used throughout this manual only
7070   when it is not obvious to which component of the MPI the documentation is referring. Otherwise, the reader should
7071   assume the information is referring to MPI/PD (VistA).
7072
7073   Master Patient Index (Austin)
7074   The Master Patient Index (MPI) is located at the Austin Information Technology Center (AITC). It is composed of a
7075   unique list of patients and an associated list of VAMCs (Veterans Affairs Medical Centers) and other systems of
7076   interest where each patient has been seen. This enables the sharing of patient data between operationally diverse
7077   systems. Each patient record (or index entry) on the MPI contains multiple demographic fields which are updated to
7078   the Primary View of the MPI.
7079
7080   When a patient is first presented into the MPI for an Integration Control Number (ICN) assignment, that patient's
7081   identifying information (i.e., name, Social Security Number (SSN), date of birth, gender, mother's maiden name,
7082   multiple birth indicator, place of birth city and state) is passed to the MPI.
7083
7084   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
7085   also made to see if the patient's internal entry number (DFN) from the querying site is already known to the MPI. If
7086   so, this is also considered an exact match. If an exact match is found, the ICN, and ICN Checksum are returned to
7087   the requesting site. The requesting site is added to the list of treating facilities (TF) in which this patient has been
7088   seen and the updated list is broadcasted to all systems of interest, including VAMCs.
7089
7090   If an exact match is not found, the MPI returns a message indicating this. The patient entry is then added to the MPI.
7091   If a potential match is found, a potential match exception is logged for the HC IdM group to review, the patient is still
7092   added to the MPI.
7093
7094   NOTE: The term "systems of interest" refers to VA facilities that have seen patients and entered them as entries onto
7095   the MPI. This also refers to non-VistA systems that have a registered interest in a patient (e.g., Federal Health
7096   Information Exchange [FHIE], HomeTeleHealth, Person Service Identity Management [PSIM], Health Data
7097   Repository [HDR], etc).
7098
7099   HC IdM Team is Data Steward for the Master Patient Index (MPI)
7100   The Healthcare Identity Management (HC IdM) team is the Data Steward for the Master Patient Index (MPI). They
7101   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-2
7102   •   View and/or edit the authority values for the Primary View business rules criterion.
7103   •   Override Primary View identity traits for selected identity fields in the MPI VETERAN/CLIENT file (#985) and
7104       broadcast the new Primary View out to the systems of interest.
7105   •   View the Primary View Reject Report from the data in the MPI REJECTED UPDATE file (#985.65).
7106
7107   NOTE: For a list of the fields stored on the MPI, see the section titled: "Appendix B: Data Stored on the MPI in
7108   Austin" in this documentation.
7109
7110   Master Patient Index/Patient Demographics (VistA)
7111   The Master Patient Index/Patient Demographics (MPI/PD) software resides in VistA enabling sites to:
7112   • Request an ICN assignment.
7113   • Resolve a potential duplicate on the MPI.
7114   • Review and process exceptions received from MPI including Primary View Reject exceptions.
7115   • Query the MPI (Austin) for known data.
7116   • Update the MPI when changes occur to demographic fields stored on the MPI or of interest to other
7117       facilities/systems of interest.
7118
7119   Distinguishing MPI (Austin) from MPI/PD (VistA)
7120   MPI (Austin) refers to the actual index located at the Corporate Data Center Operations (CDCO). MPI/PD (VistA)
7121   refers to the software that resides in VistA at sites and sends patient data to the MPI (Austin) and to other sites where
7122   a patient has been seen. These terms i.e., MPI (Austin) and MPI/PD (VistA) are used throughout this manual only
7123   when it is not obvious to which component of the MPI the documentation is referring. Otherwise, the reader should
7124   assume the information is referring to MPI/PD (VistA).
7125
7126   Master Patient Index (Austin)
7127   The Master Patient Index (MPI) is located at the Austin Information Technology Center (AITC). It is composed of a
7128   unique list of patients and an associated list of VAMCs (Veterans Affairs Medical Centers) and other systems of
7129   interest where each patient has been seen. This enables the sharing of patient data between operationally diverse
7130   systems. Each patient record (or index entry) on the MPI contains multiple demographic fields which are updated to
7131   the Primary View of the MPI.
7132
7133   When a patient is first presented into the MPI for an Integration Control Number (ICN) assignment, that patient's
7134   identifying information (i.e., name, Social Security Number (SSN), date of birth, gender, mother's maiden name,
7135   multiple birth indicator, place of birth city and state) is passed to the MPI.
7136
7137   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
7138   also made to see if the patient's internal entry number (DFN) from the querying site is already known to the MPI. If
7139   so, this is also considered an exact match. If an exact match is found, the ICN, and ICN Checksum are returned to
7140   the requesting site. The requesting site is added to the list of treating facilities (TF) in which this patient has been
7141   seen and the updated list is broadcasted to all systems of interest, including VAMCs.
7142
7143   If an exact match is not found, the MPI returns a message indicating this. The patient entry is then added to the MPI.
7144   If a potential match is found, a potential match exception is logged for the HC IdM group to review, the patient is still
7145   added to the MPI.



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-2
7146
7147   NOTE: The term "systems of interest" refers to VA facilities that have seen patients and entered them as entries onto
7148   the MPI. This also refers to non-VistA systems that have a registered interest in a patient (e.g., Federal Health
7149   Information Exchange [FHIE], HomeTeleHealth, Person Service Identity Management [PSIM], Health Data
7150   Repository [HDR], etc).
7151
7152   HC IdM Team is Data Steward for the Master Patient Index (MPI)
7153   The Healthcare Identity Management (HC IdM) team is the Data Steward for the Master Patient Index (MPI). They
7154   have the ability to perform the following functions on the Primary View of the MPI:
7155   • View and/or edit the authority values for the Primary View business rules criterion.
7156   • Override Primary View identity traits for selected identity fields in the MPI VETERAN/CLIENT file (#985) and
7157       broadcast the new Primary View out to the systems of interest.
7158   • View the Primary View Reject Report from the data in the MPI REJECTED UPDATE file (#985.65).
7159
7160   NOTE: For a list of the fields stored on the MPI, see the section titled: "Appendix B: Data Stored on the MPI in
7161   Austin" in this documentation.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-2
7162
7163                                                       Figure: 3.3-21
7164
7165   3.3.20 MDWS-Medical Domain Web Services
7166   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-2
7167
7168                                                     Figure: 3.3-22
7169
7170   3.3.21 Name Standardization
7171   The Name Standardization (Patch XU*8.0*134) provides utilities that enable VISTA applications to standardize the
7172   way person names are entered and stored in Veterans Health Administration (VHA) databases.
7173
7174   Features
7175   The Name Standardization release (Patch XU*8.0*134) features:
7176   • A standard format for person names in VISTA.
7177   • The data conversion of the NEW PERSON file (#200).
7178   • A new NAME COMPONENTS file (#20).
7179   • Changes to the data dictionary of the NEW PERSON file.
7180   • Changes to Kernel options that allow editing of individual name components.
7181   • New Application Programming Interfaces (API)s.
7182   • A new VA FileMan FUNCTION to display names in various formats.
7183
7184   Patch Designation(s): A4A7*1.01*11
7185   Description: Remove the DD and data for Files #3, #6, #16, and #20, and the x-refs in File #200 that set data into
7186   them.




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap           Page 3-2
7187
7188                    Figure: 3.3-23
7189
7190




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-2
7191   3.3.22 NOIS-National Online Information Sharing
7192   Used to track requests for service. It is used on Forum and can be implemented for local use. NOIS can be used as
7193   only an M application or as a client/server application with M as the server and Windows as the client.




7194
7195                                                       Figure: 3.3-24
7196
7197   3.3.23 National Patch Module
7198   The National Patch Module (NPM) is a software package that provides a database for the distribution of software
7199   patches and updates for the Department of Veterans Affairs' Decentralized Hospital Computer Program (DHCP).
7200   Options are provided for systematic entry and review of patches by developers, review and release of patches by
7201   verifiers, and display and distribution of the released verified patches to the users.
7202
7203   Once a problem is found in DHCP software and the solution identified, a developer enters a patch in the NPM
7204   identified by package namespace, version, and a patch number. At this point, the patch entry has a status of "under
7205   development" and is accessible only by other developers of the package. When the patch is completed and ready for
7206   review, a second developer changes the status to "completed/unverified" and the patch becomes available for review
7207   by designated verifiers of the package. After the verifier(s) have checked the patch and determined that it is ready for
7208   release, the status is changed to "verified". The patch is automatically distributed and becomes available for display
7209   by users.



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-3
7210
7211                                                        Figure: 3.3-25
7212
7213   3.3.24 NHE-Network Health Exchange
7214   Network Health Exchange (NHE) Version 5.1, a component of the Department of Veterans Affairs (VA) Veterans
7215   Health Information Systems and Technology Architecture (VistA), is software that allows Veterans Affairs Medical
7216   Centers (VAMC)s to request either complete or pharmacy patient Health Summaries from each other. NHE was
7217   created by the Chicago Westside VAMC. This software is being released as an interim bridge to a more fully
7218   integrated clinical patient data exchange system.
7219
7220   Network Health Exchange (NHE) was developed at the Chicago Westside Veterans Affairs Medical Center (VAMC)
7221   and has evolved over several iterations. The Network Health Exchange is VistA software that provides clinicians with
7222   quick and easy access to patients' information from any site where they have been treated. NHE provides the
7223   computer mechanism for VAMC clinicians to retrieve clinical patient data from other medical centers. The requester
7224   is notified of returned patient data through an alert that appears with the VistA menu system. Patient data is
7225   displayed in a format similar to the integrated clinical reports found in Health Summary and can be viewed onscreen
7226   or printed.
7227
7228   The NHE software accesses several other VistA files which contain information concerning diagnoses, prescriptions,
7229   laboratory tests, radiology exams, hospital admissions, and clinic visits. This allows a clinical staff to take advantage
7230   of clinical data supported through VistA.
7231
7232   Network Health Exchange is based on the Health Summary software. However, NHE does not make calls to Health
7233   Summary so it is not necessary for a site to install Health Summary nor is familiarity with Health Summary required in
7234   order to use NHE.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-3
7235
7236                                                       Figure: 3.3-26
7237
7238   3.3.25 PDX-Patient Data Exchange
7239   The Patient Data Exchange (PDX) software is designed to manage the transfer of patient information (demographics,
7240   episodes of care, medications, and diagnostic evaluations) between VA facilities using the MailMan electronic mail
7241   utility. Once transferred, this information may be combined with pertinent local information and assembled into a
7242   coherent composite record.
7243
7244   To which VistA Allergy Tracking application this is referring is not known. Identified in PDX-Patient Data Exchange
7245   Technical Manual, Section 7, External/ Internal Relations in listing of, "minimum software versions or higher are
7246   required in order to install this version of PDX."
7247
7248   Requests for PDX data can be processed manually or automatically. For requests to be processed manually, the site
7249   would have to be a member of the Release Group and meet the requirements for automatic processing. Records
7250   determined to be "sensitive" and those which exceed the maximum time and occurrence limits for Health Summary
7251   components may not be returned automatically and will be held for manual processing.
7252
7253   PDX V. 1.5 uses the List Manager utility extensively. The List Manager is a tool designed to display a list of items. It
7254   allows you to select items from the list and perform specific actions against those items.
7255
7256   The software provides numerous system reports (current transactions and work- load) that allow predefined and
7257   customizable sorts.
7258
7259   The Following is a brief description of the major options and menus contained in the PDX software:
7260   • Request PDX for Patient—This option is used to electronically request PDX data for a selected patient from
7261       another VA facility(s).
7262   • Unsolicited PDX—This option is used to send PDX information to a remote site without having first received a
7263       request.


       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-3
7264   •   Process External PDX—This option is used to process PDX requests received from other VA facilities that do
7265       not meet the criteria for automatic processing.
7266   • Load/Edit PDX Data—This option allows you to load or edit data fields in your PATIENT file with data from your
7267       PDX file.
7268   • Display PDX Data Menu—This menu allows you to display or print PDX data for a selected patient by either
7269       transaction or user who requested the information.
7270   • System Reports Menu:
7271             Requires Processing Report—This option is used to print a report of all PDX requests that require
7272                 manual processing.
7273             Current Transactions Report Menu—The options on this menu allow you to print reports of PDX
7274                 transactions on file by several different sorting methods.
7275             Workload Reports Menu—The options on this menu allow you to print workload reports of PDX
7276                 transactions on file by several different sorting methods.
7277   • PDX Edit Files Menu:
7278             Add/Edit Fields to Encrypt—This option provides the ability to encrypt selected data fields in the PDX
7279                 transmission.
7280             Edit Maximum Limits for Automatic Processing—This option is used to edit the maximum time and
7281                 occurrence limits that your site is willing to allow for automatic processing of a PDX transaction.
7282             Add/Edit Outgoing Group—This option is used to create outgoing groups and add/edit/delete remote
7283                 facilities in those groups.
7284             Edit Parameter File—This option is used to set up site specific PDX parameters.
7285             Add/Edit Segment Group Options—These three options are used to create segment groups (selected
7286                 group of data segments).
7287             Add/Edit Release Group—This option is used to enter/edit facilities into the release group for automatic
7288                 processing of PDX requests.
7289   • Purging Menu—These three options provide purging capabilities by default age, user defined age, or user defined
7290   date.




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
7291
7292                                                       Figure: 3.3-27
7293
7294   3.3.26 RPC-Remote Procedure Call Broker
7295   The RPC Broker is considered to be part of the infrastructure of VistA. It establishes a common and consistent
7296   foundation for communication between clients and VistA M Servers.
7297
7298   The RPC Broker is a bridge connecting the client application front-end on the workstation (e.g., Delphi GUI
7299   applications) to the M-based data and business rules on the server. It links one part of a program running on a
7300   workstation to its counterpart on the server. The client and the server can be, and most often are, written in different
7301   computer languages. Therefore, the RPC Broker bridges the gap between the traditionally proprietary VistA and
7302   COTS/HOST products.
7303
7304   The RPC Broker includes:
7305   • A common communications driver for the M server interface that handles the device-specific characteristics of
7306       the supported communications protocol.
7307   • An interface component on the M server, separate from the communications driver, that interprets client
7308       messages, executes the required code, and eventually returns data to the communications driver.
7309   • A common file on the M server that all applications use to store the information about the queries to which they
7310       respond (i.e., REMOTE PROCEDURE file [#8994]).
7311   • The Client Agent application that runs on client workstations, supporting single signon.
7312   • The TRPCBroker component for Delphi, enabling development of client applications that can communicate via
7313       the RPC Broker.
7314   • A dynamic link library (DLL) that provides access to RPC Broker functionality for development environments
7315       other than Delphi.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-3
7316
7317                                                      Figure: 3.3-28
7318
7319   3.3.27 Resource Usage Monitor
7320   The Resource Usage Monitor (RUM) software is a fully automated support tool developed by Capacity Planning (CP)
7321   Services. It entails the capture of all system and VistA option workload specifics from participating sites. This
7322   workload data is then summarized on a weekly basis and is automatically transferred via network mail (i.e., MailMan)
7323   to the Capacity Planning National Database.
7324
7325   The Veterans Health Administration (VHA) developed the Resource Usage Monitor (RUM) software in order to obtain
7326   more accurate information regarding the current and future VistA system and option workload at the VA Medical
7327   Centers (VAMCs).
7328
7329   Installing the RUM software creates the collection process mechanism and other necessary components of the
7330   software. The fully automated data collection mechanism entails capturing all system and VistA option workload
7331   specifics at the site into a temporary ^KMPTMP("KMPR") temporary collection global. The collection mechanism is
7332   continuously monitoring each process on the system while trapping system and VistA option workload data.
7333
7334   On a nightly basis, the RUM Background Driver option [KMPR BACKGROUND DRIVER] moves the data within the
7335   ^KMPTMP("KMPR") temporary collection global to the RESOURCE USAGE MONITOR file (#8971.1). Upon
7336   completion, the data within the ^KMPTMP("KMPR") temporary collection global is purged.
7337
7338   Every Sunday night, the RUM Background Driver option [KMPR BACKGROUND DRIVER] monitors the RESOURCE
7339   USAGE MONITOR file to ensure that only a maximum of three weeks worth of data is maintained at the site.
7340
7341   Also, each Sunday night, the RUM Background Driver option automatically compresses the information contained
7342   within the RESOURCE USAGE MONITOR file (#8971.1) into weekly statistics. These weekly statistics are converted
7343   into an electronic mail message that is automatically transferred via network mail (i.e., VistA MailMan) and merged
7344   into a Capacity Planning National Database where this data is used for evaluation purposes. The site also receives a
7345   summary of the system workload data in the form of an electronic turn-around message.



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
7346
7347                                                      Figure: 3.3-29
7348
7349   3.3.28 SSO/UC-Single Signon/User Context
7350   SSO/UC is not an application but a framework. Users of the software need to understand how it integrates in their
7351   working environment. Thus, installing SSO/UC means to understand what jars and files need to be put where and
7352   what are the configuration files that you need to have and edit.
7353
7354   SSO/UC provides a secure signon architecture for Vista client/ server-based applications. For example:
7355   • Care Management
7356   • Computerized Patient Record System-Rehosted (CPRS)
7357   • Vitals
7358
7359   These VistA client/server-based applications are able to authenticating against Kernel on the VistA M Server via an
7360   application graphical user interface (GUI) on the client workstation.
7361
7362   Kernel (i.e., Kernel Patch XU*8.0*337) is the designated custodial software package of the Infrastructure & Security
7363   Services (ISS) SSO/UC and related software. However, SSO/UC comprises/ depends on multiple patches and
7364   software releases from several VistA/HealtheVet-VistA applications.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
7365
7366                                                      Figure: 3.3-30
7367
7368   3.3.29 SlotMaster (Kernel ZSLOT)
7369   Slotmaster is a quick login utility for VMS systems. SlotMaster is a combination of items which include DCL
7370   procedures and MUMPS routines. It utilizes a feature available under VMS LAT known as dedicated LAT ports where
7371   an application can be dedicated to a specific LAT device. Slotmaster saves users time by letting the user connect
7372   directly to an active M partition. This saves users from sitting through VMS process creation and loading an M
7373   partition, allowing them to log in to DHCP directly.
7374
7375   Slotmaster also conserves system resources by re-using the same VMS process for new users, rather than creating
7376   a new process for each new user.
7377
7378   Only "DETACH" mode of SlotMaster supported.
7379
7380   How SlotMaster Works
7381   SlotMaster is a combination of DCL command procedures and M routines. It uses a feature available under
7382   OpenVMS LAT known as dedicated LAT ports. With dedicated LAT ports, an application can be dedicated to a set of
7383   specific LAT devices.
7384
7385   With SlotMaster, the user connects to a service that is a set of dedicated LAT ports that are connected to already
7386   running ZSLOT0 DSM jobs waiting to call the Kernel's sign-on. This keeps the user and the system from having to go
7387   through process creation and image activation at the time of login to DHCP applications.
7388
7389   SlotMaster Process
7390   The system manager starts up SlotMaster on a given node using the STARTUP$ZSLOT.COM command file. This
7391   command file creates a set of custom files and submits them to a VMS queue. These files start up the set of slot
7392   processes for the node, plus one instance of a controller process, called SlotMaster, that manages the set of slots.
7393   The SlotMaster process scans the set of slots for the current node, restarts processes that have been force-exited or
7394   have otherwise disappeared, and collects usage statistics for reference.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-3
7395
7396                                                        Figure: 3.3-31
7397
7398   3.3.30 SQLI-SQL Interface
7399   VistA's SQLI software product (part of VA FileMan), along with an M-to-SQL Product purchased from a vendor (see
7400   below), provides SQL access to your VA FileMan data.
7401
7402   From an operational point of view, VA FileMan is a hierarchical database, because it supports multiples (nested
7403   tables). However, the nature of VA FileMan's underlying file and data dictionary structures allow its files and multiples
7404   to be viewed as relational tables as well.
7405
7406   M-to-SQL vendors have provided relational access to VA FileMan data in the past by scanning VA FileMan's internal
7407   data dictionary structures, and interpreting the information found there to provide a relational view of the underlying
7408   data.
7409
7410   SQLI software (i.e., VA FileMan Patch DI*21.0*38) insulates the M-to-SQL vendors from direct access to VA
7411   FileMan's internal data dictionaries by projecting all information needed for a relational view of VA FileMan in a
7412   supported manner. Instead of accessing internal data dictionary structures, M-to-SQL vendors need only scan the
7413   SQLI's projection to build their relational view of VA FileMan data.
7414
7415   Why Map VA FileMan to SQL?
7416   SQL (Structured Query Language) is the predominant language and set of facilities for working with relational tables.
7417   The reason to access VA FileMan data through SQL is to take advantage of features provided both by SQL and by
7418   Commercial Off-the-Shelf (COTS) software. For example, if a vendor's M-to-SQL product can act as an ODBC data
7419   source, this provides direct access to VA FileMan data for ODBC-enabled Windows software!
7420
7421   Some ways you can work with VA FileMan data using an M-to-SQL product include:
7422   • Query VA FileMan data through SQL.
7423   • Manipulate VA FileMan data in Open Database Connectivity (ODBC) aware applications. This is possible if the
7424      M-to-SQL product can act as an ODBC data source. In this case, VA FileMan data can be accessed and
7425      manipulated by ODBC-compatible applications (e.g., Access, Excel, ReportSmith, Crystal Reports, etc.).
7426   • Make VA FileMan data accessible over an Intranet or the Internet using an ODBC-aware Web server.



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-3
7427
7428   What Other Software is Required to View VA FileMan Data Through SQL?
7429   To enable SQL access to VA FileMan data at your site, you need to purchase an M-to-SQL product (software that
7430   can view structured M globals as relational tables through SQL).
7431
7432   Components of an M-to-SQL System Using SQLI
7433   Providing SQL access to your VA FileMan data requires using a number of software components, all working
7434   together. VistA's SQLI software product is one component of several needed for a complete system.
7435   Required Components
7436   1. SQLI: Part of VA FileMan. Projects VA FileMan's internal data dictionary information in a format tailored for use by
7437   M-to-SQL vendors.
7438   2. M-to-SQL Product. Must be purchased from a vendor. It should:
7439   • Provide SQL services
7440   • Be able to map its SQL data dictionaries so that SQL tables can reference data stored in M globals.
7441   3. SQLI Mapper. Provided by the vendor of the M-to-SQL product. This utility reads the information published by
7442   SQLI to map the M-to-SQL product's SQL data dictionaries to reference VA FileMan data.
7443   4. ODBC Drivers (optional). If the M-to-SQL software can act as an ODBC data source, the vendor can provide
7444   ODBC workstation drivers.
7445
7446   Mapping VA FileMan to SQL without SQLI
7447   Several commercial vendors have already implemented SQL interfaces to the VA FileMan database, by mapping
7448   directly to VA FileMan's internal data dictionary structures. Despite their success, you should consider using an M-to-
7449   SQL product that can construct its mapping to the supported relational view of VA FileMan data structures provided
7450   by SQLI.
7451
7452   Advantages of Mapping to VA FileMan through SQLI
7453   SQLI publishes all of the information M-to-SQL vendors need to access VA FileMan data through SQL. It places a
7454   layer between M-to-SQL vendors and VA FileMan's data dictionary, projecting the format for SQL access to VA
7455   FileMan files in a uniform manner. This approach results in a number of advantages, compared to vendors mapping
7456   directly against VA FileMan's internal data dictionary:
7457    SQLI projects VA FileMan files as tables and VA FileMan field types as SQL data types, functions, and
7458        domains.Insulates M-to-SQL vendors from directly accessing VA FileMan's data dictionary structures, which are
7459        subject to change.
7460    SQLI provides standard interpretations of data structures such as pointer fields, variable pointer fields, word-
7461        processing fields, multiples, and internal entry numbers. It also provides a standard treatment of primary
7462        keys.Enables standard approaches to writing queries across all VA sites.
7463    SQLI publishes standard SQLI identifiers for each VA FileMan file and field.Enables one site's SQL queries to
7464        work across all VA sites.
7465    SQLI provides a standard layer in VA FileMan for SQL access features.The presence of SQLI lays the
7466        groundwork for deeper integration of SQL access with VA FileMan.
7467    SQLI provides code for many of the data retrieval tasks inherent in accessing VA FileMan data through
7468        SQL.Should save vendor work, and encourage uniform approaches to retrieving VA FileMan data among
7469        vendors.
7470



       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap              Page 3-3
7471   Developer Notes
7472   As a developer, you may want to work with VA FileMan data relationally, using embedded SQL commands. You
7473   might then wonder if SQLI and its APIs would help you in doing this.
7474
7475   SQLI does not itself provide an API for directly accessing VA FileMan data. Nor is it able to provide access to VA
7476   FileMan data relationally on its own. Instead, it provides a framework for M-to-SQL vendors to access VA FileMan's
7477   internal data dictionary information. M-to-SQL vendors are then able to provide relational access to VA FileMan data.
7478
7479   As a developer, to work with VA FileMan data relationally your application should make use of services provided by
7480   COTS M-to-SQL software. Your application can then use SQL statements to access VA FileMan data, either directly
7481   or in conjunction with ODBC-aware client applications. Using services provided by the COTS M-to-SQL product (and,
7482   optionally, ODBC-aware client software), your application can:
7483   • Run SQL queries on VA FileMan data
7484   • Implement business rules using SQL stored procedures
7485   • Create and use database views
7486   • Optionally incorporate business rules (as SQL stored procedures) in database views




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-3
7487
7488                                                      Figure: 3.3-32
7489
7490   3.3.31 Standard Files and Tables
7491   Documentation available in vdl does not provide information regarding this application and/or its features (nor does
7492   the Monograph) but only two patches for the KERNEL application:
7493
7494   KERNEL Patch XU*8*105 (31 Mar 1999) is designed to identify and correct two data problems associated with the
7495   following files:
7496   1. Patient (File #2)
7497   2. Fee Basis Vendor (File #161.2)
7498   3. Person (File #16)
7499   4. HBHC Patient (File #631)



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
7500
7501   The two problems being addressed and corrected with this patch are
7502   described below:
7503   1. Dangling pointers associated with the County Fields in the
7504   aforementioned files are identified and cleaned up. (set to null)
7505   2. State and County entries that are currently null are identified
7506   and listed as exceptions. The exceptions are listed in the temporary
7507   global ^XTMP("XUXTMP") This is a new temporary global created by the
7508   patch. These exceptions are identified to provide a list of current state
7509   and county entry errors at each site. They will need to be addressed on a
7510   site-to-site basis.
7511
7512   KERNEL Patch XU*999*3 (2 Sep 1998) is an informational patch providing instructions for synchronizing the VISTA
7513   STATE file (#5) and the AAC edit table. These recommended modifications will standardize State and County entries
7514   across all Veterans Affairs Medical Centers and with the Austin Automation Center.




7515
7516                                                        Figure: 3.3-33
7517
7518   3.3.32 SAGG-Statistical Analysis of Global Growth
7519   Statistical Analysis of Global Growth (SAGG) Version 2.0 (Patch KMPS*2*0)
7520
7521   The Veterans Health Administration (VHA) developed the Statistical Analysis of Global Growth (SAGG) software in
7522   order to obtain more accurate information regarding the current and future VistA database growth rates at the VA
7523   Medical Centers (VAMCs).
7524
7525   SAGG is a fully automated support tool developed by the Capacity Planning (CP) team, which entails the monthly
7526   capture of global database, software, and file size information from participating sites.
7527
7528   Installing the SAGG software creates the collection process mechanism and other necessary components of the
7529   software. The fully automated data collection cycle entails capturing all production global, software, and file specifics
7530   at the site into a temporary ^XTMP("KMPS") collection global. Once collected, the information is converted into an
7531   electronic mail message that is automatically transferred via network mail and merged into a CP National Database.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-3
7532   The temporary collection global is then deleted from the site's system. The site also receives a summary of the global
7533   statistical data in the form of an electronic turn-around message.
7534
7535   After the initial setup procedures are performed as detailed in the patch description for KMPS*2*0, the collection
7536   process basically operates transparent to IRM with minimal impact on system resources. The software uses the
7537   Kernel supplied TaskMan utility to schedule the initial global collection cycle, and it is then rescheduled to capture on
7538   a regular monthly basis.
7539
7540   All options in the SAGG V. 2.0 software under the SAGG Project Manager Menu [KMPS SAGG MANAGER] can
7541   function independently. Only the Schedule/ Unschedule Options option [XUTM SCHEDULE] under the TaskMan
7542   Management menu can invoke the SAGG Master Background Task option [KMPS SAGG REPORT].




7543
7544                                                        Figure: 3.3-34
7545
7546   3.3.33 Survey Generator
7547   The Survey Generator is a software package which allows creation and maintenance of computerized survey forms.
7548   It also provides for entry of any respondents answers via computer terminal or a hard copy filled out and then entered
7549   by any designated person. In addition, it provides useful statistical information by survey alone or by demographic
7550   data items.
7551   This package is designed with both the survey author and the respondent in mind. It is simple to use and
7552   straightforward in operation and does not require any exceptional skills on the user's part.
7553
7554   Functional description
7555   Creating a survey:
7556   The survey author designs a survey, complete with layout and questions for it. The survey is then entered via any
7557   terminal using the supplied menu items ' then printed in a draft f orm and reviewed for accuracy. If the survey is as
7558   the author desires, it then can be released to users who may participate via any terminal. The survey also may be
7559   printed in a final hard copy form for distribution to persons who do not have ready computer access.
7560
7561   In addition, there are other menu options which allows the survey author to manipulate, maintain, copy or report on
7562   surveys.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-3
7563
7564   Editing and Maintenance of a survey:
7565   The author of the survey may use the supplied menu options or sub-options to create, edit, or maintain any part of a
7566   survey. There are, however, certain constraints to maintenance. Several maintenance items may only be used
7567   provided the survey has not yet been responded to. This includes things like adding or deleting questions and
7568   demographic items. other maintenance items like copying, printing, complete survey deletions and counting the
7569   number of current participants may be done at any time. Persons who hold the QAP MANAGER key or who are
7570   designated by the creator as authorized editors, may act on behalf of the creator for any maintenance items.
7571
7572   Survey Participation:
7573   A person who wishes to respond to a survey may use the option 'Participate in a Survey' to enter his/her answers via
7574   any computer terminal. Users who do not have
7575   access to a computer terminal may fill out a hard copy of the survey and return it to the proper person for manual
7576   input. Users who have only partially completed a survey may suspend the survey and resume at a later date.
7577   It should be noted that survey creation and participation is entirely voluntary on the part of the authors and
7578   participants.
7579
7580   Other items:
7581   There are no electronic signatures or other similar items for this package. This package requires no periodic purging
7582   or regular maintenance from the IRM Service.
7583
7584   The Survey Generator Package consists only of two main menus and two sub-menus.
7585
7586   Survey Generator Manager Menu
7587   1 Create/Edit a Survey
7588   2 Copy a Survey
7589   3 Print a Survey
7590   4 Release/Disable a Survey for Participation
7591   5 Count Survey Participants
7592   6 Delete a Survey, Questions and Responses
7593   7 Clear a Survey of Responses
7594   8 Generate Survey Statistics
7595   9 Print Statistics by a Demographic Data Item
7596   10 Print all Survey Responses Individually
7597   11 Export a Survey
7598   12 Import a Survey
7599   13 Populate the Demographic Reference File
7600   14 Fix a Survey Response
7601
7602   Survey participant Menu
7603   1 Participate in a Survey
7604   2 Edit an Incomplete Survey Response
7605   3 Print Statistics by a Demographic Data Item
7606   4 Generate Survey Statistics



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-3
7607   5 User Hardcopy Print of Survey




7608
7609                                                       Figure: 3.3-35
7610
7611   3.3.34 STK-System Toolkit
7612   There are no documents for this application at this point. (As of: October 30, 2009)




7613
7614                                                       Figure: 3.3-36
7615
7616




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap   Page 3-3
7617   3.3.35 VDEF-VistA Data Extraction Framework
7618   VistA Data Extraction Framework (VDEF) is a VistA package that uses hard-coded MUMPS (M) routines to create
7619   and deliver Health Level 7 (HL7) messages. The VDEF package supports queuing requests for messages, control of
7620   the timing of message creation, monitoring of the request queue, and recording of errors encountered during
7621   message creation. The hard-coded programs are M programs belonging to an application’s namespace.
7622
7623   Messages are delivered using the VistA HL7 package.
7624
7625   The VDEF package is installed as a regular Kernel Installation and Distribution System (KIDS) build.




7626
7627                                                      Figure: 3.3-37
7628
7629   3.3.36 VistALink
7630   VistALink enables HealtheVet applications to communicate with VistA/M systems. The VistALink resource adapter is
7631   a transport layer that provides communication between HealtheVet-VistA Java applications and VistA/M servers, in
7632   both client-server and n-tier environments. It is a runtime and development tool that allows java applications to
7633   execute remote procedure calls (RPCs) on the VistA/M system and retrieve results, synchronously. VistALink is also
7634   referred to as VistALink J2M.
7635
7636   VistALink consists of Java-side adapter libraries and an M-side listener:
7637    The adapter libraries use the J2EE Connector Architecture (J2CA) 1.5 specification to integrate Java
7638       applications with legacy systems.
7639    The M listener process receives and processes requests from client applications.
7640    Java applications can call Remote Procedure Calls (RPCs) on the M server, executing RPC Broker RPCs on the
7641       M server without modification.
7642
7643   All components of VistALink 1.6 are compatible with WebLogic 9 and higher, up to and including WebLogic 11g.
7644



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap          Page 3-3
7645   VistALink 1.6 has been tested and is supported on Oracle WebLogic Server 9.x and 10.x, only.
7646
7647   Reasons for VistALink:
7648    Alternatives for communication between Java and M applications exist, but at the time of release of VistALink (v1
7649      .0 and v1 .5), the needs of HealtheVet applications had not been met by these alternatives. Each of these
7650      alternatives is described below:
7651    Remote Procedure Call (RPC) Broker—The RPC Broker is COM-based, rather than Java-based. Using a Java
7652      wrapper around the COM-based Broker was proven by the Care Management team to have unacceptable
7653      performance limitations.
7654    Vitria BusinessWare software—Vitria BusinessWare software is used as an HL7 interface engine by the VA for
7655      asynchronous server-to-server messaging.
7656    However, there are many situations where applications need to access functionality on another server
7657      synchronously, almost always while an end-user is interacting with the HealtheVet application and waiting for the
7658      next page to be composed and displayed.
7659    Caché—Caché provides some connectivity mechanisms between itself and Java applications. However, these
7660      features did not meet the architectural requirements for HealtheVet applications.
7661    Third-Party J2EE Connector-Compliant Adapters—At least one company marketed an adapter for J2EE-M
7662      connectivity that is J2EE Connector compliant (as is VistALink). This adapter, however, was for a version of M
7663      (Digital Standard Mum ps/DSM) no longer used by VA.
7664    Web Services—At the time of design and subsequent release of VistALink v1 .5, Web services functionality was
7665      not yet standardized in J2EE. It is well-noted, however, that post-VistALink-v1.5, this has changed, and that
7666      current versions of Caché provide Web services support as well.
7667
7668   Features
7669    Client/Server connectivity from Java client to M—Supports Java rich client applications connecting to M servers
7670       and executing RPCs on those servers. This provides the equivalent of RPC Broker functionality for Java
7671       applications.
7672    J2EE Application Server connectivity to M—Supports applications and services running on a J2EE application
7673       server, enabling them to initiate a call to an M server and execute RPCs. Implements the Java 2 Enterprise
7674       Edition (J2EE) Connectors specification. HealtheVet applications using this functionality include Patient
7675       Advocate Tracking System (PATS), Veterans Personal Finance System (VPFS) and Blind Rehabilitation.
7676




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
7677
7678                                                        Figure: 3.3-38
7679
7680   3.3.37 XML Parser (VistA)
7681   The VistA Extensible Markup Language (XML) Parser is a full-featured, validating XML parser written in the M
7682   programming language and designed to interface with the VistA suite of M-based applications. It is not a standalone
7683   product. Rather, it acts as a server application that can provide XML parsing capabilities to any client application that
7684   subscribes to the application programmer interface (API) specification detailed in this document.
7685
7686   The VistA XML Parser employs two very different API implementations. The first is an event-driven interface that is
7687   modeled after the widely used Simple API for XML (SAX) interface specification. In this implementation, a client
7688   application provides a special handler for each parsing event of interest. When the client invokes the parser, it
7689   conveys not only the document to be parsed, but also the entry points for each of its event handlers. As the parser
7690   progresses through the document, it invokes the client’s handlers for each parsing event for which a handler has
7691   been registered.
7692
7693   The second API implementation is based on the World Wide Web Consortium (W3C’s) Document Object Model
7694   (DOM) specification. This API, which is actually built on top of the event-driven interface, first constructs an in-
7695   memory model of the fully parsed document. It then provides methods to navigate through and extract information
7696   from the parsed document.
7697
7698   The choice of which API to employ is in part dependent on the needs of the application developer. The event-driven
7699   interface requires the client application to process the document in a strictly top-down manner. In contrast, the in-
7700   memory model provides the ability to move freely throughout the document and has the added advantage of ensuring
7701   that the document is well formed and valid before any information is returned to the client application.
7702




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap               Page 3-3
7703   The VistA XML Parser employs an Entity Catalog to allow storage of external entities such as document type
7704   definitions. The Entity Catalog is a VA FileMan-compatible database and can be manipulated using the usual VA
7705   FileMan tools.
7706
7707   The parser uses the Kernel function FTG^%ZISH for file access.




7708
7709                                                    Figure: 3.3-39
7710
7711
7712
7713




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap      Page 3-3
7714   3.4 HealtheVet
7715   The subsystem is also known as VistA 1.5. My HealtheVet (MHV) is a Web-based application that creates
7716   a new, online environment where Veterans, family, and clinicians may come together to optimize
7717   veterans’ health care. This Web technology combines essential health record information enhanced by
7718   online health resources to enable and encourage patient/clinician collaboration. It is the first Web-based
7719   application created by the Office of Information for the exclusive use by veterans. MHV provides a one-
7720   stop shop for information on VA benefits, special programs, and health information and health services.
7721   MHV also provides services and tools that enable veterans to keep record of their health status and
7722   communicate more effectively and on a more consistent basis with their care providers, as well as
7723   become better-informed participants in improving their health. Veterans can now partner with their
7724   clinicians to gain a better understanding of their health status and to take a more active role in self-
7725   management and in shared health care decision-making.
7726
7727   Features
7728       Enables all veterans to participate voluntarily and have access to and contr ol of his/her
7729          customizable online environment.
7730       Provides a commercial Health Education Library that contains information on medical conditions,
7731          medications, health news, and preventive health.
7732       Makes the library available to clinicians; addressable from the CPRS toolbar and included in
7733          order sets.
7734       Showcases education and program information developed by VHA program offices.
7735       Contains the latest VA/VHA news.
7736       Contains a prescription checker, health calculators, and self-assessment tools.
7737       Maps to benefits and resources available in VA and other federal sources.
7738       Provides online prescription refills for veterans enrolled in VA health care.
7739       Provides ability to view next appointment date and time at a VA health care facility.
7740       Provides ability to see total co-payment balance.
7741       Allows patient to enter and store personal information in a secure eVAult.
7742       Provides ability to format and print reports, such as information cards and medication profiles.
7743       Enables veterans to journal readings and chart progress in five self-entered metrics (e-logs)—
7744          blood pressure, blood sugar, cholesterol, weight, and heart rate.
7745       Enables veterans to utilize additional e-logs, journal readings, and chart progress.
7746       Allows veterans to request and store key portions of their VA health record in a secure, unique, and
7747          personal repository.
7748       Enables veterans to let a delegate access and manage all or some of their health information,
7749          including, family, veteran advocates, and VA and non-VA providers.
7750       Allows veterans to receive wellness reminders, written specifically for the patient, to provide
7751          effective delivery of preventive medicine served through standardized reminders.
7752



       www.oserha.org                                OSEHR System-Architecture, Product Definition and Roadmap      Page 3-3
7753   HealtheVet Desktop is an application framework that will host the new generation of Veterans Health Administration
7754   (VHA) clinical applications. Care Management is the first application to run on the new HealtheVet Desktop, and is an
7755   enhancement of CPRS designed to assist health care providers to follow-up on clinical interventions that might
7756   otherwise be missed. Care Management provides an automated method for tracking follow-up actions/tasks for a
7757   panel of patients for a designated period of time. The four perspectives of Care Management are the Clinician
7758   Dashboard, the Nursing Dashboard, the Query Tool, and the Sign List. Implementation of the Care Management
7759   project will improve patient care by:
7760
7761   •   Ensuring that appropriate clinical interventions are provided on a timely basis;
7762   •   Ensuring that clinical notifications are processed on a timely basis;
7763   •   Reducing the amount of time primary care providers spend reviewing individual patient records; and,
7764   •   Reducing the risk of erroneous data entry.
7765
7766   HealtheVet-VistA (Future)
7767   A strategy has been developed to move the Veterans Health Information Systems toward “HealtheVet,” an ideal
7768   health information system to support the ideal veterans health system. Collaboratively among the Department, field,
7769   and central office leadership and the Chief Information Officer, a proposed strategy has been developed for both VA
7770   and Veterans Health Administration needs. The strategy is built around five major systems and integrates five cross-
7771   cutting issues:
7772
7773   •    The Health Data System Health Data Repository (HDR) will create a true longitudinal health care record,
7774        including data from VA and non-VA sources. The Health Data System will support research and population
7775        analyses, facilitate patient access to data and sharing of information across VHA, and improve data quality and
7776        data security. The Health Data System will also emphasize “eHealth,” to include prescription refills,
7777        appointments, fillable forms online, and My HealtheVet (access to health record, on-line health assessment
7778        tools, and high-quality health information).
7779   •    Provider Systems support health care providers' care for veterans and feed information to VistA today and the
7780        HDR in the future. These include CPRS, VistA Imaging, Blood Bank, Pharmacy, Laboratory, and Federal Health
7781        Information Exchange (FHIE).
7782   •    Management/Financial Systems include four applications that are each ten or more years old, and will be
7783        replaced: the Financial Management System, Billing and Accounts Receivable (AR), and Fee Basis (paying
7784        providers).
7785   •    Registration, Enrollment, and Eligibility Systems will be developed as a single, department-wide data system and
7786        demographic database that supports registration and eligibility for the three Administrations, and makes this
7787        information more accessible and consistent.
7788   •    Common Services develops and maintains the underlying software infrastructure that supports both legacy and
7789        current veteran health-related applications. Though largely transparent to end users, Common Services provides
7790        essential infrastructure elements such as identity management, security, message routing, transformation, and
7791        data transport for clinical and administrative applications. Core common services are addressed through four
7792        programs: Identity Management, Security Services, Messaging and Interface Services, and Other Common
7793        Services.




       www.oserha.org                                     OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
7794
7795                                                        Figure: 3.4-1
7796
7797   3.4.1 CISS-Clinical Information Support System
7798   There are no documents for this application at this point.
7799   (As of: October 30, 2009)
7800




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap   Page 3-3
7801
7802                                                         Figure: 3.4-2
7803   3.4.2 ESig-Electronic Signature
7804   As HealtheVet-VistA developers migrate VistA applications to modern technologies, interim solutions may be
7805   required until enterprise solutions are mature and stable. The Electronic Signature (ESig) service provides an interim
7806   solution for the use of electronic codes in place of wet signatures while HealtheVet-VistA’s security infrastructure and
7807   architecture are being defined. The service duplicates for Java applications (J2EE or J2SE) the Kernel 8.0 electronic
7808   signature functionality currently used by VistA/M applications.
7809
7810   ESig furnishes a standard, consistent set of APIs that HealtheVet -VistA developers can implement to provide users
7811   access to electronic signature data stored on VistA/M systems. ESig APIs make calls from Java applications to
7812   VistA/M systems to retrieve, validate, and store electronic signature codes and signature block information (name,
7813   title, office phone, etc.). Additional Java APIs provide encoding/decoding, hash, and checksum calculation utilities,
7814   but do not interact with the VistA/M system.
7815
7816   Applications that implement the ESig service must provide a user interface (UI) to prompt users for their secret codes
7817   when authorizing orders, prescriptions, financial transactions, or other business processes. Users may also need the
7818   UI to create or modify their code or signature block data.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap              Page 3-3
7819
7820                                                     Figure: 3.4-3
7821
7822   3.4.3 HWSC-HealtheVet Web Services Client
7823   As VistA is migrated to the new HealtheVet-VistA system, some legacy VistA applications will need synchronous
7824   access to HealtheVet application services and data. HWSC uses Caché’s Web Services Client to invoke web service
7825   methods on external servers and retrieve results. It provides helper methods and classes to improve the use of the
7826   Web Service Client in a HealtheVet-VistA environment.
7827
7828   Features
7829   HWSC acts as an adjunct to the web services client functionality provided in Caché, by:
7830   • Leveraging Caché's platform-provided Web services client capabilities.
7831   • Adding a file and UI to manage the set of external web server endpoints (IP, port, etc.)
7832   • Adding a file and UI to register and manage the set of external web services.
7833   • Providing runtime API to invoke a specific web service on a specific web server.
7834   • Providing a runtime API to facilitate error processing in a VistA environment.
7835   • Providing a deployment API to install/register a web service proxy from a WSDL file.
7836   • Providing a management UI including the ability to 'ping' (test) a given web service/server combination from
7837       VistA/M.
7838   • Supporting both SOAP- and REST-style web services
7839   • Fostering consistent implementation of VistA/M web service consumers




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap           Page 3-3
7840
7841                     Figure: 3.4-4
7842
7843




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-3
7844   3.4.4 My HealtheVet
7845   The My HealtheVet VistA package supports the internet prescription refill functionality of the MHV website. It
7846   includes HL7 interfaces supporting queries for prescription information, and orders for refills.
7847
7848   My HealtheVet prescription refill functionality allows patients to request refills of their prescriptions online, resulting in
7849   fewer refill requests made via mail and telephone. My HealtheVet also allows veterans to get information on their
7850   current prescriptions, and their historical prescriptions. Online access to this information results in fewer calls to the
7851   pharmacy and Release of Information office.
7852
7853   My HealtheVet (MHV) is an online environment where veterans, family members and clinicians may come together to
7854   optimize veterans’ healthcare. Web technology combines essential health record information with online health
7855   resources to enable and encourage veteran/clinician collaboration.
7856
7857   The My HealtheVet system consists of a national system housed at the Austin Automation Center (AAC), and the My
7858   HealtheVet VistA package. The national system is comprised of a website available to all veterans on the public
7859   internet (http://www.myhealth.va.gov), and its supporting database, application, and internet servers. More
7860   information on that system is available from the My HealtheVet Product Homepage at
7861   http://vaww1.va.gov/MyHealtheVet.
7862
7863   MHV should be journaled.




       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap                  Page 3-3
7864
7865                     Figure: 3.4-5
7866




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-3
7867   My HealtheVet - (Component diagram)
                  cmp My HealtheVet

                    Name:      My HealtheVet
                    Package:   My HealtheVet
                    Version:   1.0
                    Author:    Pat
                                                                         My HealtheVet


                                                                             «interface»
                                                                                MHV
                                                                                                   Austin Information
                                                                                                   Technology Center


7868
7869                                                         Figure: 3.4-6
7870
7871   3.4.5 NUMI-National Utilization Management Integration
7872   The National Utilization Management Integration (NUMI) application is a web-based solution that automates
7873   utilization review assessment and outcomes. The Utilization Management (UM) Process is a tool used to help ensure
7874   that patients are receiving the right care, at the right time, and in the right place. UM is both a quality and efficiency
7875   tool, as it is used to move patients efficiently through the VA system to maximize use of resources. UM reviewers
7876   assess patient admissions and hospital stay days using standardized objective evidence-based clinical criteria to
7877   determine whether patients meet criteria for acute hospital care.
7878
7879   The NUMI application standardizes UM review methodology and documentation at the facility level and creates a
7880   national VHA utilization information database. In NUMI, patient movement data is obtained from read-only VistA
7881   access to pre-populate a patient stay database, eliminating redundancy and errors from manually re-entering patient
7882   data. A Commercial Off-the-Shelf (COTS) product, McKesson Care Enhanced Review Management Enterprise
7883   (CERME), is integrated into NUMI to provide access to the InterQual® standardized clinical appropriateness criteria
7884   and algorithms. The CERME functionality is used to determine whether patient admissions and hospital days meet
7885   clinical appropriateness criteria for acute care hospital care. The national NUMI database is built in SQL and will
7886   enable facility, VISN, and national reporting of UM review outcomes.
7887
7888   The NUMI system provides critical functionality to help UM reviewers to organize UM review workload, document UM
7889   review outcomes, and generate reports to help identify system constraints and barriers to providing the appropriate
7890   services at the appropriate level of care. NUMI users can perform the following functions:
7891   • Pre-populate patient stay information from VistA into a NUMI SQL database which records patient stay
7892        information. UM review outcomes, reasons, and recommended levels of care are saved in the NUMI database
7893   • Generate a list of patient admissions and hospital days that need to be reviewed to assist UM reviewers in
7894        organizing their workload
7895   • For newly admitted patients, collect patient and treatment information to determine whether patients meet clinical
7896        criteria for inpatient admission
7897   • Following admission, collect treatment information for each hospital day to determine whether patients meet
7898        continued stay criteria
7899   • Standardize documentation of a) reasons for inpatient admissions or continued stays that do not meet clinical
7900        criteria for inpatient care, and b) recommended levels of care for admissions and continued stay days not
7901        meeting criteria



       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap                Page 3-3
7902   •   Provide Physician UM Advisors with an automated UM review list to access reviews, document agreement or
7903       disagreement with current levels of care, and add comments and recommendations regarding patients not
7904       meeting criteria
7905   •   Generate summary reports of UM outcomes to provide insight into system constraints and barriers and identify
7906       quality improvement opportunities
7907   •   Assign specific reason codes for reviews that do not meet criteria. The VA-specific reason code structure will
7908       enable UM staff to aggregate and analyze the most prevalent reasons why patients are not meeting criteria at
7909       their current level of care. This information provides insight to help identify quality and access improvement
7910       opportunities.
7911   •   Display a list of patient stays and review information, with filters and search features to assist in organizing
7912       individual reviewer workloads
7913
7914   NUMI was developed to address the Utilization Management data needs of the VHA and to provide the UM staff with
7915   a web-based solution for capturing patient information in compliance with VHA Directive 2005-040 (Utilization
7916   Management Policy).




7917
7918                                                      Figure: 3.4-7
7919
7920




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
7921   3.4.6 OHRS-Occupational Health Record-keeping System
7922   The Occupational Health Record-keeping System (OHRS), is a web-based application that enables occupational
7923   health staff to create, maintain, and monitor medical records for VA employees and generate national, Veterans
7924   Integrated Service Network (VISN), and site-specific reports.
7925
7926   The OHRS help topics provide detailed information to assist Clinical Information Support System (CISS) site staff
7927   members and other users to successfully use CISS and OHRS.




7928
7929                                                     Figure: 3.4-8
7930
7931




       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap          Page 3-3
7932   3.4.7 PATS-Patient Advocate Tracking System
7933   The Patient Advocate Tracking System (PATS) is a web-based application with a centralized database and
7934   notification function (email) for tracking patient-related issues. PATS is designed to work on various operating
7935   systems (e.g., Windows 2000, Windows XP, Linux).
7936
7937   PATS enables users to perform the following tasks:
7938    Add a Report of Contact (ROC) which details a Veteran’s issue (compliment or complaint).
7939    Edit, close, reopen, and delete an ROC.
7940    Send Informational Notifications to communicate an issue to an employee involved in a Report of Contact and/or
7941      the employee’s supervisor.
7942    Send Action Request Notifications, which require a response from the individual regarding action to be taken or
7943      next steps.
7944    Generate site-specific and National reports.
7945    Create ad hoc reports.
7946    Display reports online and save them in a variety of formats (i.e., Word, Excel, PDF files).
7947
7948   PATS automatically rolls up data to the VISN Support Service Center (VSSC) to provide additional National reports.
7949
7950   National Program Office and Patient Advocates can add and change (update, activate, and inactivate) PATS table-
7951   reference data (e.g., Hospital Location).
7952   PATS includes online help pages that you can access from the menu or directly from each page within the
7953   application.




7954
7955                                                      Figure: 3.4-9
7956
7957



       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap          Page 3-3
7958   PATS-Patient Advocate Tracking System - (Component diagram)
        cmp PATS-Patient Adv ocate Tracking System

          Name:       PATS-Patient Advocate Tracking System
          Package:    PATS-Patient Advocate Tracking System
          Version:    1.0
          Author:     Pat




                               PATS-Patient
                             Adv ocate Tracking
                                   System


                                     «interface»                Austin VISN Support Service Center - VSSC
                                        PATS




7959
7960                                                 Figure: 3.4-10
7961
7962




       www.oserha.org                                OSEHR System-Architecture, Product Definition and Roadmap   Page 3-3
7963   3.4.8 Person Services
7964   Enhancements (Release Notes):
7965   North Chicago Enhancement
7966   • Add new "Attended Search threshold" value to support the returning a larger range of selectable candidates
7967        (needed to support when SSN is not provided or unavailable)
7968
7969   VRM IAM IPT
7970   • Add DoD Correlation based on VA LOB Business
7971
7972   IdM User -HcIdM (WorkStream)
7973   • General Usability enhancements
7974   • Manage Potential Duplicate enhancement
7975   • Exception search enhancement
7976   • TK display support for NHIN larger Identifiers
7977   • TK support for PIV card login authentication
7978
7979   IdM Service (WorkStream)
7980   • Establish DoD Query WebService Interface
7981   • Establish DoD Update Patient WebService Interface
7982   • Establish DoD Add Person WebService Interface
7983   • Establish GetProfile WebService
7984   • Create Admin tools to manually monitor and trigger WebServices
7985   • 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-3
7986
7987                                                        Figure: 3.4-11
7988
7989   3.4.9 Registries
7990   There are no documents for this application at this point.
7991   (As of: October 30, 2009)
7992
7993   The Registries Program supports the population-specific data needs of the enterprise.




       www.oserha.org                                      OSEHR System-Architecture, Product Definition and Roadmap   Page 3-3
7994
7995                                                       Figure: 3.4-12
7996
7997   3.4.10 SCIDO-Spinal Cord Injury and Disorders Outcomes
7998   The Spinal Cord Injury and Disorders Outcomes (SCIDO) application is a system for compiling spinal cord injury and
7999   disorders information. The SCIDO application accesses several other VistA programs that contain information
8000   regarding diagnoses, prescriptions, surgical procedures, laboratory tests, radiological exams, patient demographics,
8001   hospital admissions, and clinical visits. This access allows clinical staff to take advantage of the data supported by
8002   VistA. Information can be summarized at three levels: local medical center, SCI&D region, or national research
8003   access.
8004
8005   Overview and Features
8006   The SCIDO application has been organized using World Health Organization concepts. After a cover sheet
8007   summarizing the patient’s status and a registration sheet, tabs address impairments, medical complications,
8008   activities, and participation. The reports tab and administration tab follow these health domain tabs.
8009
8010   Subject Tabs
8011   The footer of each page contains seven tabs representing the pages of the application. Moving from one page to
8012   another is possible by simply selecting the tabs located at the bottom of each page. For example, if the user is on the
8013   Activities tab and wants to open the Impairments tab, the user selects the Impairments tab in the footer. The SCIDO
8014   application can be navigated through the following tabs:
8015
8016   Cover Sheet – displays a summary of the patient’s status. It displays recent diagnoses and CPT codes from the past
8017   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-3
8018   application. If the information has not been entered, these fields will be blank. The patient record opens to the Cover
8019   Sheet unless the Veteran has not been registered in the SCIDO application.
8020
8021   Registration Tab – used to register Veterans into the SCIDO application and to enter data, which allows staff access
8022   to valuable regional and local program data. This information is designed to simplify your job. Investing a small
8023   amount of time entering registration and other useful information will return valuable dividends when the information
8024   is needed in reports or displayed.
8025
8026   Impairments Tab – Impairments refer to any loss of psychological, physiological, or anatomical structure or function.
8027   Impairments affect organ systems, thought, or emotion. Information about impairments is provided on both the
8028   Impairments Tab and the Medical Complications Tab.
8029
8030   Medical Complications Tab – Medical Complications are impairments that are commonly associated with spinal cord
8031   injury; therefore, this tab focuses on respiratory complications, urinary tract infections, influenza, pressure ulcers, and
8032   pain. These secondary complications are common, costly, and can be disruptive to activities, participation, and
8033   satisfaction with life.
8034
8035   Activities Tab – activities are tasks and actions by an individual at the level of a person rather than the anatomic,
8036   physiological, or social levels. Activities have been associated traditionally with abilities, disabilities, or independence.
8037   This tab summarizes common activity limitation measures such as the FIM, FAM, and Kurtzke EDSS and FSS
8038   measures, which are used specifically for multiple sclerosis.
8039
8040   Participation & SWLS Tab – participation reflects the nature and extent of a person’s involvement in life situations at
8041   a social or societal level and often pertains to participating in meaningful social roles. This tab summarizes
8042   participation information based on the CHART-SF and also includes Diener’s Satisfaction with Life Scale (SWLS).
8043
8044   Reports Tab – reports reflect the benefits of accurately maintaining the SCIDO application for the Veterans you
8045   serve. Templated reports regarding impairments and medical complications, aggregate outcome reports, and patient
8046   listings are available for ready review. Filtered reports allow the selection of specific portions of the population for
8047   review before the reports are generated. For unique reports that affect your practice, you can learn how to use the
8048   Report Designer to generate custom reports for the population.
8049
8050   Administration Tab – provides the functionality to display user names and roles; SCI Regional definitions; activate or
8051   inactivate a patient status; activate or inactivate patient assessments; activate or inactivate Episodes of Care; import
8052   patient records from the national database; and add or delete SCI and Multiple Sclerosis (MS) mail groups.
8053
8054   Information Resource Management (IRM) tab – allows a person within the IRM/ISS/ITS user role to add or delete
8055   medical centers from SCI&D regions, modify regional attributes, perform a national or regional audit, and monitor
8056   system activity.




       www.oserha.org                                        OSEHR System-Architecture, Product Definition and Roadmap                 Page 3-3
8057
8058                                                       Figure: 3.4-13
8059   3.4.11 VES-VA Enrollment System
8060   Enrollment System Redesign (ESR) V3.4 (a.k.a. HECMS) is the HealtheVet replacement system for the
8061   decommissioned product known as HEC (Health Eligibility Center, Atlanta) Legacy. It is both a re-host of HEC
8062   Legacy and in some instances (use cases/features), a re-engineering. HECMS allows staff at the HEC to work more
8063   efficiently and determine patient eligibility in a more timely manner. Messaging with the VAMC (Department of
8064   Veterans Affairs Medical Center) allows updates to the enterprise enrollment system to be shared with the field.
8065
8066   It is one component of the "system of systems" needed to implement the HealtheVet REE (Registration, Eligibility
8067   and Enrollment) environment.
8068   Its two main functions are:
8069   1. Expert System
8070    Based on information obtained from sites, VBA (Veterans Benefit Administration) and HEC staff determine and
8071         communicate verified medical benefits eligibility and enrollment (E&E) information for all Veterans and
8072         beneficiaries.
8073   2. Work Flow (Case Management)



       www.oserha.org                                  OSEHR System-Architecture, Product Definition and Roadmap          Page 3-3
8074      For every exception where the expert system process cannot make a determination, "cases" are created for
8075       human intervention.
8076
8077   HEC staff utilizes HECMS to manage these "cases" to completion so that verified E&E can be determined.
8078   ________________________________________
8079
8080   To satisfy the Program Management Accountability System (PMAS) initiative to provide more frequent software
8081   releases with reduced functionality, ESR V3.1 was released separate from the Veterans Online Application (VOA)
8082   package, which will be released at a later date. The unpopulated VOA fields are identified by adding “VOA” in
8083   parenthesis next to the respective field names in this manual. These placeholder fields will not be populated until
8084   VOA is released.
8085
8086   ESR V3.2 added the General Counsel’s (GC) Ruling on changes to the Geographic Means Test Threshold (GMTT).
8087   The GC ruling dictates that people with very low income who live where the GMTT is less than the Means Test
8088   Threshold (MTT) and whose net income is less than the GMTT, yet their net income plus assets is greater than the
8089   Net Worth Threshold, be placed in Priority Group (PG) 7.
8090
8091   ESR V3.3 added the Eligibility and Enrollment (E&E) Web Service which supports requests for data or information
8092   regarding the enrollment or eligibility of Veterans on an as-needed basis. An Enrollment Web Service brokers
8093   requests from other systems to ESR, carrying out the system specific information request.
8094
8095   VBA Pension Data Sharing expanded on the pension information gathered by ESR. Additional Pension Award fields
8096   related to VA Pension were added to the Edit Current Eligibility screen. Also included as part of the VBA Pension
8097   Data Sharing enhancement were two Class II Dental fields added to the Current Military Service screen.
8098
8099   Priority Group Relaxation % Phase II expanded upon the P8 Relaxation Enhancement, which allowed Veterans to be
8100   enrolled based on a fixed percentage allowance above the Means Test or Geographical Means Test Thresholds, by
8101   providing the ability to change the Relaxation Percentage by income year. The change was retroactive back to the
8102   beginning of the current Income Year for any Veterans who were rejected at that time, but would now qualify under
8103   the new relaxation percentage.
8104
8105   ESR V3.4 adds the following additional Military Service Data Sharing (MSDS) capabilities.
8106    A manual query to the Beneficiary Identification Records Locator System (BIRLS) and VA/DoD Identity
8107      Repository (VADIR) via the MSDS Broker can be initiated from the Military Service page.
8108    The MSDS Query Status is displayed on the Current Eligibility page.
8109    The veteran’s record will be updated if the incoming data received data from BIRLS and VADIR is more
8110      favorable for the veteran.
8111    Medal of Honor Indicator data is now stored and displayed on the Military Service page.
8112    When new Military Service Episode (MSE) or Operation Enduring Freedom/Operation Iraqi Freedom (OEF/OIF)
8113      data is received from a site, an MSDS Broker query is triggered.
8114    HEC and Broker data is now used rather than site data to determine the Veteran Indicator, calculate the Combat
8115      Veteran End Date, and determine the veteran’s Period of Service.
8116    MSE data is shared with the sites (VistA).
8117


       www.oserha.org                                   OSEHR System-Architecture, Product Definition and Roadmap            Page 3-3
8118   The main areas and releases in which some enhancements were made are:
8119    Data Handling Process (3.1)
8120    Reporting (3.1)
8121    Standardizing Date Checks (3.1)
8122    Enrollment Processing (3.1)
8123    Message Processing Improvements (3.1)
8124    System Administration (3.1)
8125    Veterans Online Application (10-10EZ supplement) (3.1)
8126    Identity Traits (3.1)
8127    Financials/Adjudication (3.2)
8128    E&E Web Services Phase II (3.3)
8129    VBA Pension Data Sharing (3.3)
8130    Priority Group Relaxation % Phase II (3.3)
8131    Remove Unecessary Data Consistency Checks (3.3)
8132    Duplicate Merge Tool Enhancement (3.3)
8133    Military Service Data Sharing (MSDS), Phase I (Phase I will create HEC-owned MSE records based on site data
8134       from incoming ORUZ07 messages) (3.X)
8135    Patient Benefits Handbook Phase I (3.X)
8136    MSDS Phase II (3.4)
8137




8138
8139                                                   Figure: 3.4-14
8140
8141



       www.oserha.org                                 OSEHR System-Architecture, Product Definition and Roadmap        Page 3-3
8142   VES-VA Enrollment System - (Component diagram)
        cmp VES-VA Enrollment System

          Name:      VES-VA Enrollment System          «interface»
          Package:   VES-VA Enrollment System           Veterans
          Version:   Sep 2011                          Enrollment
          Author:    Pat                                 System
                                                                                 VA/DoD Information Repository (VADIR)




                                  VBA Beneficiary Indentity Record Locator System (BIRLS)
8143
8144                                                      Figure: 3.4-15
8145
8146   3.4.12 VPFS-Veterans Personal Finance System
8147   Veterans Personal Finance System (VPFS) is the mini-banking system used by the Veterans Health Administration
8148   (VHA) to manage the accounts of VHA patients in the VHA hospital system. VPFS replaces the Personal Funds of
8149   Patients (PFOP) system that was used previously. VPFS looks different from PFOP because it is a web-based
8150   application; however, its design and functionality are modeled after PFOP. You can perform all of the functions in
8151   VPFS that were available in PFOP, with the exception of a few functions that are no longer needed because of the
8152   new built-in security controls.
8153
8154   One of the major changes is that VPFS is a centralized system. With PFOP, each site used a stand-alone copy of the
8155   software and there were differences between local versions, such as data structures, business rules, etc. With VPFS,
8156   all sites access the same centralized application using a web browser over the VHA secure Intranet. VPFS stores all
8157   data for all sites in one centralized database. Access to the data in the database is controlled by security software
8158   that limits access according to your VistA site and user role.




       www.oserha.org                                    OSEHR System-Architecture, Product Definition and Roadmap             Page 3-3
8159
8160                    Figure: 3.4-16
8161




       www.oserha.org   OSEHR System-Architecture, Product Definition and Roadmap   Page 3-3

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:327
posted:12/4/2011
language:English
pages:368