OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
TO:
jake.lewis@tma.osd.mil, no later than 5:00 pm EST, on (Wed) 27-Feb-13.
FROM:
Seong K. Mun, PhD, President and CEO, OSEHRA, not-for-profit LLC
900 N. Gelbe Road, Arlington, VA, 571-858-3201, munsk@osehra.org
SUBJ:
Response to DOD MEDICS EHRS HT0012-RFI-0008
DATE:
27 February 2013 Final Version, where, this version is 24-Feb DRAFT-I
Contents
1. OVERVIEW / EXECUTIVE SUMMARY ................................................................................................................................... 2
2. PURPOSE OF THIS RFI RESPONSE .................................................................................................................................. 14
FULL DISCLOSURE / DISCLAIMER / ACKNOWLEDGEMENT ................................................................................................................... 14
ASSUMPTIONS ........................................................................................................................................................................... 14
WHY OPEN SOURCE? ................................................................................................................................................................. 15
WHY OSEHRA? ....................................................................................................................................................................... 15
WHY OPEN-SOURCE MEDICS EHRS/VISTA CORE? ....................................................................................................................... 15
INNOVATION AND A MEDICS EHRS/VISTA FUTURE STATE VISION .................................................................................................... 16
VistA - the core of a Cloud-based MEDICS EHRS ................................................................................................................... 16
MEDICS EHRS - from Piecemeal to the Cloud ........................................................................................................................ 16
VistA - evolving to a Cloud-based MEDICS EHRS ................................................................................................................... 16
DoD, VA and Partner Data - Just Publish and Link .................................................................................................................. 17
3. CAPABILITY STATEMENT SUBMISSION SCOPE ................................................................................................................ 21
3.1 GENERAL............................................................................................................................................................................. 22
3.2 EHRS SOLUTION .................................................................................................................................................................. 25
3.3 TEST OF OPEN-SOURCE SOFTWARE .......................................................................................................................................... 31
3.4 INTEGRATION ....................................................................................................................................................................... 32
3.5 TRANSITION ......................................................................................................................................................................... 34
3.6 NETWORK AND SECURITY ARCHITECTURE.................................................................................................................................. 36
3.7 ARCHITECTURE/SYSTEMS ENGINEERING (A/SE) ......................................................................................................................... 36
3.8 IDENTITY MANAGEMENT.......................................................................................................................................................... 37
3.9 DATA .................................................................................................................................................................................. 38
3.12 USER INTERFACE ................................................................................................................................................................ 42
3.13 WORKFLOW ....................................................................................................................................................................... 45
MEDICS EHRS RFI ATTACHMENT (1) – ANTICIPATED MEDICS EHRS/VISTA OBJECTIVES ...................................................... 46
1. GENERAL OBJECTIVES ............................................................................................................................................................. 46
2. CLINICAL OBJECTIVES .............................................................................................................................................................. 46
3. BUSINESS OBJECTIVES ............................................................................................................................................................ 47
4. PROGRAM MANAGEMENT OBJECTIVES ........................................................................................................................................ 47
5. TECHNICAL OBJECTIVES ........................................................................................................................................................... 47
OSEHRA/VISTA SYSTEM ARCHITECTURE ............................................................................................................................ 48
WORKING DRAFT
3/21/2016 6:25 PM, Page 1
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
Forward
The following diagram highlights the OSEHER’s current Open Source engagement with federal agencies, private
sector, and academia (ACAD) and proposed option for MEDICS EHRS.
As shown in the Figure, OSEHRA houses DOD Open AHLTA, Janus, as well as code contributed by the US Air
Force. Additional, OSEHRA houses the IHS (Indian Health Services) RPMS (Resource and Patient Management
System) and VA VistA code bases.
As a part of VA’s Open Source initiative, VA has announced that all current VistA software supported at the
national level will be certified by OSEHRA. Additionally, all VA Medical Centers (VAMCs) will use the certified
VistA software. A key component of VA’s Open Source Initiative is the VistA Standardization Project, which has
been chartered to ensure all instances of VistA national software use the OSEHRA certified version for each VistA
product at all VAMCs. This project is currently completing its pilot phase. Another Open Source Initiative is
expansion and enhancement of the VistA programming environment through addition of open source Application
Programming Interfaces.
VA Blue Button Continuity of Care Document (CCD) and then My HealtheVet (MHV) Open Source Platform, as
part of the customer facing aspect of the Open Source Initiative are being extended to accommodate open source
platforms and projects. The goal of this effort is to implement a new architecture leveraging open source as a
means of enabling HITSP/C32 functionality as a part of CCD (C32 is a type of CCD which focuses on the patient's
summary information.) By leveraging this technology the open source development is able to provide MHV a webservice and data store for the CCD document.
The Open Source Initiative also addresses the “outbound” processes to actively share and contribute products
and developments to OSEHRA for certification and distribution. Therefore, as VA software is being developed,
the developers, Project Managers (PM) will contribute their codes and artifacts to OSEHRA. A symmetric aspect
of the VA Open Source Initiative is adoption and incorporation of code and products from OSEHRA. Project
Managers, requirements analysts and software developers are encouraged to investigate existing certified code
and products in the OSEHRA repository for incorporation into future projects or to address agency business
needs requirements.
We envision that DOD MEDICS EHRS can be constructed from an OSEHRA certified open-source core, and
potentially additional capabilities, which are housed at OSEHRA and are available to all contractors, at no cost.
Seong Ki Mun, President and CEO
OSEHRA, 501(C)-6 not-for-profit corporation
WORKING DRAFT
3/21/2016 6:25 PM, Page 2
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
1. Overview / Executive Summary
The OSEHRA Open Source Community believes that an open-source Medical Electronic DoD Integrated Core
System (MEDICS) EHRS/VistA can deliver to the warfighter an electronic health record (EHR) with the most
capability in the shortest period of time for the least cost. Open-Source MEDICS EHRS/VistA will be an open,
modular EHRS SOA Platform using standards-based / non-proprietary interfaces, which can cost-effectively replace
DoD legacy electronic health records systems (e.g., Armed Forces Health Longitudinal Technology Application
(AHLTA), Composite Health Care System (CHCS), and Inpatient System Essentris®) with a Gartner Generation 4
EHRS for clinical and business applications. When fully implemented, the open-source MEDICS EHRS/VISTA can
provide a single “logical” authoritative source, within a federated EHRS deployment, of health information for DoD
beneficiaries; help improve the health of our population; improve patient safety and quality of care provided; help
control health care costs; and contribute to the medical readiness for our military. The proposed MEDICS
EHRS/VistA conceptual architecture and strategic vision is proven to be scalable and can support DoD’s direct care
population of more than 3 million beneficiaries, and 70,000 clinicians who practice in 56 hospitals, 364 medical
clinics, and 282 dental clinics1. The proposed MEDICS EHRS/VISTA architecture and strategy can maintain, and
support enhancements to, ongoing data exchange between DoD and the Department of Veterans Affairs (VA), and
all external partners.
The MEDICS EHRS/VistA core and iEHR ESB/SOA Suite platform together provide the common infrastructure,
clinical and business for a Best of Suite (BoS) application, which would be followed by the addition of Best of Breed
(BoB) applications until final operating capability is deployed. OSEHRA’s open-source MEDICS RFI response
provides analyses, alternatives, timelines, and recommendations as to this approach. For the purposes of this RFI,
the OSEHRA open-source MEDICS EHRS/VistA response supports and can greatly exceed the DoD defined
EHRS core as containing, at a minimum, the following components:
1) System Management: Includes support for security (while balancing the need for legitimate access),
identity management, disaster recovery, and business continuity
2) Interoperability: Ability to communicate and interact with other systems
3) Data Model: Permanent data store that guarantees that information is stored for the legally required time
and can be retrieved rapidly and flexibly
4) Clinical Workflow: Support for the processes involved in clinical care as well as the information needed
5) Clinical Documentation, Document Management, and Data Capture: Capture all clinically relevant
information at the point of care
6) Clinical Display / Dashboard (part of clinical applications): Present data in a meaningful manner that
contributes to the clinician’s ability to use the data effectively
7) Clinical Decision Support (CDS): Ability to incorporate rules and decisions
8) Order Management (including Computerized Physician Order Entry or CPOE): Support a variety of
mechanisms for entry and management of all types of clinician orders
Map and Gap
OSEHRA is providing the Government an assessment of its definition of the core in light of best practices and
variances identified by the open-source community.
1. The RFI cites: 282 dental clinics (P.1) and (P.2) but does not encompass a dental electronic health record
capability within the core or other elements of the high-level solution. This is a critical element for two reasons:
1
See VA response to DOD MEDICS EHRS RFI for details
WORKING DRAFT
3/21/2016 6:25 PM, Page 3
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
a. The DoD has the largest organized dental capability and mission in the Nation, and the MHS has yet to
provide an Acceptable, affordable or achievable solution to its dental community.
b. The largest and most “recognized” dental-specific record capability is summarized as: “Currently, there
are two modules available for dentistry that are certified by the Office of the National Coordinator for
Health Information Technology (ONC): the Indian Health Services’ Resource and Patient Management
System (RPMS) and Electronic Dental Record (which is a Dentrix product) and the Veterans
Administration’s VistA Dental Record Manager Plus. The VistA system is certified as a module, while
the IHS product is certified as a full EHR.”
Perhaps most critical, is the ROM description in the RFI document which reads as follows with emphasis applied:
iv. Deployment, with your timeline, for the following:
a) Development and Test Center environment for test prior to deployment
b) 13 academic medical centers with 144,692 admissions, 214,812 procedures (2012 data)
c) 43 community hospitals with 95,017 admissions, 119,875 procedures (2012 data)
The Question raised from the above is
Where Are the 364 medical clinics, and equally Where are the 282 Dental Clinics?
Conceptual Architecture
The recommended MEDICS EHRS/VistA is intended to be a Healthcare Services Platform emphasizing the reuse
of high quality clinical/business, infrastructure services, a User Experience (UX) framework, a Virtual Patient Record
(VPR) and virtual data repository (VDR). The recommended MEDICS EHRS/VistA is intended to be an
interoperability-framework for COTS (Commercial Off-The-Shelf), GOTS (Government Off-The-Shelf) and opensource components. All medical specialty domains, such as Joint Immunization Capability (JIC), should each be an
orchestration of EHRS Platform Services; where, each medical-specialty domain has its own data-and-terminology
models, business-rules, workflows, reports and displays in accordance with scope-of-practice, organizational
policy, governance and jurisdictional law.
We recommend the following two MEDICS EHRS/VistA specific 1) technical and 2) risk mitigation strategies:
1. We recommend that MEDICS EHRS/VistA establish the FOC foundation and the legacy transition strategy by
focusing on VDR legacy-system data integration using the HL7/OMG specified RLUS (Retrieve, Locate, and
Update Service) database front-end; and to insure interoperability, IOC must include a requirement to use the
underlying EHRS Platform HDD (Health Data Dictionary), to implement RLUS), Janus UX framework, VPR and
VDR. IOC should, ideally, use MEDICS EHRS/VistA clinical/business services, initially provided by legacysystem’ service-facades. If IOC includes a turn-key COTS or GOTS component, it must have exit ramps (e.g.,
service invocations) enabling the use of the HDD, UX framework, VPR and VDR. FOC (Final Operating
Capability) should exclusively use MEDICS EHRS/VistA platform services.
2. We recommend a three-phase risk mitigation strategy, where the EHRS integration contractor coordinates and
demonstrates the MEDICS EHRS/VistA core platform solution; first, in the Service Oriented Architecture (SOA)
Suite/ESB (Engineering Service Bus) sandbox; secondly, at the DOD integration and Test facility in Richmond
or Maui and finally at Dec 2014 IOC.
WORKING DRAFT
3/21/2016 6:25 PM, Page 4
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
Figure 1 Benefits of MEDICS EHRS/VistA including iEHR ESB / SOA Suite
TECHNICAL STRATEGY RECOMMENDATION #1, shown in Figure 1, emphasizes the MEDICS EHRS/VISTA
solution as being an orchestration of EHR clinical/business, SOA Suite/ESB, UX Framework, VPR and VDR
services; at IOC, the core MEDICS EHRS/VISTA clinical/business services should, ideally, be provided by legacysystems’ service-façades; at FOC, the same EHR services should be exclusively provided by MEDICS
EHRS/VISTA components / capabilities. Most importantly, the key clinical/business services are:
1. Virtual Patient Record (VPR) Service to collate data from all legacy sources and use it as if it were
coming from one source
a. RLUS (Retrieve, Locate Update Service) fronted databases and COOP (continuity-of-operation) and
performance caches
b. HDD (3M Healthcare Data Dictionary) information-and-terminology models and services supporting
VPR.
2. Care Coordination Services2 enabling “medical-home” type patient-care management
a. Problems, including Diagnosis and Allergies
b. Treatments, including Medication List and Procedures
c. Diagnostic Test Results, including Radiology Reports, Radiology Images, Pulmonary Function Tests,
Electrocardiograms, Laboratory Test Results, Microbiology Results, Pathology Reports, Synoptic
Pathology Reports, Pathology Images
d. Demographics, Advance Directives and Patient / Family Preferences
3. Orders Management Service, ideally, provided within the Care Coordination Service
4. Note Writer Service, ideally, provided within the Care Coordination Service
5. Inventory Management Service, ideally, provided by the Pharmacy capability.
6. CDS (Clinical Decision Support), possibly built from the Business Rules Service
7. UX Portal Framework enabling SSO/CM/AM/ID, secure-mobile devices and medical-domain-specific
portlets3
Adapted from Committee on Data Standards for Patient Safety, Board of Healthcare Services, Institute of Medicine. Key Capabilities of an Electronic
Health Record System Letter Report. 2003. National Academies Press, Washington DC., http://www.nap.edu/catalog.php?record_id=10781
3 SSO/CM/AM/ID=SSO (single sign on), CM (context management), AM (access management), ID (identification). Portlets are pluggable user interface
components
2
WORKING DRAFT
3/21/2016 6:25 PM, Page 5
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
Figure 2 n-tiered Open-Source MEDICS EHRS/VISTA Conceptual Architecture4
The MEDICS EHRS/VISTA conceptual architecture specifies an n-tiered federated deployment topology. The
(virtual) patient record tier, is already available in VistA components, the ESB / SOA Suite services bus tier, the
VLER gateway, and Janus GUI define the MEDICS EHRS/VISTA Platform (aka “ IOC capability 0”) upon which
EHRS Core will be constructed by incrementally adding healthcare-related capabilities/applications.
The VDR (aka, federated database system) is a type of metadata-tagged database management system (DBMS),
which transparently maps multiple autonomous database systems into a single logical data repository and provides
a standard Retrieve, Locate and Update Service (RLUS). The driver in MEDICS EHRS/VISTA using this approach
is the longitudinal nature of the data involved, whereby the mandate that the data must be sustained for more than
75 years. The MEDICS EHRS/VISTA VDR can be a logical or physical partitioning of data among multiple
databases which apply to one or more capabilities / applications. It can support operational data store, data mart,
and data warehouse type queries.
The VDR should support the following requirements:
• To continue “good” care, historical clinical data that currently reside in legacy data bases must be
accessible from the source data repository or an appropriate data warehouse via the VDR.
• Commercial products, like ancillary services, inpatient, and emergency department systems have their own
DBMS that must be accessible via the VDR.
• VDR constituent databases may be geographically decentralized where data may be partitioned by types
(e.g., pharmacy, laboratory, images).
4
Based on Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/21/2016 6:25 PM, Page 6
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
As a whole, the VDR must support key performance parameters.
• The VDR must support a single RLUS.
• The VDR must support near 100 percent availability, even with unreliable hardware.
• The VDR must have a Data Management Lifecycle Plan to consider how database upgrades, database
transitions, and database growth will be handled over time, regardless of the disparate technologies used.
• There is no actual data integration in the VDR constituent databases. Since the constituent database
systems remain autonomous, a federated database system is a contrastable alternative to the (daunting)
task of merging together vastly disparate data types into one physical data repository.
Through data abstraction, federated database systems can provide a uniform
RLUS user interface, enabling users and clients to store and retrieve data in multiple noncontiguous databases with
a single query—even when the constituent databases are heterogeneous. To this end, a federated database
system must be able to decompose each query into sub-queries for submission to the relevant constituent Data
Base Management Systems (DBMS), after which the system must composite the resulting sets of the sub-queries.
Because various DBMS employ different query languages, federated database systems can apply wrappers to the
sub-queries to translate them into the appropriate query languages.
MEDICS EHRS/VISTA common data implies the native use of a single logical database, specified by the HDD. The
HDD manages information and terminology models, a concept dictionary and translation models; where we
recommend the use of the new HL7 Consolidated CDA5 and HL7 Fast Healthcare Information Resource (FHIR)6
information exchange payload models, schemas, and Schematron. These design-time components provide MDR
(Metadata Repository) services to the run-time CTR (Clinical Template Repository) and Built-In Test Environment
(BITE). The HDD provides terminology services that enables semantic interoperability among healthcare trading
partners. BITE enables run-time performance and payload-data-integrity testing of MEDICS EHRS/VISTA ad-hoc
trading partners and plug-and-play applications. BITE uses Schematron, which is a rule-based validation language.
RLUS (Retrieve, Locate and Extraction) provides a data extraction service, a data translation service, an
information exchange mediation service, and BITE services. RLUS relies on identification, authentication,
authorization, access, and secure data transport services. RLUS and HDD “harmonize” the MEDICS EHRS/VISTA
federated data environment.
The proposed rule for Meaningful Use Stage 2 and its companion rule for standards and certification criteria for EHR technology promote
the use of single standards for communicating information in certain transactions. The proposed rule establishes the Consolidated Clinical
Document Architecture (CDA) as the single standard for communicating the summary of care. The Consolidated CDA is based on
components of two standard formats that were previously required for certified EHRs: the Continuity of Care Record (CCR) and the
Continuity of Care Document (CCD). This format was chosen as the standard for communicating the summary of care since it can
accommodate all data elements that CMS proposes providers give their patients after office visits. Health Level 7 (HL7), an accredited
standards development organization, created a single implementation guide for the Consolidated CDA, which was released in December
2011 in an effort to reduce ambiguity and eliminate conflicts in documentation; where, the Consolidated CDA solution encompasses a
library of reusable CDA templates, setting the stage for streamlined development and quicker implementation. The templates allow for
incremental interoperability and easier machine-to-machine communication, thereby facilitating the transfer and storage of more data.
6 Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "Resources" that represent granular clinical
concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for
a range of interoperability problems. The simple direct definitions of the resources are based on thorough requirements gathering, formal
analysis and extensive cross-mapping to other relevant standards. A workflow management layer provides support for designing,
procuring, and integrating solutions. Technically, FHIR is designed for the web; the resources are based on simple XML, with an httpbased RESTful protocol where each resource has a predictable URL; where possible, open internet standards are used for data
representation.
5
WORKING DRAFT
3/21/2016 6:25 PM, Page 7
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
It is important to look at each tier in conjunction with the other tiers. The capabilities / applications and ESB
interactions with each other exist, and the database will influence the way ahead for best approach(es) to managing
the database, performance, and the data lifecycle.
Figure 3 VistA Core
Figure 3 shows a conceptual view of the 2011 OSEHR system architecture. Legacy OSEHR is predominantly
coded in Ansi MUMPS (M) and can be run within the open source GT.M Linux/UNIX environment or within the
InterSystems Cache Windows environment. At the conceptual level, OSEHR has the following major components:
 Applications, such as Scheduling, Pharmacy (Rx), Laboratory, Radiology, ADT plus 100+ other packages
 Kernel/Tools, such as Security, Menu Management, TaskMan, MailMan, Package Manager, etc.
 FileMan, which contains set of APIs, search, inquire, edit, print, utility functions, data dictionary utilities,
transfer entries, etc.
 “Database”, which is composed of FileMan, which manages the M global namespaces and the Data
Dictionary, which defines OSEHR’s hierarchical file layout for Apps., Rx, Lab, Images, Common Data, Plus
over 100+ other files.
Typically, each OSEHR application module generates at-least-one global data file. Within these files are the
clinical, administrative, and computer infrastructure-related information that supports day-to-day operations and
contain patients' medical and healthcare utilization histories, including data on demographics, episodes of care,
medicines, practitioner information, diagnoses, procedures.
WORKING DRAFT
3/21/2016 6:25 PM, Page 8
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
The following problems are being addressed by the future-state architecture:
1. Innovation. Services within a standards-based component-architecture encourage lower-cost component
innovation without requiring enterprise-wide expertise and extensive testing. SDK empowers individuals and
avoids stovepipes.
2. Interoperability among DoD, VA, IHS and purchased care partners. Canonical information and terminology
models can be used to map among heterogeneous system information exchanges. By adopting common HDD
data, terminology, and communications standards; multiple organizations can share and ultimately harmonize
Electronic Medical Records.
3. Transition from legacy systems and data to an interoperable EHR architecture. Virtualization-Layers of
Federated Standards-Based Services allow new and legacy COTS, GOTS and open-source applications,
scaleable databases and infrastructure to coexist.
4. Agility to respond to rapid healthcare changes and related legislation. Services within a standards-based
component-architecture encourage faster and lower-cost changes to be made and tested within components
without requiring enterprise-wide expertise and testing.
5. High Costs of change and sustainment. Virtualization-Layers of Federated Standards-Based Services make
plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and
can be tested efficiently. Interchangeable-components can compete based, on functionality, quality,
performance vs. cost, usability and supportability. Built In Test Environment (BITE) identifies faults early,
improving robustness and reducing test costs. .
6. Patient Safety issues resulting from software changes. Component architecture localizes faults. BITE
identifies faults early, improving system robustness, patient safety.
7. Open Source Community Enablement Virtualization-Layers of Federated Standards-Based Services support
alternate configurations of applications, databases and infrastructure, which may be combinations of MUMPS,
COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities.
Response: We suggest that the VistA Kernel, Fileman and Database be encapsulated into a VistA core
with a set of Services as shown in Figure 4 VistA Core Expanded.
WORKING DRAFT
3/21/2016 6:25 PM, Page 9
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
302
303
Figure 4 VistA Core Expanded
304
305
Figure 5 Proposed MEDICS EHRS/VISTA Logical System Architecture7
7
From Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/21/2016 6:25 PM, Page 10
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
Operational and Technical environment that the DoD’s legacy EHRs operate in.
1.
The DoD has a tiered healthcare delivery network composed of academic medical centers, community hospitals, and standalone health and dental clinics, that are supported by the full range of administrative, logistics, and transportation services. It is a
global enterprise that must also operate in an austere and expeditionary environment (e.g., combat zones and areas
experiencing natural disasters).
2. The work force is composed of military, government civilian, contractor support, and volunteers.
3. The patient population is highly mobile and may present at any of the DoD’s healthcare fixed and expeditionary facilities around
the globe.
4. Patients are typically Service members and their dependents, although there are special cases that do not fall into these
categories.
5. Care is delivered in two (2) ways:
a. the direct care system provides healthcare to DoD beneficiaries in DoD facilities; and
b. the purchased care system provides healthcare to DoD beneficiaries in contractor facilities. Approximately 60% of
healthcare is delivered in the purchased care network.
6. DoD requires the capture of this data from the private sector made available to the EHRS using Health Information Exchange
(HIE) standards and best practices.
7. The technical environment supporting the EHRS is currently composed of 101 host sites operating the CHCS order entry
system (e.g., Laboratory, Radiology, Pharmacy, Patient Administration, Managed Care, Records Management, etc.), a
centralized instantiation of the AHLTA clinical note system, with a hospital-based inpatient system. According to Gartner’s
Generation definitions, this combination of healthcare systems is considered a Generation 2 EHRS.
8. The military services use a DISA provided single logical network on which the EHRS will operate.
9. The DoD desires a regional data storage architecture with virtualization sites placed closer to the direct care facilities.
10. An n-tier architecture is envisioned with
a. a data layer,
b. a Service Oriented Architecture (SOA) / Enterprise Service Bus (ESB) services layer,
c. an application layer, and
d. a user experience (UX) layer for the graphical user interface (GUI).
RESPONSE8: Service-Centric Open Business Model for MEDICS EHRS/VISTA
In order for DoD MHS and VA to successfully deliver and modernize health services, it is necessary to not
only provide an integrated Electronic Health Record system, but to deliver services using an open
architecture as the foundation of an agile ecosystem of health IT vendors. Ensuring modular, composable
business functionality aligned with the VA enterprise architecture provides a path for incremental enterprise
transformation that leverages existing capability within a more flexible IT framework that promotes
innovation and evolution.
As health services are refactored to work within the new open architecture, modularity provides flexibility for
local customization and extension to be balanced with standardization for efficiency. Modular, open
business architectures also promote more rapid and sustainable innovation. New functionality can be more
rapidly implemented, integrated, and provisioned, and assessed without undue impact to the broader
delivery system of systems.
Realizing the full value proposition for the information supply chain requires addressing multiple domains
from operating systems, to application servers, to integration technology, to business domain applications.
Open Source provides the intellectual property foundation for a richer, more diverse, and efficient IT and
health services marketplace.
Services realize their full potential when they can be composed into higher level capabilities for end-to-end
delivery that is user-centric and task focused to the particular business domain and process context. This
8 Edward Ost, Director, Worldwide Technology Alliances, Talend, Open Integration Solutions, 301-666-1039
WORKING DRAFT
3/21/2016 6:25 PM, Page 11
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
requires both efficient delivery using standardized IT in an integration PaaS (Platform as a Service) delivery
model. With multiple open source vendors competing and cooperating in the market place, the value of
individual services is multiplied through re-use that is not limited to a single vendor’s technology. This
preserves SaaS (Software as a Service) flexibility for necessary variation.
Without standardization on an open-source, open architecture reference implementation the solution
implementation is slowed by fruitless variation in IT layers that do not provide value to the end user. At the
same time, competition and innovation at the IT layer must be preserved. An open source solution based
on a truly open community such as Apache is necessary to provide an end-to-end, certifiable environment
for provisioning and composition of services; where, the VA has established OSEHRA to bring those
groups together for this purpose.
Use of proprietary infrastructure, even when it supports open standards for interfaces, restricts the options
for composition of the business components. Vendors must expend additional cycles on supporting
multiple proprietary platforms. Often times the architecture is less flexible as well, running only on JEE
servers. This effectively limits the marketplace to those large vendors capable of providing an end-to-end
solution, whether west-of-suite, best-of-breed or not. Monolithic applications lead to monolithic businesses
which are slow to innovate and adapt.
If the health services are not sufficiently modular and compose-able, or if they are not interoperable,
scalable, and pluggable with IT infrastructure, then the ability to compose solutions is severely
constrained. In contrast, when open source health applications work together using an open source
integration framework the true promise of open source is achieved. Open source, modular frameworks
provide the foundation IaaS and PaaS for an open market place of health services. Open source SaaS
delivered on top of that open platform can transform not just individual systems, but the health service EHR
marketplace.
Requirements
1) The DoD desires open and standardized application program interfaces (APIs) to the EHRS core and
applications, and open access to the data and data model.
RESPONSE: The Janus GUI is open source, at OSEHRA, and should be adapted to meet user and API needs
following an agile methodology.
2) The DoD desires a common and configurable UX that can also be used with the VA EHRS.
RESPONSE: An open source MEDICS EHRS/VISTA core based on open-source VistA will inherently
interoperate with the VA’s VistA configuration. The DOD and VA Secretaries stated that the IOC GUI will be
Janus, which is available as open-source, at OSEHRA. We9 propose the extension of Janus into an open GUI
framework that will support a modular, interchangeable, and reusable open source GUI, using the JAVA
standard GUI API (JSR 168, JSR 186). The purpose of the Web Services for Remote Portlets protocol is to
provide a web services standard that allows for the "plug-n-play" of remote running portlets from disparate
sources. Many sites allow registered users to personalize their view of the website by turning on or off portions
of the webpage, or by adding or deleting features. This is sometimes accomplished by a set of portlets that
together form the portal. The Java Portlet Specification (JSR168, JSR286) enables interoperability for portlets
between different web portals. This specification defines a set of APIs for interaction between the portlet
container and the portlet addressing the areas of personalization, presentation and security.
The open GUI framework will provide structural support for existing GUI systems such as Janus and others by
providing best-practice design and usability guidelines for their expansion and enhancement to meet the needs
9
Parsons Institute for Information Mapping (PIIM) is a member of the OSEHRA organization.
WORKING DRAFT
3/21/2016 6:25 PM, Page 12
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
of the more encompassing integrated EHR. The open GUI framework will promote a modular solution, where
modules can be easily interchanged and integrated into GUIs suitable for various Healthcare settings.
The open GUI framework will promote system usability and support the ability to test GUI designs both before
and after implementation to gauge effectiveness. The open GUI framework will consolidate in one location the
advances made through the redesign efforts of AHLTA, Essentris and others, developing a common interface
that evolves out of all the GUI efforts. OSEHRA has seen some growth in new GUI systems for specific uses
(HealthBoard for the Patient Centered Medical Home). Well designed GUI contributions hold the key to a
number of usability and adoption challenges now faced by existing EHR systems. The open GUI framework
would take advancements made in the OSEHRA community and implement them through a universal
interface.
3) The DoD healthcare data must be interoperable with the VA, and vice versa, supporting the care delivery to
shared or transferring patients. The VA data can be normalized and standardized using the 3M Healthcare Data
Dictionary (HDD) and other appropriate standards.
 RESPONSE: All databases should have an standard RLUS API façade, which uses the 3M HDD and
Common Terminology Service (CTS) to harmonize data into the local VPR cache.
 For IOC, we recommend that the terminology used for the Immunization capability include federally
approved interoperability standards. Most terminology required by the JIC will map directly to the CDC
(Centers for Disease Control) CVX and MVX (immunization substance and manufacturer names) code
sets, wrapped into a SNOMED extension. Other terminology extensions may be required, and those shall
be authored in a manner consistent with the SNOMED standard, and placed in a SNOMED extension
namespace controlled by the IPO iEHR program.
 For FOC, sets of clinical event-data should be represented in Simple Information Models (SJICs) that
conform to the evolving CJICI (Clinical Information Modeling Initiative) and the SNOMED EL++ standard.
These models are limited in number; and, they will require authoring by SMEs (subject matter experts) who
are guided by IPO’s Standards and Interoperability (S&I) Branch informatics-experts. In addition to the
actual terminology-and-information models, a surrounding set of terminology services is required. These
services must provide a variety of application program interface and query capabilities as defined, at a
minimum, by the HL-7/OMG CTS2 (Common Terminology Services 2) Draft Standard for Trial Use10.
Additionally, services should allow translation between equivalent terms, query of available terms, and
exploration of various code sets. Finally, in order to tractably and effectively host, `author, and modify both
the Immunization Capability terminology-and-information models, a Standards and Interoperability
Terminology Workbench is required. Some of these elements, such as the Terminology Services, the
Workbench, and the Simple Information Model/CJICI models are shared, as they are required by a broad
variety of MEDICS EHRS/VISTA medical-specialty capabilities; ultimately, the terminology workbench
should be used by medical department proponents and clinical users allowing user-centric agile-processes,
ultimately managed, in accordance with scope-of-practice, organizational policy, governance and
jurisdictional law.
4) The DoD anticipates that the overall replacement EHRS effort may include, but not be limited to:
(1) system and software engineering;
(2) system integration;
(3) installation, testing, and deployment;
Currently, the HL7 CTS 2 draft standard does not provide full support for SNOMED CT structures; it will need some evolution to bring it where it needs
to go. IPO S&I branch will work with CDC so that CVX and MVX are represented as SNOMED extensions that we can maintain with the IHTSDO
workbench.
10
WORKING DRAFT
3/21/2016 6:25 PM, Page 13
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
(4) lifecycle logistics support to include user training;
(5) system and data hosting;
(6) operations and maintenance (O&M) support; and
(7) business intelligence and research.
RESPONSE: These requirements are standard fare for an RFP response and will not be addressed here;
except to note, the RFP must clearly define the boundaries of the IPO Systems Integrator support, DHIMS
engineering support and the MEDICS EHRS/VISTA required support in order for the vender team to provide a
realistic time and budget.
2. Purpose of this RFI Response
OSEHRA is acting to bring a wide range of community stakeholders’ input into a coherent RFI response at
the vision, conceptual and strategic architecture level. This Information is provided to stimulate the
government’s interest and venders’ open-source response to the MEDICS RFP; specifically, OSEHRA is
facilitating the open-source community to form open-source partnerships or consortia and for industry to bid
an Open-Source VistA-based solution for the “MEDICS EHRS/VISTA Core Capabilities” RFP. All
information developed in this open-source MEDICS Vision and Strategy RFI response is public and is freely
available to everyone, on the OSEHRA web-site. OSEHRA believes its open-source MEDICS vision,
conceptual architecture and strategic vision will result in a compelling (faster, better and cheaper) Business
Case for an open-source MEDICS EHRS/VISTA; considering that schedules are tight and that the
governments’ evaluation criteria is “Best Value to the Government”.
Full Disclosure / Disclaimer / Acknowledgement
OSEHRA can NOT bid on Federal Contract RFPs and OSEHRA does NOT speak for the government or any
particular company. Rather, OSEHRA is acting as a trusted-agent to bring a wide range of community stakeholders
together to espouse a win-win open-source MEDICS EHRS conceptual architecture and strategic vision RFI
response, leveraging OSHERA VistA (OV) to the core and extended vision of the RFI.
Assumptions
“OSEHRA is fully aware of the DOD and VA Secretaries’ February 5, 2013 announced changes to the iEHR
project. We are equally aware of the pending (February 27, 2013) session to be conducted under the House
Veterans Affairs Committee. Our understanding is that the iEHR investment by the Departments will be continued to
the described schedule for IOC and FOC as described, which includes:
1. The further maturation of the iEHR “User Experience” based on the JANUS GUI which is in pilot
2. The completion of the schedule for the deliverable infrastructure and associated integration of the iEHR
SOA-ESB to the Development Test Center(s), the greater San Antonio area, and the greater Norfolk area
3. It is likely that many of the “Capability Set 0” services based on the ESB/SOA Suite to include Identity
Management, User provisioning, security and potentially Provider Order Entry (POE) will be available to the
MEDICS EHRS through the SOA ESB/Suite.
4. We have not seen any update to the clinical capability deployment plan for the ESB/SOA project
It is our assumption in the OSEHRA response to the RFI; provided below, that MEDICS EHRS core will leverage
the investment(s) already made Jointly to deliver the Core Solution and to “provision” the MEDICS EHRS Core
through application, clinical and business capabilities sequentially, prioritized by need and availability. The reasons
for our assumption are that the above items have already been invested by DoD, and that they are both consistent
with the MEDICS EHRS core vision and leveragable to that “Vision. “
WORKING DRAFT
3/21/2016 6:25 PM, Page 14
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
Why Open Source?
“Maximizing the rate of EHR innovation” means engaging the best minds in government, industry, and academia.
Developers must be comfortable contributing their innovations and users must be comfortable relying on the
software to run their enterprise. A well-constructed open source model provides the relationship between
developers, users, vendors, and service providers and provides the infrastructure for their efficient interaction.
Why OSEHRA?
OSEHRA simply and powerfully establishes an organized framework for all kinds of companies and creative
individuals – users, developers, service providers, researchers, universities and for-profit companies – to
communicate, collaborate, and share. The open source ecosystem is a transparent, rapid and safe way to
accelerate progress in creating an ever improving, and highly functional EHRS for the beneficiaries of healthcare,
and more broadly, the nation as a whole.
Why Open-Source MEDICS EHRS/VistA Core?
We believe that MEDICS EHRS/VistA supports a faster, better, cheaper business case to meet
1) the DOD and VA Secretaries objectives
a. to select a “core set of IEHR capabilities no later than March of 2013”
b. to support 2014 iEHR IOC (Initial Operating Capability)
c. to be the foundation for 2017 iEHR FOC (Final Operating Capability) and
2) the President’s and Congressional objectives for an integrated DOD and VA EHRS.
VistA was designed by clinicians for clinicians, VistA is patient-centric and embodies the clinical workflow processes
that support VA’s models of care; where it has enabled measurable improvements in health outcomes and is central
to the VA’s ability to deliver high quality lifetime care to a large and varied Veteran population. “Clinicians consider
VistA the best health information system in the world, bar none; at the same time, VistA is very old, very hard to
maintain, hard to manage and manipulate, and incredibly expensive to maintain.”
MEDICS EHRS/VistA Core can be “reengineered” in the sense of using iEHR’s n-tiered architecture and
OSEHRA’s, open-source, open-standards ecosystem within which the proven functional capabilities of VistA can be
replicated, modernized, and enhanced in a sustainable, scalable, and secure environment
The recommended quick-win approach11 boils down to:
1. Starting with the iEHR n-tiered architecture; then, encapsulating VistA core with a SOA façade and a
service orchestration adding a DOD business process / workflow & CDS (Clinical Decision Support) layer
and data interoperability layer. This reengineered system should be done using a contemporary federated
n-tiered SOA ESB, GUI, Cloud-Based (Data Store and processor, Communications) architecture, which is
more structured and properly componentized (with components from internal VA development, external
development by paid contractors, project grants, and open source community, or commercial off the shelf
products).
2. Restructuring the existing VistA system, piece by piece, into a more modular and well behaved application
while still using it. (“Change the tires, while the car is still on the road.”) Open-Source software is not free…
Twenty approaches were suggested within the VistA Modernization Report:
11
Based on VistA Modernization Working Group Report, May 4, 2010, American Council on Technology, Industry Advisory
Council
WORKING DRAFT
3/21/2016 6:25 PM, Page 15
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
Innovation and a MEDICS EHRS/VISTA Future State Vision
AHLTA has been condemned by its users12; while, VistA has a fervent user acclaim and is known for user driven
innovation. We recommend a continuation of stakeholder innovation with an IOC MEDICS core, based on VistA,
which supports a natural FOC migration to …
VistA - the core of a Cloud-based MEDICS EHRS
The following is an open source community-based13 recommendation for MEDICS as the core of a Cloud-based
Electronic Health Record System (EHRS) and how best to link DoD, VA and partner data going forward. Both topics
are relevant for the DoD's MEDICS EHRS RFI, specifically for sections 3.2, 3.7a, 3.9.
MEDICS EHRS - from Piecemeal to the Cloud
Broadly there are three classes of EHRS. First there’s the collection of loosely coupled, self-contained applications
each performing an exclusive function, such as Pharmacy, Radiology, Lab or Scheduling. Here you have limited
data-exchange that relies on the widely deployed HL7 V2 protocol and individual applications come from different
vendors. Such a Piecemeal EHRS is typical in private-sector hospitals. Yes, you have vendor choice but you also
suffer data-lockup, where much of the information of the system remains silo'ed in one application or another. We
propose freeing the data …
Secondly, and until recently, the only alternative to such a system was the integrated suite of applications. Like the
traditional Microsoft Office, Suite EHRS are built around a common framework, which allows and promotes a great
deal of data and component reuse, and they come from a single vendor like Epic, or like the VA's VistA or the
DoD's AHLTA, they originate in-house at large institutions. But here what you gain in reuse, you lose in the ability to
introduce outside components.
Now there's a third EHRS type, the Cloud-Based. With the advent of high capacity networks and cloud storage
which can enable mobile applications that leverage common services and UX framework over a network. An EHRS
built this way would have the component reuse and data sharing of the traditional suite, while being open to multiple
vendors.
VistA - evolving to a Cloud-based MEDICS EHRS
Fortunately those who have deployed Suite EHRS can evolve to this more flexible architecture, just as Microsoft
made the latest Office a cloud-based suite. Select framework functions needed to move into a cloud equivalent and
the current obscure data models need to be comprehensively defined and made easially upgradable.
Is VistA the easiest Suite EHRS to migrate to the Cloud? Consider this - Epic, the other major Suite
EHRS, has embedded a great deal of logic in its Visual Basic coded client. VistA, on the other
hand, has most of its logic in its server framework. This choice - and the choice of the now obsolete
Visual Basic - will make it significantly harder to migrate Epic.
In the EHRS world, VA VistA is an example of this evolution. A networked service (e.g., First Data Bank) for
checking drug-interactions has replaced an equivalent in VistA's self-contained, locally accessible framework and
that is now working at OSEHRA. This ambitious vision is to fully open VistA up to allow applications from many
parties, of all shapes and sizes, in any programming language, to leverage VistA's proven framework over a
network.
12
The 2009 EHR User Satisfaction Survey Responses From 2,012 Family Physicians by Robert L. Edsall and Kenneth G. Adler, MD, MMM
available at http://www.aafp.org/fpm/20091100/10the2.html
13
This section provided by Conor Dowling, Rafael Richards; Carol Monahan; Rick Marshall of Caregraf
WORKING DRAFT
3/21/2016 6:25 PM, Page 16
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
"Networking the Framework" is a sensible strategy - the advantage of retaining existing functionality is that it is
proven. It is often cost-prohibitive to re-engineer all of the special cases and particulars accounted for by a
comprehensive framework built over many years.
In VistA's case, networked versions of MEDICS EHRS/VISTA core services - Lexicon, Document
Template Management, Order Management, Lab and Drug type mapping services - should free up
third parties to focus on novel presentation and newer capabilities. Which leaves full and
comprehensive data definition, a MEDICS EHRS/VISTA core Framework's Data Architecture.
While it is acceptable to "just know" the shape of data when applications are all local, are all in one
programming language, all by one party, a federated networked system requires clear-cut,
complete data definition.
The federated MEDICS EHRS/VISTA Networked Framework needs to be explicit about what data it needs, stores
and produces. What does a Prescription look like? A Problem? A Surgical Procedure? … these all require Detailed
Clinical Models (DCMs). And here OSEHRA can contribute moving VistA forward by managing the fuller definition
of MEDICS EHRS/VISTA core framework's data model using the latest standards and technologies.
Two pieces – ESB key services (i.e., networking, common, clinical, financial and administrative) and being explicit
about data - allow VistA to evolve into a federated, Cloud-based MEDICS-EHRS, which is open to outside
developers and better able to interoperate with other systems. It also makes VistA much more applicable outside
the VA, in part because there's no need to adopt it wholesale - it can now mix and match.
DoD, VA and Partner Data - Just Publish and Link
Traditionally interoperability meant two parties reducing their information to commonly agreed subsets, all too often
ridiculously inadequate in scope; and then, putting the result into some agreed markup and sending it over some
bus or pipe. In the meantime, both parties continued to expand the data they had and exchange never kept up. For
the VA and DoD, you see that in VLER and the efforts in North Chicago; where, we have too-little meaningfulexchange that has taken too long to put in place. With Linked-Data - data on the Web - this can change.
iEHR talks about a Common Information Interoperability Framework (CIIF) for ensuring data
compatibility. In Linked-Data, this framework would be a mechanism for analyzing and adding data
linkage as would the Concept Manager like 3M's HDD. iEHR also talks about data mobility using a
Retrieve Locate Update Service (RLUS); where, in the Linked-Data approach, such a service
would be implemented using W3C standards for data update, construction and retrieval.
In Linked-Data, data exchanges use the same architecture and technologies that have proven so successful for
hyperlinked documents. Data doesn't hide behind APIs and wrappers. It is fully exposed, as is, with each piece
given a URL linked to other URL-carrying data. Every Patient gets a URL, every Vital Measurement gets one too.
So does every type of Drug or Observation, every Physician, every Clinic. In this model, an enterprise database,
such as Cassandra, is composed of URLS pointing to federated VistA NOSQL data stores; hence, the system-ofrecord can remain the federated data stores.
On top of this publication is a query mechanism that, like SQL for relational stores, lets analytical CDS systems ask
questions, such as What Patients took Drug Such and Such for a particular set of conditions and what were their
outcomes? Or in Linked-Data terms, what is the URL of the Patient who took the Drug identified with such and such
WORKING DRAFT
3/21/2016 6:25 PM, Page 17
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
a URL? Got data in a relational store? There's a Linked-Data tool to publish it all. In a NoSQL store, like VistA's
FileMan? There's a tool for that too.
As the name suggests, Linked-Data is all about Links. The question of whether data is well structured reduces to
how many links does it have? The question of whether two data sets are compatible reduces to how interlinked
are they? When you publish data this way, you expose its nature and can see how to improve it.
The approach here is "publish everything now and improve as you use", rather than honing a
pristine, all-too-small view of data. Exchange of pristine subsets of what's available is replaced by
interlinking of fully published data.
Of course not everything that should link links right away. For example, if a Prescription in DoD identifies a drug
with a URL based on a HDD NCID, and the VA equivalent has URLs with VA VUIDs, they won't link because both
prescriptions identify the same drug using different URLs. But just because they don't immediately link doesn't
mean that the VDR (Virtual Data Repository) can’s ultimately add NCID-VUID-SNOMED link(s), as the need arises.
After publication comes analysis of "dead ends", islands of data unlinked outside an organization. How could it link?
What data in one organization is the same as data in another and as a result can link up? Bit by bit, through new
links, data joins up. While mutual understanding isn't automatic, just by exposing data on the web, the points and
amount of misunderstanding, of where links are lacking, becomes clear, and can be automatically quantified and
incrementally fixed. Obviously, we don’t expose protected patient data; rather, we are exposing publically available
HDD metadata links, which correspond to the data structure.
A data exchange mechanism that can publish both data like the DoD's that is in relational stores and like the VA's
that is in noSQL, that supports measurable and incremental improvement - isn't this what both the DoD and VA
require?
The DoD is performing market research to ascertain the interest, capabilities, Rough Order of Magnitude (ROM) life
cycle costs, and available solutions within the healthcare industry to provide the following:
1. An EHRS core, as defined in paragraph 1, or as recommended by the interested party to meet the
purposes of the core.
2. A full EHRS system capable of adding, upgrading, and interfacing with BoB products
RESPONSE: Estimating a rough order of magnitude (ROM) for open-source MEDICS EHRS/VISTA core and
capabilities, well before concrete technical information is available on the program being developed, can only
be based on a desired capability—or even on an abstract concept—rather than a concrete technical solution
plan to achieve the desired capability. Hence the role and modeling of assumptions becomes more
challenging. OSEHRA recommends the CMU (Carnegie Mellon University) approach to Quantifying
Uncertainty in Early Lifecycle Cost Estimation (QUELCE) conducted by the SEI Software Engineering
Measurement and Analysis (SEMA) team.
It should be noted that open-source does not mean free; but rather, many of the DOD specific integration and
deployment costs will be the same; regardless of the specific EHRS. However, licensing cost are eliminated
for open-source components and innovation is increased; because of transparency to any interested party, be
they a clinician at a hospital or a computer scientist in industry. The open-source approach is a Darwinian trialand-error march to excellence.
WORKING DRAFT
3/21/2016 6:25 PM, Page 18
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
709
710
711
712
713
714
715
716
717
718
i. Software, to include licensing arrangements / pricing model
Response: Since the “core software” of the OSHERA VistA EHRS solution is an Apache-2.0 open-source
license and is based upon the fully acquirable VistA, MDWS, VPR, Janus software, there is no licensing
cost to the current core capability over the life-cycle. Through OSEHRA developers and partners, there will
be potential costs to enhancements and extensions, which are often shared across stakeholders. These
updates to the OSERHA VistA core are added as further capabilities and are tested and certified by
OSEHRA in its established processes.
To Comment on the potential gap in the RFI with respect to Dental, please note that the Veterans
Administration’s VistA Dental Record Manager Plus is an enhancement to the base VistA dental record
module developed by DSS Inc. who is a contributing member of OSHERA
ii. Hardware
Response: Open-source Vista will run on virtual machines, hosted on the blade servers, which the
government already plans to deploy at the DISA centers and regional sites. Obviously, system engineering
and performance tuning must be done, over time, to maximize the cost-performance of the deployment.
It needs to be remembered that the Core and a limited Full EHRS is required for the Theater, Remote
(low/no Communications) settings and there will be a hardware investment, or more likely a coordination of
hardware Refresh to the current DoD planning to those sites and much of the above.

Inherently, the recommended VistA solution, with RLUS fronted databases supports the TMIP (Theater
Medical Information Program) data integrity approach to a disconnected (no network available) mode. In
696
detached operations, data is pre-cached in the VPR
697
and when connectivity is established, standard store698
and-forward and standard database-synchronization
699
techniques are used. For mobile displays, secure
700
memory-less HTML-5 can be used. The
701
recommended RLUS, UX framework and (open702
source Janus) EHRS platform components make
703
porting capabilities to multiple-types of mobile or
704
detached-platforms simpler and less costly. This
705
approach also supports LCS (Local Cached Storage)
706
for dynamic performance-tuning and a graceful
707
COOP (Continuity-of-Operations) in the event
708
connectivity is lost to regional DISA centers.
Figure 6 The Recommended MEDICS EHRS/VISTA core supports
Mobile Displays, Detached Operations and COOP
iii. Implementation, to include development, test, and integration (e.g., network, external devices,
external systems)
Response: OSEHRA is already a “self-organized” and functioning development, test and integration
environment. The replication of the current AHLTA-CHCS +Essentris instance to the OSEHRA environment
would follow the pattern that has been engaged under the maturation of the Development Test Center in
Richmond VA and the expansion of the capabilities of the DISA Joint Information Technology Centers in
WORKING DRAFT
3/21/2016 6:25 PM, Page 19
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
719
720
721
722
723
724
725
726
727
728
729
730
731
CONUS and particularly in the Military Health System's Pacific Joint Information Technology Center (P-JITC) in
Maui. This approach is selected both to save considerable costs and to integrate the parallel paths and phasing
that the DoD is engaged in currently. Equally, this is an approach that is focused upon leveraging the current
investment in DISA cited in the RFI. Finally, DTC Richmond and the P-JITC are already “equipped” with
instances of VistA-CPRS and CHCS, with other external systems linkages either in execution or planning to
include DEERS testing instance(s) from DMDC.
iv. Deployment, with your timeline, for the following:
a) Development and Test Center environment for test prior to deployment
b) 13 academic medical ce n t e rs with 144,692 admissions , 214,812 procedures
c) 43 community hospitals with 95,017 admissions, 119,875 procedures
Response: Considering the 5 February 2013 DOD and VA Secretaries stated milestones14 and the published iEHR
2014 IOC and 2017 FOC milestones, the following milestone schedule is applicable.
14
On 5 February 2013, the DOD and VA Secretaries stated that “in the short term, that we've agreed to
1. Improve data interoperability to that integrated electronic health record before the end of this year, by standardizing health care data no later
than December 2013,
2. Creating health data authoritative source no later than September of 2013,
3. Accelerating the exchange of real-time data between V.A. and DOD no later than December of 2013, and
4. Allowing V.A. and DOD patients to download their medical records, what we call our Blue Button Initiative, no later than May of 2013, and,
finally,
5. Upgrading the graphical user interface, this thing we call the GUI, to display the new standardized V.A. and DOD health care data no later than
December of 2013,
6. Expand the use of the Janus graphical user interface, the GUI, to seven additional sits and its expansion of two DOD sites no later than July
2013 …
7. Select a core of -- core set of IEHR capabilities no later than March of 2013 …
8. Achievement of the president's goal in 2014 … to do everything possible to try to put the health care systems of both these departments
together for the benefit of our troops.”
WORKING DRAFT
3/21/2016 6:25 PM, Page 20
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
732
LEGEND
Green Administration’s Milestones
Blue DOD and VA Secretaries’ Milestones
Red MEDICS EHRS/VistA Core Milestones
4/13
iEHR
DOD MEDICS
Core
EHRS/VistA
Selected Specified
3/13
5/13
Blue
Button
4/13
5/13
6/13
Authoritative
Sources
6/13
12/13
“DOD & VA GUI Exchanging
Standardized
11/13
Healthcare
DOD MEDICS
Data which Is
EHRS/VistA
Ready for IATO 2014 iEHR IOC Ready”
8/13
Development
and
Test Center
7/13 environment
Janus for test prior
GUI to deployment
7/13
8/13
9/13
10/13
11/13
12/13
3/1/2013
12/31/2013
2/14
Start
iEHR IOC
Integration and
Deployment
2/14
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
12/14
Achievement of the
president's goal in 2014
to do everything possible
to try to put the health care systems
of both these departments together
for the benefit of our troops.
9/14
Start Deployment to
13 academic
medical center and
43 community hospital
3/14
4/14
5/14
6/14
7/14
8/14
9/14
10/14
11/14
12/14
1/1/2014
12/31/2014
Figure 7 High Level MEDICS EHRS/VistA Milestone Schedule,
Based on Administration plus DOD and VA Secretaries’ Milestones
v. Training
Response: OSEHRA will NOT bid on an RFP; rather, this RFI response provides an open-source MEDICS
EHRS/VistA vision, conceptual architecture and strategic vision for the government and its contractors to follow.
vi. Business process reengineering and change management
Response: OSEHRA can provide a forum to support change management needs determination.
vii. Sustainment
Response: The OSEHRA open-source community, including providers and developers, can be a catalyst for
continual improvement; and, OSEHRA can help manage change, test and certification.
3. Capability Statement Submission Scope
OSEHRA’s RFI response is limited to a conceptual architecture and strategic concepts deems applicable by the
open source community, with the expectations that one-or-more commercial venders will provide the tactical details
in their RFP responses. This section describes how OSEHRA and the open-source community general approach
and capability to respond to the MEDICS EHRS RFP.
WORKING DRAFT
3/21/2016 6:25 PM, Page 21
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
3.1 General
OSEHRA supports an open, collaborative community of users, developers, and companies engaged in advancing
electronic health record software and health information technology. OSEHRA’s mission is to facilitate, through the
use of the best practices in open source software development, the improvement and maintenance of EHR
information systems. These systems will be freely available for all medical beneficiaries and – like other successful
open source communities – will welcome the contributions of all kinds of developers.
1) Provide the business name and / or team name, a point of contact (POC), address, and DUNS number.
Seong K. Mun, PhD, President and CEO
OSEHRA - None-Profit Corporation
900 N. Gelbe Road, Arlington, VA
571-858-3201
2) Provide an indication of current certified business and socioeconomic status; this indication should be clearly
marked on the first page of the capability statement.
Response: OSEHRA is a custodial agent and will not respond to any RFP; specifics will be provided by the
responding vender.
3) Provide a description of the proposed core capability set, and the full EHRS, that meets the objectives provided
in this RFI.
Response: Please see response 3.2.1.a and the VistA description attachment.
4) Provide a description of the company or team’s background, technical expertise, experience, staffing, and other
capabilities that demonstrate its capability to provide the anticipated objectives listed in Attachment (1).
Specifically:
a) Describe your approach, with a corresponding timeline, to support an initial deployment of two separate
and distinct hospital sites using at least the core, and possibly the entire EHRS, and then to all the
remaining DoD medical facilities (i.e., hospitals and clinics).
Response: OSEHRA will NOT bid on an RFP; rather, this RFI response provides an open-source MEDICS
EHRS/VistA vision, conceptual architecture and strategic vision for the government and its contractors to
follow.
b) Describe your Agile approach and timeline to configure and deploy the EHRS at multiple sites and in
multiple healthcare environments across multiple time zones, scaling up to world-wide deployments. The
Government will provide a product owner who will be embedded in each Scrum team. Describe your
management approach to using two-week sprints ending in demonstrations.
Response: same as 4.a.
c) Describe your approach to scale the development and integration of complex healthcare systems with
greater than five (5) million members.
Response: See Figure 11: Proposed Systems Engineering / Integration Approach and Figure 12 Proposed
Transition-Strategy for MEDICS EHRS Linkage to Legacy Systems plus associated write-ups.
d) Describe your approach to implement, configure, deploy, and / or develop, an EHRS using Agile Scrum
processes.
RESPONSE: OSEHRA and its community, focus on how open source and open architecture can be
applied to middleware servers to provide an incremental but rapid path to enterprise transformation that
enables development of SaaS (Software as a Service) capability using Service Oriented principles. The
convergence of open ESB platforms with Service Oriented Architecture (SOA) principles delivered using
Cloud delivery models realizes the vision of Platform as a Service (PaaS) to transform the delivery of IT
WORKING DRAFT
3/21/2016 6:25 PM, Page 22
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
systems in a manner that dramatically increases business agility while minimizing project and enterprise
risk profiles.
Enterprise Use Case
Consider a typical enterprise with multiple packaged applications, a growing number of external and
perhaps on-premise SaaS providers, and custom enterprise applications specific to their domain. A
common integration bus that provides service adaptors for the SaaS, packaged applications, and in-house
applications is desired. These adaptors should provide location transparency and service virtualization to
all enterprise systems in order to provide business and technical agility. Elastic scalability and high
availability are necessary IT attributes for responsive infrastructure. In addition, service virtualization must
extend the reach of the SaaS experience to business analysts using BPM (Business Process Modeling)
tools to re-engineer and compose new processes. In order for this to succeed, all service endpoints should
be optimized to share a common set of management infrastructure. These services must be available
regardless of the application servers being used to host the existing business systems. Finally, it must also
apply to both service providers and service consumers in order to accurately manage workload and service
level agreements (SLA).
Agile Development is more than process. Open Source Software (OSS) follows a federated agile development and
test process encompassing engineering agility via modularity. This results in an Open Business Model = OSS +
Open Architecture.
WORKING DRAFT
3/21/2016 6:25 PM, Page 23
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
822
823
824
825
826
827
828
829
830
Traditional proprietary middleware server solutions require separate server processes. In contrast, open-source
architecture uses lightweight, modular integration components, such as those available from Apache based on the
OSGI standard that can be deployed as dedicated integration servers or embedded as smart endpoints for peer-topeer architectures that simplify adoption of PaaS. In contrast to proprietary middleware products, An open-source
ESB can provide portable, embedded smart endpoints that span heterogeneous application servers. These smart
endpoints provide a common service management infrastructure independent of the application server. When
dedicated integration servers make sense.
831
832
833
834
835
The net effect of an open source, open architecture approach is architectural agility that enables low risk
evolution. The lightweight Apache type foundation can be leveraged to provide common, portable,
standards based management infrastructure across heterogeneous systems. The service management
infrastructure provides the foundation for PaaS capability that can support development of SaaS. The open
WORKING DRAFT
3/21/2016 6:25 PM, Page 24
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
836
PaaS architecture also provide project flexibility that enables efficient and timely application of human
837
resources to migrate existing systems in a manner consistent with contract, budget, and enterprise
838
planning constraints.
839
840
3.2 EHRS Solution
841
1) Describe the functionality within your solution. At a minimum:
842
a) Describe how your EHR core addresses the DoD’s definition of an EHRS core as described in paragraph 1. The DoD is
843
interested in industry’s feedback on DoD’s core definition, to include (1) comparing it to how they define their product’s core, (2)
844
describing potential differences and the reasons for those differences, and (3) providing recommendations with regards to the
845
use of the DoD model and how their product core compares to the DoD model.
846
847
RESPONSE: MEDICS EHRS/VistA can support both ambulatory and inpatient care; where the most
848
significant capabilities are computerized order entry (medications, special procedures, X-rays, nursing
849
interventions, diets, and laboratory tests), bar code medication administration, electronic prescribing, and
850
clinical guidelines. Details are available at: http://architecture.osehra.org and an MS Word version is available
851
at: http://www.osehra.org/document/osehra-vista-system-architecture-product-definition-and-roadmap-updated852
2012-03-06 The follow-on RFP may choose among the following to augment the Figure 3 VistA Core / Figure 4
853
VistA Core Expanded MEDICS EHRS/VISTA Core capabilities; because the following capabilities are
854
immediately available; and, they can be refactored / reengineered in an orderly fashion as time and budget are
855
available:
889
31. Laboratory: Anatomic Pathology
856
890
32. Laboratory: Blood Bank
857
Clinical Capabilities
891
33. Laboratory: Blood Bank Workarounds
858
1. Admission Discharge Transfer (ADT)
892
34. Laboratory: Electronic Data Interchange (LEDI)
859
2. Ambulatory Care Reporting
893
35. Laboratory: Emerging Pathogens Initiative (EPI)
860
3. Anticoagulation Management Tool (AMT)
894
36. Laboratory: Howdy Computerized Phlebotomy Login
861
4. Automated Service Connected Designation (ASCD)
895
Process
862
5. Beneficiary Travel
896
37.
Laboratory: National Laboratory Tests (NLT)
863
6. Blind Rehabilitation
897
Documents and LOINC Request Form
864
7. Care Management
898
38.
Laboratory: Point of Care (POC)
865
8. Clinical Case Registries
899
39.
Laboratory: Universal Interface
866
9. Clinical Procedures
900
40.
Laboratory: VistA Blood Establishment Computer
867
10. Clinical/Health Data Repository (CHDR)
901
Software (VBECS)
868
11. Computerized Patient Record System (CPRS)
902
41.
Lexicon Utility
869
12. CPRS: Adverse Reaction Tracking (ART)
903
42.
Medicine
870
13. CPRS: Authorization Subscription Utility (ASU)
904
43.
Mental Health
871
14. CPRS: Clinical Reminders
905
44.
Methicillin Resistant Staph Aurerus (MRSA)
872
15. CPRS: Consult/Request Tracking
906
45.
Mobile Electronic Documentation (MED)
873
16. CPRS: Health Summary
907
46.
Nationwide Health Information Network Adapter
874
17. CPRS: Problem List
908
(NHIN)
875
18. CPRS: Text Integration Utility (TIU)
909
47.
Nursing
876
19. Dentistry
910
48.
Nutrition and Food Service (NFS)
877
20. Electronic Wait List Pharm: National Drug File (NDF)
911
49.
Oncology
878
21. Emergency Department Integration Software (EDIS)
912
50.
Patient Appointment Info. Transmission (PAIT)
879
22. Functional Independence Measurement (FIM)
913
51.
Patient Assessment Documentation Package (PADP)
880
23. Group Notes Primary Care Management Module
914
52.
Patient Care Encounter (PCE)
881
(PCMM)
915
53.
Patient Record Flags
882
24. HDR – Historical (HDR-Hx)
916
54.
Pharm: Automatic Replenish / Ward Stock (AR/WS)
883
25. Home Based Primary Care (HBPC)
917
55.
Pharm: Bar Code Medication Administration (BCMA)
884
26. Home Telehealth
918
56.
Pharm: Benefits Management (PBM)
885
27. Immunology Case Registry (ICR)
919
57.
Pharm: Consolidated Mail Outpatient Pharmacy
886
28. Incomplete Records Tracking (IRT)
920
58.
Pharm: Consolidated Mail Outpatient Pharmacy
887
29. Intake and Output Scheduling
921
59.
Pharm: Controlled Substances
888
30. Laboratory Shift Handoff Tool
922
60. Pharm: Data Management (PDM)
WORKING DRAFT
3/21/2016 6:25 PM, Page 25
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
1029
61.
62.
63.
64.
65.
66.
Pharm: Drug Accountability
Pharm: Inpatient Medications
Pharm: Outpatient Pharmacy
Pharm: Prescription Practices (PPP)
Prosthetics
Quality Audiology and Speech Analysis and Reporting
(QUASAR)
Radiology / Nuclear Medicine
RAI/MDS
Remote Order Entry System (ROES)
Social Work
Spinal Cord Dysfunction
Standards & Terminology Services (STS)
Surgery
Traumatic Brain Injury (TBI)
Virtual Patient Record
VistA Imaging System
VistAWeb
Visual Impairment Service Team (VIST)
Vitals / Measurements
Womens Health
977
978
979
980
981
982
983
67.
984
68.
985
69.
986
70.
987
71.
988
72.
989
73.
990
74.
991
75.
992
76.
993
77.
994
78.
995
79.
996
80.
997
998
Financial-Administrative Functions
999
1. Accounts Receivable (AR)
1000
2. Auto Safety Incident Surv Track System (ASISTS)
1001
3. Automated Information Collection System (AICS)
1002
4. Automated Medical Information Exchange (AMIE)
1003
5. Clinical Monitoring System Integrated Billing (IB)
1004
6. Compensation Pension Record Interchange (CAPRI) 1005
7. Current Procedural Terminology (CPT) Library
1006
8. Decision Support System (DSS) Extracts
1007
9. Diagnostic Related Group (DRG) Grouper
1008
10. Electronic Claims Management Engine (ECME)
1009
11. Engineering (AEMS / MERS) Police and Security
1010
12. Enrollment Application System Quality Management 1011
Integration Module
1012
13. Equipment / Turn-In Request
1013
14. Event Capture Release of Information (ROI) Manager 1014
15. Fee Basis
1015
16. Fugitive Felon Program (FFP)
1016
17. Generic Code Sheet (GCS)
1017
18. Health Eligibility Center (HEC)
1018
19. Hospital Inquiry (HINQ)
1019
20. ICD-9-CM
1020
21. Incident Reporting
1021
22. Income Verification Match (IVM)
1022
23. Integrated Patient Funds
1023
24. Occurrence Screen
1024
25. Patient Representative
1025
26. Personnel and Accounting Integrated Data (PAID)
1026
27. Record Tracking
1027
28. Veterans Identification Card (VIC/PICS)
1028
29. Voluntary Service System (VSS)
30. WebHR
31. Wounded Injured and Ill Warriors
Infrastructure Functions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
Capacity Management Tools
Duplicate Record Merge: Patient Merge Name
Standardization
Electronic Error and Enhancement Reporting (E3R)
Enterprise Exception Log Service (EELS)
FatKAAT
FileMan
FileMan Delphi Components (FMDC)
Health Data Informatics
HL7 (VistA Messaging)
Institution File Redesign (IFR)
KAAJEE
Kernel
Kernel Delphi Components (KDC)
Kernel Toolkit
Kernel Unwinder
List Manager
M-to-M Broker
MailMan
Master Patient Index (MPI)
Medical Domain Web Services (MDWS) (MWVS*2)
National Online Information Sharing (NOIS)
National Patch Module
Network Health Exchange (NHE)
Patient Data Exchange (PDX)
Remote Procedure Call (RPC) Broker
Resource Usage Monitor
Single Signon/User Context (SSO/UC)
SlotMaster (Kernel ZSLOT)
SQL Interface (SQLI)
Standard Files and Tables
Statistical Analysis of Global Growth (SAGG)
Survey Generator
System Toolkit (STK)
VistA Data Extraction Framework (VDEF)
VistALink
XML Parser (VistA)
Patient Web Portal Functions
1.
2.
3.
4.
5.
6.
7.
8.
9.
WORKING DRAFT
Clinical Information Support System (CISS)
Electronic Signature (ESig) Person Services
HealtheVet Web Services Client (HWSC) Registries
My HealtheVet Spinal Cord Injury and Disorders
Outcomes (SCIDO)
National Utilization Management Integration (NUMI)
Occupational Health Record-keeping System (OHRS)
Patient Advocate Tracking System (PATS)
VA Enrollment System (VES)
Veterans Personal Finance System (VPFS)
3/21/2016 6:25 PM, Page 26
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
b) Identify specific functions / modules provided in your EHRS and how each function / module is priced.
Describe the ability and impacts of turning off specific function(s) which are not essential to the core EHRS,
but support the use of interfaced BoB applications. Describe the impacts or benefits of utilizing alternate
BoB applications to obtain those functions or capabilities.
RESPONSE: Usage in non-VA hospitals - Under the Freedom of Information Act (FOIA) and at OSEHRA, the VistA
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
system, associated add ons (MDWS, Janus, HeathyVet) and unlimited ongoing updates (500–600 per year) are provided
as public domain software.[22] This was done by the US government in an effort to make VistA available as a low cost
Electronic Health Record (EHR) for non-governmental hospitals and other healthcare entities.
With funding from The Pacific Telehealth & Technology Hui, the Hui 7 produced a version of VistA that ran on GT.M in a
Linux operating system, and that was suitable for use in private settings. VistA has since been adapted by companies
such as Blue Cliff, DSS, Inc., Medsphere, and Sequence Managers Software to a variety of environments, from individual
practices to clinics to hospitals, to regional healthcare co-ordination between far-flung islands. In addition, VistA has been
adopted within similar provider environments worldwide. Universities, such as UC Davis and Texas Tech implemented
these systems. A non-profit organization, WorldVistA, has also been established to extend and collaboratively improve
the VistA electronic health record and health information system for use outside of its original setting.
VistA (and other derivative EMR/EHR systems) can be interfaced with healthcare databases not initially used by the VA
system, including billing software, lab databases, and image databases (radiology, for example).
VistA implementations have been deployed (or are currently being deployed) in non-VA healthcare facilities in Texas,[23]
Arizona,[24] Florida, Hawaii,[25] New Jersey,[26] Oklahoma,[25] West Virginia,[27][28] California,[29][30] New York,[31] and
Washington, D.C.[25][32]
In one state, the cost of a multiple hospital VistA-based EHR network was implemented for one tenth the price of a
commercial EHR network in another hospital network in the same state ($9 million versus $90 million for 7–8 hospitals
each). (Both VistA and the commercial system used the MUMPS database).15
Additionally, VistA has even been adapted into a Veterinary Medicine Health Information System (VMACS) at the
veterinary medical teaching hospital at UC Davis
International deployments
VistA software modules have been installed around the world, or are being considered for installation, in
healthcare institutions such as the World Health Organization,[27] and in countries such as Mexico,[25][27][35]
Samoa,[25] Finland, Jordan,[36] Germany,[37] Kenya,[27] Nigeria,[38] Egypt,[25] Malaysia, India,[39] Brazil, Pakistan,[32]
and Denmark.[40]
In September 2009, Dell Computer bought Perot Systems, the company installing VistA in Jordan (the
Hakeem project).[41]
c) Describe the Generation level of your product, based on Gartner's 2007 Criteria for the Enterprise CPR,
Published: 29 June 2007.
RESPONSE: VistA inherently exceeds the Figure 8 Gartner defined Evidence-Based Level 3 CPR16 system containing
patient-centric, electronically maintained information about an individual's health status and care, focused on tasks and
“Demonstration of M2Web". UC Davis VMTH (Veterinary Medical Hospital) (Dec 2008). http://vista.vmth.ucdavis.edu/notebook/index.
To avoid complications, especially as it relates to data ownership issues, Gartner restricts the scope of a CPR system to a single organization; and, the
key Gartner findings were:
1. Clinical decision support is the single most important CPR capability to assist in the avoidance of medical errors.
2. Over time, the CDS system must be able to interact seamlessly with all other CPR components.
15
16
WORKING DRAFT
3/21/2016 6:25 PM, Page 27
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
events directly related to patient care and optimized for use by clinicians. Out of the box, VistA can meet DOD’s MEDICS
EHRS/VISTA, legal and administrative requirements for the clinical process. An MEDICS EHRS/VistA CPR system is
composed of 10 integrated —— not interfaced —— core capabilities: clinical systems management, interoperability,
clinical data repository, Controlled Medical Vocabulary, clinical workflow, clinical decision support, clinical documentation
and data capture, clinical display (including clinician dashboards), clinical order management (including computer-based
physician order entry), and knowledge management; where, the CPR is also be able to adequately meet the varying
needs of all of the MHS care venues, as well as the wide array of clinician types.
1074
1075
1076
1077
1078
1079
1080
1081
1082
Figure 8: Gartner Level 3 Evidence Based Medicine (EBM) CPR System Criteria
1083
1084
3.
The CDS rule engine must be coupled with an adequate notification system to ensure that critical decisions are made available to caregivers as soon
as possible.
WORKING DRAFT
3/21/2016 6:25 PM, Page 28
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
As listed in Table 1, “out-of-the-box” MEDICS EHRS/VistA can deliver a Gartner Level 4+ advanced system that provides
substantial functionality for nurses, physicians, pharmacists, laboratory and imaging technicians. MEDICS EHRS/VistA plus
the iEHR Enterprise Service Bus (ESB) / SOA Suite, Virtual Patient Record and RLUS-fronted federated Virtual DataRepositories will have decision support, workflow capabilities and tools that permit the DOD MHS to more easily bring EBM to
the point of care; where, this out-of-the-box Level 4 MEDICS EHRS/VistA core CPS platform is the perfect foundation to
evolve the MHS to a full Level 5 CPS enterprise.
WORKING DRAFT
3/21/2016 6:25 PM, Page 29
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
Generation 1 Gartner's 2007 CPR Clinical Decision Support Criteria

None.

Basic rule capability for a limited set of data items (for example, drug-drug interactions and drug allergies).
1.
CDS can operate in both a real-time and a near-real-time manner and provides feedback to users at the earliest possible time
(for example, an alert for a drug-drug conflict before the order is actually entered).
CDS rules are based on normalized concepts represented in the CMV.
CDS toolset supports both vendor and client creation and maintenance of rules.
It is possible for a CDS rule to include a pointer to relevant knowledge management supporting content.
Supports full Boolean logic rule expressions.
The output of one rule can trigger the evaluation of a subsequent set of rules.
"Proactive" alerts (for example support, "Your patient on gentamicin now has worsening renal function. Do you want to lower
dose?").
Supports basic rule editing and management functions (for example, find all rules that deal with hip fractures).
Supports at least minimal interactions with the other CPR core capabilities, especially CMV, workflow, order entry and clinical
documentation.
Other CPR components (for example, workflow and order entry) can trigger evaluation of CDS rules.
Has a variety of notification options (for example, paging, e-mail and creating an item to be viewed by any person who reviews
that patient's clinical results display).
Ability to create time-based alerts.
3 Ability to escalate alerts if the original notification is not acknowledged in a specified
time period.
Generation 3 Patient status indicators (for example, "at risk for renal failure") can be created and then used in CDS functions.
Logging and auditing tracks the execution of rules and the resulting decision results.
Generation 2 Gartner's 2007 CPR Clinical Decision Support Criteria
Generation 3 Gartner's 2007 CPR Clinical Decision Support Criteria
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Generation 4 Gartner's 2007 CPR Clinical Decision Support Criteria
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
There must be an architecturally distinct CDS system rule engine.
The rule engine must be capable of dealing with a variety of rule types, including Boolean logic, set theory and fuzzy logic
algorithms.
Ability to handle all decision support functions needed for clinical, operational and financial activities.
CDS rules use a standardized syntax for all rules executing on the CPR rule engine.
Able to fully participate in clinical care protocols, including actively monitoring all relevant data input streams.
All data in rules and messages must be normalized by interaction with a CMV vocabulary server (VOSER).
Supports complete rule-management capabilities for the creation, indexing, testing and maintenance of rules.
Supports a full suite of alerting and notification capabilities.
Ability to perform clinical simulation functions.
Must provide basic integrity-checking capabilities to ensure that a given version of the institution’s rule set is logically consistent.
Has basic capabilities to support the import of new rules from external sources.
Rules tailoring takes into account all of the patient's active diagnoses and problems, the primary practitioner caring for the
patient, and all treatment protocols currently active for the patient.
All decisions made by the CDS system must be logged and available for analysis to support clinical quality assurance,
continuous process improvement and the development of new rules.
Sufficient power to provide sub-second response times despite the existence of a large number (thousands) of rules.
Existence of "wizards" and libraries to assist nontechnical staff in the design of new rules.
Generation 5 Gartner's 2007 CPR Clinical Decision Support Criteria
1.
2.
3.
4.
5.
6.
7.
CDS functions are fully integrated with all other CPR capabilities.
Single unified management environment for all CDO decision support capabilities.
Support for artificial intelligence applications when needed and appropriate.
Supports customization of clinical rules based on any relevant set of clinical parameters, including information on the capabilities
and limitations of the particular CDO where the patient is being treated.
Rules can be imported from an external authority, with the only manual step being the evaluation of the rule by whatever group is
designated to approve changes in clinical practice.
Robust facilities to manage the current rule set and ensure the logical integrity and consistency of the currently operating set of
rules.
Potential to extend clinical decision support beyond the boundaries of the institution when appropriate.
Table 1 Gartner's 2007 CPR Generation Clinical Decision Support Criteria
WORKING DRAFT
3/21/2016 6:25 PM, Page 30
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
3.3 Test of open-source software
Response: The recommended open-source MEDICS EHRS/VistA will be a flexible system that supports multiple test
methodologies. DOD can implements a complete spectrum of test methodologies that support development and
maintenance of a complex EHRS system, including developer unit test, functional system test, interoperability testing,
performance testing, 508 accessibility testing, DOD 8500.2 IA and system stress testing, many of these can first be
done transparently at OSEHRA for minimum cost and maximum effectiveness.
a) Provide / describe any empirical test evidence that your EHRS performs as expected in the intended user
or similar environment. Describe the scalability of your EHRS.
Response: The production implementation of VistA at VA’s scale, across more than 1500 facilities and more than 6
million patients, achieving high quality health care outcomes and exceptional system reliability, demonstrates the
ability of VistA to perform in DoD’s intended user environment.
b) Describe your capability to support an Agile testing process that requires early inclusion of users and
Government technical specialist operating in a team to manage and report on development / integration /
testing activities in two-week sprints. What program(s) have you supported in this capacity and what were
the associated products(s) / capability?
Response: Most VA software development, as well as contracted software development, is performed according to
Agile processes. Core VistA development and significant new programs such as the hi2 Health Management
Platform, My HealtheVet, and the Connected in Health platform are all developed using sprint-based Agile
processes, including test at the developer and system level.
Agile development requires flexible test tools that can be rapidly configured for the tasks in each sprint. VA has
developed two such tools for use in VistA development and deployment: an automated system test platform and a
tool for system data analysis.
A platform for automated system-level functional test allows developers and testers to rapidly script functional tests
that focus on the features under test provides a powerful tool for Agile test practices. Test scripts can be written in a
simple scripting language or they can be automatically generated by recording user actions during test scenarios. All
test scripts, custom and auto-generated, may be run as fully automated regression tests.
Analyzing and testing the MEDICS EHRS/VistA involves more than the checking of code; much of the power of VistA
is captured in system data: templates, menu options, data dictionaries, file structures, etc. VA engaged the open
source community to develop a tool that analyzes system data and compares two VistA instances (for example, a
“gold” version vs. a unit under test), allowing developers to rapidly verify that any changes to system data are
appropriate.
Both test tools are available via OSEHRA.
WORKING DRAFT
3/21/2016 6:25 PM, Page 31
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
3.4 Integration
Describe your approach to integrating your EHRS into the DoD environment as described in paragraph 1.
Figure 9 RLUS is used to Integrate with Legacy Systems’ Data17
RESPONSE: The recommended solution illustrated directly above and detailed-out directly below should be fully
integrated and use both legacy VA/DoD systems, user interfaces and the MEDICS EHRS/VISTA system, as a
whole, including the IOC and FOC JSR 286 standard portal/portlet UX frameworks with WSRP (OASIS Web
Service for Remote Portlets). All data will be written back to legacy system and MEDICS EHRS/VISTA IOC and
FOC repositories using RLUS, Mirth and Level7 SSG with standard data XML content formats, based on the
canonical information and terminology models and transformations appropriate to the respective repositories. The
3M-HDD will manage the data semantics/ quality among systems.
17
From Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/21/2016 6:25 PM, Page 32
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
Clinical
Template
Repository
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
Figure 10 User Experience (UX) is Thoroughly Integrated into MEDICS EHRS/VISTA and Legacy using
RLUS18
The following annotation applies to the figure above:
[1]
User Experience (UX) Standard XML Form Language (XForms) Generation
[2]
Multiple Display Platforms
[3]
Clinician and Patient Sourced Data Updates
[4]
Use of Common Information Interoperability Templates and Value Sets
[5a]
Communication between UX and Care Coordination Capability
[5b]
Use of Analytics Capability within UX
[6]
Coordination with Care Record Capability
[7]
Coordination with Health Concern Tracking Capability
[8]
Coordination with Care Plan Management Capability
[9a]
Interaction between Care Record Capability and Care Plan Management Capability
[9b]
Interaction between Care Record Capability and Health Concern Tracking Capability
[9c]
Interaction between Care Plan Management and Health Concern Tracking Capabilities
[10a]
Data Management via Retrieve Locate and Update Service (RLUS)
[10b]
Communication with Legacy Systems via RLUS
[10c]
Communication with MEDICS EHRS/VISTA Integrated Clinical Data Repository via RLUS
[11a]
Use of Enterprise Data Warehouse by Analytics Capability
[11b]
Real-time Population of Enterprise Data Warehouse (EDW) by RLUS
[12a]
Inputs and Outputs of Clinical Decision Support (CDS) Capability
[12b]
Generation of Alerts Reminders and Notifications by CDS Capability
[12c]
Order Management Capability Interactions with the Care Coordination Capability
18
From Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/21/2016 6:25 PM, Page 33
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1225
1226
1227
1228
1229
1230
1231
1232
1233
Figure 11: Proposed Systems Engineering / Integration Approach19
3.5 Transition
a)
b)
c)
1234
1235
1236
Describe your approach to transitioning from a legacy EHRS to a new core and / or EHRS.
Describe your approach to a typical deployment and implementation of the EHRS, including key activities, tasks, timelines,
resources, and dependencies.
Describe your approach to the change management process in implementing an EHRS.
Figure 12 Proposed Transition-Strategy for MEDICS EHRS Linkage to Legacy Systems20
19
20
Adapted from Technical Specification Summary available at www.tricare.mil/iEHR
Adapted from Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/21/2016 6:25 PM, Page 34
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
RESPONSE: The iEHR initiative plans to move to a common Janus open-source GUI, common services, and
common information model and terminology, which can operate with legacy systems. RLUS boxes represent
potential gateways on the security boundaries of each system / organization. The common GUI and common
services may reside in some new joint security domain, where data stores are federated across 6–8 regional DISA
data centers. There will likely be local data caches to meet performance requirements. Using the RLUS and HDD,
the MEDICS EHRS/VISTA initiative will allow the retirement of the legacy Clinical Data Repository/Health Data
Repository (CHDR), Bidirectional Health Information Exchange (BHIE), and the Federal Health Information
Exchange (FHIE) information-sharing systems, and will ultimately allow appropriate computable information sharing
with VA and external partners, via VLER .
Most legacy applications cannot be just turned off immediately. It is possible with current technology to replace the
front-end aspect of most legacy applications. Initially, legacy inclusion is essential with a phased sunset or
refactoring of legacy applications either from a front-facing GUI and backend data store aspect. There will be a plan
for rolling out new capabilities that replace or repurpose legacy capabilities with some phased approach to access
to historical data and intermingling of capabilities during the phase-in period. In some cases, there is benefit to
moving to a commercial application and replacing its front-face because the application does not present a unified
MEDICS EHRS/VISTA view to the user. As commercial applications begin to be included, work with those vendors
must be provided in tandem to provide a unified “style” to the application front end, within the iEHR / MEDICS
EHRS presentation GUI.
The advantage of the RLUS + HDD approach is that it decouples complex implementation schemas, allowing the
DOD to choose when and how they upgrade their legacy systems to the MEDICS EHRS/VISTA common GUI,
common services, common information structure, and common terminology approach. This is also practical path to
DOD-VA integration, resulting in a single logical Virtual Patient Record (VPR) for each patient. The approach is
based on freely available national and international standards (e.g., SNOMED-CT, LOINC, RxNorm) and allows the
reuse and repurposing of existing components, supporting the independent transition of each agency’s healthcare
IT. Common tools can centrally manage the accumulation of knowledge within the information and terminology
models and services. As the iEHR / MEDICS EHRS/VISTA Program (s) move forward, the need for translation
services is diminished for partners who elect to implement HDD access21 natively in their products. Note that there
is always a need to harmonize different versions of terminologies, code sets, and value sets, which evolve over
time.
Currently, the agency systems, their existing and required information exchanges, and a high-level specification of
the necessary MEDICS EHRS/VISTA system functions, capabilities, and services are known. Simulations and
appropriate prototypes to add fidelity to the interoperability specifications, performance parameters, capacity
planning, and independent government cost estimates will need to be done. This must be done for the iEHR /
EHRS final state, as well as the need to simulate and appropriately prototype the legacy systems transition phases
from the as-is state through a sequence of transition states to the MEDICS EHRS/VISTA objective state
The MEDICS EHRS/VistA architecture can be designed to comply with the DOD and VA information security
requirements and take into account the allowable ports and protocols allowed to transition across the Information
Assurance (IA) boundaries. Additionally; as DOD reacts to different IA threats, stricter Information Operations
Condition (INFOCON) controls and restrictions will be imposed at the DOD IA boundary. At the highest INFOCON
level, there is a possibility that all communications through the DOD IA boundary will be curtailed. The MEDICS
3M, the U.S. Department of Defense (DoD) and the U.S. Department of Veterans Affairs (VA) jointly made HDD Access, the public version of the 3M™
Healthcare Data Dictionary (HDD). Deployed since 1996, the HDD is helping 3M customers manage terminologies used in healthcare and can be
integrated with other applications in a seamless manner.
21
WORKING DRAFT
3/21/2016 6:25 PM, Page 35
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
EHRS/VistA integration architecture design must take this into account, as a part of the Continuity of Operation Plan
(COOP), with local Virtual Patient Record caches.
3.6 Network and Security Architecture
a) Describe your approach to network and security solutions. The Government intends to use a dedicated
health network that will run on the Defense Information Systems Network (DISN) as a logical network as
part of the Non-classified Internet Protocol Router Network (NIPRnet). The Government will be responsible
for the network from the datacenters down to the end user devices.
b) Describe your approach to disconnected operations. How does your EHRS support continued operations in
a disconnected (low (256KB) or no bandwidth) mode?
c) Describe your approach to access control. Is it role-based, attribute-based, or both?
Response: VistA integrates seamlessly with network security measures implemented by the deploying enterprise.
VA, for example, segregates VistA-related network traffic using industry-standard MPLS services to implement
regional VPNs with inter-regional routing. Network boundary protection and monitoring occurs at Trusted Internet
Connections (per Department of Homeland Security policy) and a tightly controlled business process governs
network access. No changes are required to VistA software in order to gain the benefit of robust network security
practices.
3.7 Architecture/Systems Engineering (A/SE)
a) Describe your approach to software, languages used, hardware, and systems architectures that will support
the implementation of an EHRS and its integration into the DoD environment.
Response: The recommended MEDICS EHRS/VistA core database (fileman) is written in MUMPS and has
Service wrappers, which support Java or C++ or C# .net or Delphi calls. This strategy supports the flexibility
to integrate “Best-of-class” component integration. MEDICS EHRS/VistA can be run on a proprietary
Windows/Cache’ environment or an open-source Linux/GT.M environment; where, both environments have
had extensive use and testing. From a hardware perspective, the MEDICS EHRS/VistA can run on the
DOD commodity blade processors running load-managed Virtual-Machines to provide the best costperformance at DISA centers, regional sites and local or deployed systems. The system architecture starts
with the Figure 4 VistA Core Expanded running on the Windows/Cache’ or Linux/GT.M environment within
the Figure 2 n-tiered Open-Source MEDICS EHRS/VISTA Conceptual Architecture federated across DISA
centers and MHS Regional sites and hospitals. Database shadowing will be used to put local data within
the MHS Clinical Data Repository (CDR) and/or iEHR enterprise data store.
b) Describe any hardware or software requirements that are necessary to implement your EHRS (e.g.,
databases, severs, bandwidth, etc.).
RESPONSE: The proposed MEDICS EHRS/VistA core will integrate into the IEHR ESB/SOA Suite, as
shown in Figure 2 n-tiered Open-Source MEDICS EHRS/VISTA Conceptual Architecture.
c) Describe your approach to data storage solutions. The Government is interested in your assessment of
using multiple regional data centers in a federated architecture, with multiple virtualization sites located
closer to the care delivery organizations (CDOs).
Response: The key to practical federation is having an HL7/OMG specified Standard RLUS (Retrieve,
Locate, Update Service) API façade for all databases, as is shown in Figure 11. Multiple regional data
centers in a federated architecture, with multiple virtualization sites located closer to the care delivery
organizations (CDOs) is essential to cost-performance tuning. Additionally, the Virtual Patient Record
(VPR), shown in Figure 2, is an additional cache, which is critical to managing the cost-performance and
disaster capability recovery of the Figure 2 architecture.
WORKING DRAFT
3/21/2016 6:25 PM, Page 36
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
d) Describe your approach to disaster recovery.
 Response: The recommended MEDICS EHRS/VistA core supports LCS (Local Cached Storage) aka VPR
for dynamic performance-tuning and a graceful COOP (Continuity-of-Operations) in the event connectivity
is lost to regional DISA centers.
 Additionally, the recommended solution supports the TMIP (Theater Medical Information Program) data
integrity approach to a disconnected (no network available) mode. In detached operations, data is precached and when connectivity is established, standard store-and-forward and standard databasesynchronization techniques are used. For mobile displays, secure memory-less HTML-5 is used. The
recommended RLUS, UX framework and (ideally open-source) HSP components make porting capabilities
to multiple-types of mobile or detached-platforms simpler and less costly.
3.8 Identity Management
a) Describe your approach to using an external identity management system in your EHRS. The Government
intends to use the Defense Manpower Data Center (DMDC) who provides an external identity management
service and a unique electronic data interchange personal identifier (EDIPI).
Response: The recommended MEDICS EHRS/VistA architecture treats DMDC as a service provider,
augmented with disaster recovery and detached operations caching capabilities.
b) Describe your approach to identity management and access control for individuals who have more than
one role (patient, provider, dependent, etc.).
Response: As in the VA, DOD EHRS/VistA Identity Access Management (IAM) services should separate the
user identity, established through various electronic measures (PIV, CAC, and Federation Partners - including
DS22 Logon), from management of roles. When a user authenticates, the user’s credentials are mapped to
their roles. In this manner, support is provided for both coarse and fine grain access controls enforceable from
various points in the architecture. Services for Role Provisioning, Role Attribute Query, and Role Enforcement
are designed with open standards such as LDAP, SAML, XACML, SPML and others to meet the highest
interoperability goals. For example, AcS Specialized Access Control (SAC) service can provide fine-grained
access control for applications and services like a doctor’s attempt to self-prescribe medication.
For individuals who have multiple roles, the role or personal selection is tied to the authenticated session or
queried through the distributed system by the application being accessed. User menus, keys, and file
access are assigned and enforced on an individual user and role basis.
c) Describe your approach to Single Sign On capability and the ability to extend it to products that might be
added in the future.
Response: The recommended MEDICS EHRS/VistA approach for the IAM (Identity Access Management)
internal Single Sign-On is for the UX component be the entry portal to support both legacy and new application
development efforts. Legacy applications can be SSO-enabled through the use of the Identity Access
Management (IAM) Single Sign-On Internal (SSOi) service. The key to the IAM SSOi solution is the flexibility
to support both existing and new applications with varying degrees of integration to support the specific
business need. The IAM SSOi service supports certificate-based authentication including VA PIV and DOD
CAC and is partnered with the Specialized Access Control (SAC) service to provide an end-to-end security
solution.
The Department of Defense (DoD) Self-Service Access Center (DS Access) provides a means for a sponsor (family member with an affiliation to the
Department of Defense) to request a DoD Self-Service Logon (DS Logon) for their own use and for those family members who are eligible to receive one.
22
WORKING DRAFT
3/21/2016 6:25 PM, Page 37
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
d) Describe your approach to Context Management capability and the ability to extend it to products that might
be added in the future.
Response: The recommended MEDICS EHRS/VistA approach for context management is for the UX
component to be the entry portal to support both legacy and new application development efforts. In the short
term, MEDICS EHRS/Vista might use the Sentillion patient context management in a centralized and/or
decentralized manner. Via the UX framework, applications are integrated with the context manager in order to
set the patient context; on the backend, the context manager integrates with the patient identity management to
verify and validate the identity of the patient context and set all other relative identifiers (i.e. EDIPI, ICN, VistA
IEN, CHCS IEN) in context. As we integrate into iEHR, context Management should include session
management and the development of SOA based services that will streamline integration with new COTS
products.
3.9 Data
a) Describe your data strategy, including storage, persistence, data model, architecture, security, distribution,
transformation, and presentation; and how you will provide standardized and normalized data sharing
between the DoD and VA using with the 3M HDD.
Response: The recommended approach to run-time configurable reporting is to use the new HL7
Consolidated CDA23 and HL7 Fast Healthcare Information Resource (FHIR)24 to define semantically
interoperable documents, which can be exchanged or printed.
The VistA data model is open and in the open source community. The Data Architecture Repository allows
searching of data fields and allows developers to maintain data integrity; honoring parent/child
relationships, for example. Descriptions of the VistA data model can be found under the Architecture link at
http://architecture.osehra.org.
VA uses ICD-9 (with work underway to move to ICD-10), CPT, DRG, DSM, HCPCS, CDT, NDC, LOINC
and other terminologies for the coding of medical records and data fields. SNOMED for problem list is
currently in beta testing with CPRS 29; full deployment will occur in 2013. This accelerates DOD’s ability to
meet Meaningful Use Stage 2 standards.
The proposed rule for Meaningful Use Stage 2 and its companion rule for standards and certification criteria for EHR technology promote
the use of single standards for communicating information in certain transactions. The proposed rule establishes the Consolidated Clinical
Document Architecture (CDA) as the single standard for communicating the summary of care. The Consolidated CDA is based on
components of two standard formats that were previously required for certified EHRs: the Continuity of Care Record (CCR) and the
Continuity of Care Document (CCD). This format was chosen as the standard for communicating the summary of care since it can
accommodate all data elements that CMS proposes providers give their patients after office visits. Health Level 7 (HL7), an accredited
standards development organization, created a single implementation guide for the Consolidated CDA, which was released in December
2011 in an effort to reduce ambiguity and eliminate conflicts in documentation; where, the Consolidated CDA solution encompasses a
library of reusable CDA templates, setting the stage for streamlined development and quicker implementation. The templates allow for
incremental interoperability and easier machine-to-machine communication, thereby facilitating the transfer and storage of more data.
23
Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "Resources" that represent granular clinical
concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for
a range of interoperability problems. The simple direct definitions of the resources are based on thorough requirements gathering, formal
analysis and extensive cross-mapping to other relevant standards. A workflow management layer provides support for designing,
procuring, and integrating solutions. Technically, FHIR is designed for the web; the resources are based on simple XML, with an httpbased RESTful protocol where each resource has a predictable URL; where possible, open internet standards are used for data
representation.
24
WORKING DRAFT
3/21/2016 6:25 PM, Page 38
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
VA is committed to making VistA compatible with the HDD. This will allow VistA systems to access clinical
data stored in the DoD CDR, and to provide data in that format for use by the CDR. Note that VA has
migrated data from VistA many times, for use in products like Blind Rehabilitation, Spinal Cord Injury &
Disorder Outcomes, and the Central Data Warehouse (CDW).
VistA is fully compliant with HIPAA Privacy and Security standards. Patient records can be designated as
sensitive; access to such records triggers a warning message alerting the user that they are about to
access a sensitive record, if the user proceeds with the access, the system creates an audit record that
records puts the requesting user on a list to be checked by the facility ISO. Access via VistA is via rolebased menu trees with sensitive options locked with security keys to grant permissions to personnel by
minimum necessary standards.
The VA/hi2 program has adopted the Virtual Patient Record (VPR) approach to create temporary data
caches that are highly indexed, standardized, and optimized for a defined need. To support the Health
Management Platform, the VPR is a JSON store that meets HITSP standards for C83 document format and
is indexed to optimally support the Solr search engine. The VPR is populated from all VistA databases and
can accept data from multiple other sources.
VA’s CDW supports enterprise-wide analytics. Individual VistA instances update regional data warehouses;
the regional data stores are aggregated in the CDW. Data is normalized in the CDW and the warehouse is
optimized for analytic use; this database design facilitates the development and support of multiple data
marts that can be developed quickly to meet the needs of the end users.
Should DoD adopt VistA as its core EHRS, data sharing between VA and DoD medical facilities can be
easily accomplished via the enterprise architecture employed by VA. Each MTF/VAMC has rapid access to
patient data in its local data store; patient data stored at non-local facilities can be located via the MVI.
While patient data can be shared via electronic exchange of Blue Button or continuity of care documents,
perhaps via eHealth Exchange, a database-level sharing of data is far superior. Sharing of data for
analytics can be accomplished by federating VA’s CDW and DoD data stores such as the CDR and the Air
Force Health Services Data Warehouse.
b) Describe your data management approach to address scale, data format (structured, unstructured, multimedia, and extensibility), consistency, quality and quality management, redundancy, availability, patient
safety, and operational performance objectives.
Response: As stated in 3.9.a, the recommended approach to run-time configurable reporting is to use the
new HL7 Consolidated CDA and HL7 Fast Healthcare Information Resource (FHIR) to define semantically
interoperable documents, which can be exchanged or printed.
VistA already handles a wide range of document types. In addition to storing and managing radiology
images, MRIs, and other clinical images, the VistA Imaging system handles video, graphics, audio, and
scanned images.
All scanned documents and images have a required Document/Image Type when stored in VistA.
Examples of “types” include: Advance Directive, Consent, Discharge Summary, Image, Procedure/Record
Report, etc. These Document/Image Types are then associated with specific classes of images, such as
Clinical, Clinical/Administrative, and Administrative. Uses can be given specific roles and Security Keys so
that they will only see ADMINISTRATIVE “types” and/or CLINICAL “types”. The User can then create
WORKING DRAFT
3/21/2016 6:25 PM, Page 39
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
Image List ‘Filters’ to access scanned documents and images specific to Document/Index Type, Specialty,
Procedure/Event, Class, Date/time etc.
VistA/CPRS systems are configured for enterprise-wide quality monitoring and improvement that align with
VA health care mission. Current VA activities that address data architecture and storage (e.g., the
Corporate Data Warehouse) and the requirements of Meaningful Use (e.g., electronic Clinical Quality
Measures), as well as the future presentation layer for clinicians (e.g., Health Management Platform) will
build upon that solid foundation to expand VistA/CPRS’ capability to improvement clinical management in
real time.
As VA works towards Meaningful Use certification for VistA, they are developing the ability to report Clinical
Quality Measures. The hi2 program is developing tools to support specific CQMs (Congestive Health
Failure and Antibiotic Stewardship) and will expand to other Quality Measures as the tools mature. Also, VA
plans to integrate existing open source tools (such as Pop Health) with VistA, CDW and other data sources
to facilitate clinical quality reporting.
c) Describe your data management approach to include the use of legacy data and data stores, and how data
will be managed across system components (e.g., Pharmacy, Lab, etc.).
Response: VistA’s data model makes all system and patient data available to applications. No export,
import, or explicit exchange of data between system components such as Pharmacy, Lab, etc. is required.
This level of integration allows workflow, orders, and decision support to operate with a complete view of
patient data, decreasing opportunities for errors that may impact quality of care and patient safety.
Handling legacy data, specifically integrating CDR data with MEDICS EHRS/VistA instances, is handled in
two phases. In the first phase, legacy data resides in CDR and is extracted and displayed with VistA data
using the Janus user interface. Note that in this scenario, all VA data and all new (post-DoD deployment of
VistA) is handled in VistA; only legacy DoD data in CDR requires integration in the clinical display.
In the second phase, CDR data is extracted and loaded into one or more VistA databases. Once loaded,
the legacy data is available to any interconnected MEDICS EHRS/VistA system and is thus available
throughout the DoD network and the VA network (providing appropriate network connectivity and RLUS
integration is implemented).
d) Describe the ability of your EHRS to support data operations offline (if appropriate), to include data
availability, replication of data between servers, resynchronization of data, automatic conflict resolution for
concurrency issues, and modification of the data.
Response: Mobile Electronic Documentation (MED) provides staff in non-connected environments the
ability to view a medical record, document, and place orders when connectivity is not possible; data is
synchronized when connectivity is restored. Both VistA and Master Veteran Index (MVI) support this
capability; if the enterprise MVI is not available, local identifiers are created and used at the disconnected
VistA site until the centralized system is available. When the MVI is again reachable, all identities and
identifiers are reconciled and any anomalies are resolved.
e) Describe how your EHRS would support data federation across repositories external to the boundaries of
your EHRS, and how you would approach data migration from the Clinical Data Repository (CDR) to your
EHRS data store, and federation of your EHRS data store with VA and other systems. How would you
account for data volume and performance requirements?
WORKING DRAFT
3/21/2016 6:25 PM, Page 40
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
Response: The proposed MEDICS EHRS/VistA inherently supports continued support of legacy systems
during the migration of data, as is shown in Figure 5 Proposed MEDICS EHRS/VISTA Logical System
Architecture and Figure 9 RLUS is used to Integrate with Legacy Systems’ Data.
It is worth noting that VA’s enterprise-wide VistA implementation is, in effect, a federation of individual VistA
instances, each with its own local data store. Patient data that is stored in multiple locations, or patient data
that must be accessed from a remote location, can be located via the MVI, which has a record of the sites
at which patients receive care.
Should DoD adopt VistA as its core EHRS, all post-VistA-deployment patient data would be in a common
system and both VA and DoD data could be accessed in the same way that VA accesses data today.
Legacy CDR data can be handled in two phases.
First, while the legacy data resides in the CDR, the Janus GUI is used to retrieve data from the CDR and
from VistA and present it together. It is transparent to the clinician whether the patient data is coming solely
from VistA, solely from the CDR, or some combination of the two. Unlike the current deployment in joint VADoD sites such as North Chicago, where clinicians must use either VistA or AHLTA to enter orders, notes
and other clinical encounter interactions, clinicians would use VistA as the sole EHR system for all patients.
Second, data from the CDR is extracted and loaded into one or more VistA databases. It is possible and
desirable to load patient data into VistA instances where patients actually receive care. When this data
migration is completed, all data is stored in VistA systems and VistA can be used as the sole clinicianfacing system.
f) Describe your approach to addressing continued support of legacy systems during the migration of data.
Response: The proposed MEDICS EHRS/VistA inherently supports continued support of legacy systems
during the migration of data, as is shown in Figure 5 Proposed MEDICS EHRS/VISTA Logical System
Architecture and Figure 9 RLUS is used to Integrate with Legacy Systems’ Data.
Once DoD facilities are up and running with VistA, it is not necessary to maintain support of legacy systems.
Since VistA can be brought up at each site independently, each legacy system can be shut down independently
when the local facility is comfortable that the VistA instance is fully operational and that staff are ready. There is
no need to coordinate a network-wide switchover.
Describe either the use of a federated data model that serves as the single authority for patient data, or a single
physical data repository that provides global access, and the expected performance of your recommended
EHRS.
The VistA database serves as the single authority for patient data. Because patient data can be accessed
remotely, and the MVI maintains the local of patient data, it is not necessary to build a single, central data
repository in order to provide global access. The performance of the EHRS is, for the vast majority of
interactions, determined by the performance of the local VistA instance and not a clinician concern, even at
VA’s largest installations.
g) Describe either the use of a federated data model that serves as the single authority for patient data, or a
single physical data repository that provides global access, and the expected performance of your
recommended EHRS.
WORKING DRAFT
3/21/2016 6:25 PM, Page 41
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
Response: The proposed MEDICS EHRS/VistA inherently supports both federated instances of MEDICS
EHRS/VistA at regional and local, including detached, environments and shadow database transactions to a
centralized “cloud-based” “big-data” NOSQL Central Data Warehouse (CDW). Local VistA database instances
support high performance Operational Data Store needs and the VistA NOSQL CDW supports CDS analytics
and reporting.
VA is an active participant in the eHealth Exchange effort and has developed VA connectors to enable
exchange of VA data via Direct and Connect.
VA has developed code to handle the extraction of patient data from VistA and the formatting of exchangeable
health summary documents. This code has been wrapped as a web service (as part of the MDWS suite) and is
used by the MyHealtheVet platform to build a C32 Continuity of Care Document version of the Blue Button
personal health record.
VA also has a pilot project that has implemented the transmission of medical images (from VistA imaging) to
external providers using Direct protocols. We expect that the ability to exchange Blue Button files, including
images, via Direct to be launched in production later this year.
h) Describe your approach to using the eHealth Exchange from the Office of the National Coordinator (ONC),
Health and Human Services (HHS), and the Connect protocol and the Direct protocol to exchange data
with the private sector.
Response: The proposed MEDICS EHRS/VistA proposes the Figure 2 n-tiered Open-Source MEDICS
EHRS/VISTA Conceptual Architecture, This architecture incorporates the DOD and VA VLER capabilities;
where, VLER uses the eHealth Exchange from the Office of the National Coordinator (ONC), Health and
Human Services (HHS), and the Connect protocol and the Direct protocol to exchange data with the private
sector. The more recent secure SMTP Direct protocol can be easily added within VLER.
3.12 User Interface
Describe your approach for the system user interface, to include, but not limited to, the ability to support the user
interface configuration and customization. Describe your approach to implementing a third-party user interface with
the EHRS.
Response: Building on the recent establishment of Janus as an open-source Graphical User Interface (GUI), we25
propose the adoption of a flexible, open GUI framework that will support a number of complementary modular,
interchangeable and reusable interfaces. Due to the complexity of user-based needs and specialties that requires a
flexible interface design, this framework will help establish best-practice designs but provide flexibility in allowing
users to customize the modules most appropriate for their needs within a widget-based framework.
Much like a smart phone or tablet’s interface allows for a great deal of customization of buttons or widgets relevant
to the end user, so must an EHR establish the same level of usability amongst both patients and providers.
HealthBoard is one example of a new open-source GUI framework available through OSEHRA. Originally
developed for the Patient Centered Medical Home, HealthBoard can complement Janus by providing additional
modules. An open GUI framework would support such an exchange of interface designs and modules. The
25
CHRISTOPHER GORANSON l THE NEW SCHOOL. Director, Parsons Institute for Information Mapping, 68 5th Avenue,
Suite 200, New York, NY 10011
WORKING DRAFT
3/21/2016 6:25 PM, Page 42
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1587
1588
framework would also be capable of growing to support existing MEDICS system architecture requirements while
allowing flexibility in their appearance.
1589
1590
Figure 13 HealthBoard button homepage example.
1591
1592
Figure 14 HealthBoard widget view from the patient’s perspective.
WORKING DRAFT
3/21/2016 6:25 PM, Page 43
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1593
1594
1595
1596
1597
1598
Figure 15 HealthBoard’s widget example used in a provider’s portal.
Best practices can ensure that the lookout and feel, regardless of the user’s preferences are maintained in a
meaningful and easy-to-use manner by the patient or provider.
WORKING DRAFT
3/21/2016 6:25 PM, Page 44
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
A modular design allows for the adoption of those features that are most needed in a dynamic interface.
3.13 Workflow
Describe your approach to configurability of the workflow through a user interface, modify and cancel the workflow
on the fly, create reports, and operate in an offline environment.
Response: The proposed MEDICS EHRS/VistA integrated with iEHR’s IBM ESB / SOA Suite and the
open-source Druels provide the Business Logic integration Platform which provides a unified and integrated
platform for Rules, Workflow and Event Processing, which can be configured through a UX portlet GUI.
The recommended approach to run-time configurable reporting is to use the new HL7 Consolidated CDA26
and HL7 Fast Healthcare Information Resource (FHIR)27 to define semantically interoperable documents,
which can be exchanged or printed.
The proposed rule for Meaningful Use Stage 2 and its companion rule for standards and certification criteria for EHR technology promote
the use of single standards for communicating information in certain transactions. The proposed rule establishes the Consolidated Clinical
Document Architecture (CDA) as the single standard for communicating the summary of care. The Consolidated CDA is based on
components of two standard formats that were previously required for certified EHRs: the Continuity of Care Record (CCR) and the
Continuity of Care Document (CCD). This format was chosen as the standard for communicating the summary of care since it can
accommodate all data elements that CMS proposes providers give their patients after office visits. Health Level 7 (HL7), an accredited
standards development organization, created a single implementation guide for the Consolidated CDA, which was released in December
2011 in an effort to reduce ambiguity and eliminate conflicts in documentation; where, the Consolidated CDA solution encompasses a
library of reusable CDA templates, setting the stage for streamlined development and quicker implementation. The templates allow for
incremental interoperability and easier machine-to-machine communication, thereby facilitating the transfer and storage of more data.
26
Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "Resources" that represent granular clinical
concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for
a range of interoperability problems. The simple direct definitions of the resources are based on thorough requirements gathering, formal
analysis and extensive cross-mapping to other relevant standards. A workflow management layer provides support for designing,
procuring, and integrating solutions. Technically, FHIR is designed for the web; the resources are based on simple XML, with an httpbased RESTful protocol where each resource has a predictable URL; where possible, open internet standards are used for data
representation.
27
WORKING DRAFT
3/21/2016 6:25 PM, Page 45
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
Eclipse Business Intelligence Reporting Tools (BIRT) is ideally suited to perform reporting, data
visualization and analytics across multiple components of an EHRS acting as a bolt on application. In this
specific mode BIRT could function as SOA or an ESB component. This approach addresses the
interoperability of the Best of Suite (BoS) and Best of Breed (BoB) applications. This also addresses one
aspect of a full ERHS capability of adding, upgrading, and interfacing with BoB products.
BIRT is a Java based reporting framework that allows developers to construct Data Visualizations and
Reports. The BIRT framework provides components for building report designs and a framework with
complete APIs for delivering content. These designs are stored in XML documents that easily integrated
with other applications. BIRT can source data from, web services, XML documents, JDBC sources, Excel
files, Hadoop, and Flat files. In addition to these sources BIRT provides simple points to integrate any data
source that has a Java based API, including extensible hooks to provide a customized GUI for developers.
Once data is sourced to the BIRT framework, this data can be further grouped, filtered, sorted and
displayed with a myriad of graphical components with complex charting and drill through support. In
additional BIRT has the added benefit of combining and visualization data from disparate data sources.
For example, a Doctor could be presented with a Report that contains Immunization data combined and
aggregated with Laboratory data, for a specific patient.
Using BIRT, each user’s view of conglomerate data can be automatically customized based on the user’s
locale and language preferences. BIRT provides additional customization capabilities using CSS based
style sheets, full featured parameter support, a complete scripting environment, and a complex set of
interactivity features to support client side decision making. Reports can also be exported to PDF,
PostScript, Word, XLS, PPT, HTML, paginated HTML, and Open Office formats. BIRT exporting also
provides extension points to extend this list to support addition formats.
BIRT also supports reusability by allowing common data and graphical components to be shared across
reporting artifacts. These library components are referenced by reports, meaning changes are
automatically reflected to the end user without the need to update reports.
BIRT specifically or in part addresses points 2.1, 2.3, 2.9, 2.10, 2.11, 2.12, 2.14, 2.15, 3.4, 5.2, 5.3, 5.4, 5.6
of Attachment (1) Anticipated Electronic Health Record System Objectives.
MEDICS EHRS RFI Attachment (1) – Anticipated MEDICS EHRS/VistA Objectives
The following paragraphs provide a list of anticipated objectives to be met by the DoD EHRS.
1. General Objectives
The general objectives include the following:
1. Replace the current DoD systems with an EHRS that is at least a Generation 3 EHRS, or later generation, as defined in
Gartner's “Criteria for the Enterprise CPR”, Published: 29 June 2007
2. Provide better performance than existing DoD EHRs
3. Provide longitudinal medical record for each beneficiary that is globally available across all time zones (24/7/365) and full range
of military operations
4. Improve electronic exchange of medical and patient data between the DoD and their external partners
Response: The proposed MEDICS EHRS/VistA meets or exceeds these objectives, as presented above
2. Clinical Objectives
The clinical objectives include the following:
1. Provide ability to view legacy and external data
2. Provide a configurable user interface to enable tailoring of the clinician workflow
WORKING DRAFT
3/21/2016 6:25 PM, Page 46
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
3.
4.
5.
Provide patient facing view of record, supporting data entry and secure messaging
Provide team management tools to improve efficiency and collaboration
Provide the clinician workforce with innovative and advanced tools, i.e., clinical decision support, highly integrated orders
services, and cognitive analytic capabilities
6. Provide capability to implement automated clinical practice guidelines (condition based reminders and suggested formatting
behaviors) that can be configured to Military Health System (MHS) standards and adapt to changing healthcare environments
7. Provide clinician and commander workforce with the ability to control access to segmented, privileged, very important person
(VIP) and sensitive / masked data
8. Provide a capability that operates with autonomous, self-contained medical devices
9. Provide standards-based data export to an auxiliary data warehouse / analytics-like capability to enable data mining for
identification of trends and support for medical research
10. Provide patient safety through delivery of current, complete, and appropriate patient information and evidence-based decision
support to providers to make quality decisions
11. Improve patient safety through use of analysis and monitoring of data for early detection, identification, and investigation of
hazards
12. Provide a reporting functionality for visibility and transparency of safety events throughout the system for improved patient
outcomes
13. Provide / identify ancillary care processes that contribute to patient safety
14. Provide historical patient safety information to consumers / patients to build trust through a transparent system
15. Provide the capture of structured and unstructured data in a way that enables easy customization, consistent with usability
standards, of ad hoc reports and generation of template reports
16. Support Patient Centered Medical Home
Response: The proposed MEDICS EHRS/VistA meets or exceeds these objectives, as presented above
3. Business Objectives
The business objectives include the following:
1) Support 70,000 total clinicians and a maximum of 20,000 concurrent clinicians
2) Dramatically reduce overall costs incurred by the DoD healthcare environment
3) Provide an upgrade strategy with minimal cost and disruption to user community
4) Provide capabilities for aggregate analysis to include export of standard data elements for use by peripheral business systems
5) Provide predictable costs and performance measures such that the DoD can analyze the cost of treatment to evaluate existing
and future costs of operations
Response: The proposed MEDICS EHRS/VistA meets or exceeds these objectives, as presented above
4. Program Management Objectives
The program management objectives include the following:
1) Ensure the program has a well-defined risk management approach
2) Plan and execute a user acceptance and adoption strategy that mitigates identified adoption risks and is responsive to the
changing needs of DoD’s clinician workforce
3) Provide a transition strategy that minimizes disruption to operations
4) Provide and eventually move all inter-related components of the EHRS to the appropriate DoD sustainment activity
5) Provide a program approach that utilizes the Agile Scrum methodology to include product configuration, development,
integration, and clinical, technical, and management engagements
Response: OSEHRA will NOT bid on an RFP; rather, this RFI response provides an open-source MEDICS EHRS/VistA vision,
conceptual architecture and strategic vision for the government and its contractors to follow; in which, the Program Management
Objectives (listed above) should be achievable.
5. Technical Objectives
The technical objectives include the following:
1) Configure the EHRS to interface with medical devices and respective data
2) Deploy an EHRS that has the ability to exchange data in non-proprietary formats, using federally approved health data exchange
standards
3) Deploy an EHRS that uses an open and standards-based information / data model
4) Deploy an EHRS that has standardized and open Application Program Interfaces (APIs)
5) Deploy an EHRS whose underlying and supporting technologies are designed to support extensibility, and supports
interoperability with separately developed capabilities
WORKING DRAFT
3/21/2016 6:25 PM, Page 47
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
6)
Deploy an EHRS that supports a federated data architecture and includes federation with VA data sources and other external
data sources
7) Deploy an EHRS that maintains, and supports enhancements to, ongoing data exchange between DoD and VA, and all external
partners
8) Deploy an EHRS which is end-user platform independent, and supports use by credentialed users (clinicians and patients)
independent of location and device (e.g., mobile devices)
9) Deploy an EHRS that maintains patient context across all user-facing components
10) Deploy an EHRS that enables 100% compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA)
and with the Privacy Act of 1974 as amended
11) Deploy an EHRS that securely controls data at rest and during transmission
12) Deploy an EHRS with attribute-based access controls and an authorization mechanism to differentially protect data (e.g., by type
or level of sensitivity)
13) Deploy an EHRS with the ability to customize and manage workflow and associated business rules
14) Deploy an EHRS that utilizes a Government-operated Identity Management service
15) Deploy an EHRS with a Single Sign-On approach using a DoD Common Access Card (CAC)
16) Deploy an EHRS that meets DoD Information Assurance requirements to include obtaining Authorization to Operate (ATO) and
Authority to Connect (ATC)
17) Deploy an EHRS that allows continued operations with no data loss when disconnected from the network or in low or no
bandwidth environments and allows for efficient disaster recovery
18) Deploy an EHRS that utilizes industry best practice for configuration management, system updates, and deployment change
management on an enterprise scale
19) Deploy an EHRS designed to operate in a multi-network environment (e.g., .mil, .gov)
20) Deploy an EHRS that supports data exchange with systems to be identified (e.g., Defense Medical Logistics Standard Support
(DMLSS), Blood Donor Management System (BDMS), Healthcare Artifact and Image Management Solution (HAIMS), Coding
and Compliance Editor (CCE), and Theatre Medical Data Store (TMDS))
21) Deploy an EHRS using a regional data center approach to deliver capability to medical facilities and end users
22) Deploy an EHRS using a scalable, regional hub construct and infrastructure that allow the EHRS to meet non-functional
performance requirements (e.g., user experience, system availability, disaster recovery, data read / write response time, etc.)
23) Employ a repeatable, scalable change management and training approach to deliver technical and functional end-user training
while continuously optimizing user experience
24) Deploy an instance of the system (including all integration efforts) as a “Training Environment” that supports users in predeployment training, future new, and refresher training enabling end-users to practice in a non-production environment
25) Deploy an EHRS that includes a support and sustainment strategy to address maintenance and updates for the system
26) Ensure that the proposed regional hub design for EHRS is consistent with the Medical Community of Interest (Med-COI) strategy
27) Deploy an EHRS that supports remote system performance monitoring and modern techniques for preemptive failure prediction
and adjudication
Response: The proposed MEDICS EHRS/VistA meets or exceeds these objectives, as presented above
OSEHRA/VistA System Architecture
Core MEDICS EHRS/VistA can support both ambulatory and inpatient care; where the most significant capabilities are computerized order
entry (medications, special procedures, X-rays, nursing interventions, diets, and laboratory tests), bar code medication administration,
electronic prescribing, and clinical guidelines. OSEHRA/VistA details are available at: http://architecture.osehra.org and an MS Word
version is available at: http://www.osehra.org/document/osehra-vista-system-architecture-product-definition-and-roadmap-updated-201203-06 The separate system architecture summarizes the OSEHR Product Definition, VistA subsystems, GT.M and Caché environments,
LINUX and MS Windows platforms and optional components. In summary, the attached "Product Definition" is the inventory of modules,
which comprise OSEHRA/VistA, where:
 The FOIA release is the “core” set of modules.
 We flag FOIA modules, no longer used by the VA (e.g., HealtheVet)
 We list non-mumps modules used by the VA with appropriate comments.
 We list non-FOIA open-source and commercial modules used by the VA with appropriate comments/links.
 We list the 4 regional and 1 administrative class 2 modules with appropriate comments.
 We list VA approved class 3 modules, used by individual hospitals with appropriate comments/links.
 We list re-factored and in-flight modules with appropriate comments.
 We list the Cache environment & related modules as the primary VA platform.
 We list the GT.M environment & related modules as the available open-source platform.
WORKING DRAFT
3/21/2016 6:25 PM, Page 48
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789

We include links to the Visual Cross Reference tool, source code/package directory, documentation Wikis, discussion groups,
tests and entries per package.
Note that a particular build will require the selection of a subset from the OSEHRA/VistA Product Definition; as an example there may be
alternative modules, which do the same function (e’g’, graphical user interfaces).
For each module, we define:
 Module grouping (e.g., Clinical, Admin/Finance/ HealtheVet)
 Class (e.g., 1, 2, 3)
 Core FOIA (yes/no)
 Module Name
 FOIA Package Name)
 Version
 Namespace
 Patch Number
 Comment
WORKING DRAFT
3/21/2016 6:25 PM, Page 49