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
46
47
48
49
TO:
jake.lewis@tma.osd.mil, no later than 5:00 pm EST, on (Wed) 27-Feb-13.
FROM:
Seong Ki Mun, PhD, President and CEO, OSEHRA, not-for-profit corporation
900 N. Glebe 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 26-Feb DRAFT-M
Contents
FORWARD ............................................................................................................................................................................ 2
1. OVERVIEW / EXECUTIVE SUMMARY ................................................................................................................................... 3
2. PURPOSE / SCOPE OF THIS RFI RESPONSE ..................................................................................................................... 14
FULL DISCLOSURE / DISCLAIMER / ACKNOWLEDGEMENT ................................................................................................................... 14
ASSUMPTIONS ........................................................................................................................................................................... 14
WHY OPEN SOURCE? ................................................................................................................................................................. 15
WHY OSEHRA? ....................................................................................................................................................................... 15
WHY OPEN-SOURCE MEDICS EHRS VCAS? ................................................................................................................................ 15
MEDICS EHRS VCAS FUTURE STATE FOC VISION........................................................................................................................ 16
VistA - the core of a Cloud-based (PooS, IooS, SooS) MEDICS EHRS VCAS ............................................................................ 16
MEDICS EHRS VCAS - from Piecemeal to the Cloud .............................................................................................................. 16
VistA - evolving to a Cloud-based MEDICS EHRS VCAS ......................................................................................................... 17
FOC DoD, VA and Partner Data - Just Publish and Link ........................................................................................................... 18
3. CAPABILITY STATEMENT ................................................................................................................................................ 22
3.1 GENERAL............................................................................................................................................................................. 22
3.2 EHRS SOLUTION .................................................................................................................................................................. 26
3.3 TEST OF OPEN-SOURCE SOFTWARE .......................................................................................................................................... 34
3.4 INTEGRATION ....................................................................................................................................................................... 35
3.5 TRANSITION ......................................................................................................................................................................... 37
3.6 NETWORK AND SECURITY ARCHITECTURE.................................................................................................................................. 39
3.7 ARCHITECTURE/SYSTEMS ENGINEERING (A/SE) ......................................................................................................................... 39
3.8 IDENTITY MANAGEMENT.......................................................................................................................................................... 40
3.9 DATA .................................................................................................................................................................................. 41
3.12 USER INTERFACE ................................................................................................................................................................ 45
3.13 WORKFLOW ....................................................................................................................................................................... 48
GLOSSARY ......................................................................................................................................................................... 49
CONSOLIDATED CDA .................................................................................................................................................................. 49
FHIR ....................................................................................................................................................................................... 49
SEMANTIC WEB.......................................................................................................................................................................... 49
MEDICS EHRS RFI ATTACHMENT (1) – ANTICIPATED MEDICS EHRS OBJECTIVES ................................................................ 50
1. GENERAL OBJECTIVES ............................................................................................................................................................. 50
2. CLINICAL OBJECTIVES .............................................................................................................................................................. 50
3. BUSINESS OBJECTIVES ............................................................................................................................................................ 50
4. PROGRAM MANAGEMENT OBJECTIVES ........................................................................................................................................ 50
5. TECHNICAL OBJECTIVES ........................................................................................................................................................... 51
OSEHRA VISTA SYSTEM ARCHITECTURE ............................................................................................................................ 51
WORKING DRAFT
3/16/2016 9:10 AM, Page 1
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
Forward
On February 22, 2013, under the direction of Mr. Roger Baker, Assistant Secretary for
Information and Technology directed the release to the general public, through OSHERA, a
document summarizing the VA approach to addressing the DoD MEDICS RFI. That document,
which “integrates” to the OSEHRA response, will be submitted by VA. In this brief cover letter,
we provide the rationale for considering OSEHRA-VistA in the evaluation process that the DoD
has engaged. The following diagram highlights OSEHER’s current Open-Source (OS)
engagement with federal agencies, the private sector (CORP), academia (ACAD) and
proposed option for the Medical Electronic DoD Integrated Core System (MEDICS) Electronic
Health Records System (EHRS).
Figure 1 OSEHRA Open Source CM, Problem Tracking, Test and Certification Processes
As shown in Figure 1 above, OSEHRA houses DOD Open AHLTA, Janus, and code
contributed by the US Air Force. OSEHRA also houses the Indian Health Services Resource
and Patient Management System (IHS RPMS) and VA VistA code base.
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 the My HealtheVet (MHV) Open
Source Platform are being extended to accommodate open source platforms and projects as
part of the customer facing aspect of the Open Source Initiative. 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 the Continuity of Care Document (CCD – HITSP/C32 is a type of CCD
which focuses on the patient's summary information.) By leveraging this technology the open
WORKING DRAFT
3/16/2016 9:10 AM, Page 2
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
81
82
83
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
source development is able to provide MHV a web-service 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 open source software is being developed for the VA, the OSEHRA community 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 opensource 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
1. Overview / Executive Summary
The OSEHRA Open Source Community believes that an open-source "VistA Core as Services” (VCAS)
Medical Electronic DoD Integrated Core System (MEDICS) EHRS can deliver to the warfighter an electronic health
record system (EHRS) with the most capability in the shortest period of time for the least cost. The OSEHRA
proposed MEDICS EHRS VCAS will be an open, modular EHRS SOA Platform using standards-based / nonproprietary 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 VCAS 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 VCAS 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 clinics. The proposed MEDICS EHRS VCAS 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 proposed MEDICS EHRS VCAS plus the 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 VCAS 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
WORKING DRAFT
3/16/2016 9:10 AM, 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
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. There are a couple of areas where the RFI could benefit from
clarification:
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:
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 (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)
Therefore, based on the information provided through the RFI,
where are the 364 medical and 282 dental clinics?
MEDICS EHRS VCAS Conceptual Architecture
MEDICS EHRS VCAS is intended to be a Healthcare Services Platform (HSP) 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 VCAS is intended to be an interoperabilityframework for COTS (Commercial Off-The-Shelf), GOTS (Government Off-The-Shelf) and open-source
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 potentially has its own data-andterminology models, business-rules, workflows, reports and displays in accordance with scope-of-practice,
organizational policy, governance and jurisdictional law.
WORKING DRAFT
3/16/2016 9:10 AM, Page 4
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
170
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
Figure 2 Benefits of Open Source MEDICS EHRS VCAS including iEHR ESB / SOA Suite1
TECHNICAL STRATEGY RECOMMENDATION shown in Figure 2, emphasizes the MEDICS EHRS VCAS
solution as being an orchestration of EHR clinical/business, SOA Suite/ESB, UX Framework, VPR and VDR
services; at IOC, the core MEDICS EHRS VCAS 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
VCAS 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. RLUS2 (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 Services3 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
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
portlets4
1
See http://dbooth.org/2008/soas/slides.ppt
2
there is a different opinion, which we recommend as phase 2, one that says w3c Semantic Web standards should be used and that Health-care should
not be developing its own standards for commonplace data exchange functions. In these places reference the "Just Publish and Link" attachment. (see
http://vista.caregraf.info/papers/VistACloudEHRS.html)
3 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
WORKING DRAFT
3/16/2016 9:10 AM, Page 5
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
Figure 3 n-tiered Open-Source MEDICS EHRS VCAS Conceptual Architecture5
The MEDICS EHRS VCAS conceptual architecture specifies an n-tiered federated deployment topology. The
(virtual) patient record tier, is already available in VistA components, the (IBM Web Sphere and open source
MIRTH) ESB / SOA Suite services bus tier, the VLER gateway, and Janus GUI define the MEDICS EHRS VCAS
Platform (aka “ IOC capability 0”) upon which EHRS Core will be constructed by incrementally adding healthcarerelated 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 VCAS using this approach
is the longitudinal nature of the data involved; considering, the mandate that the data must be sustained for more
than 75 years. The MEDICS EHRS VCAS 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 analytics / 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, have their own DBMS that must be accessible via the VDR.
SSO/CM/AM/ID=SSO (single sign on), CM (context management), AM (access management), ID (identification). Portlets are pluggable user interface
components
4
5
Based on Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/16/2016 9:10 AM, Page 6
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
219
220
221
222
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
253
254
255
•
VDR constituent databases may be geographically decentralized; and where, data may be partitioned by
types (e.g., pharmacy, laboratory, images).
As a whole, the VDR must support key performance parameters.
• The VDR must support a single RLUS API for applications to use.
• 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, an RLUS fronted 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 should apply RLUS API wrappers to the sub-queries to translate them into the
appropriate query languages.
MEDICS EHRS VCAS common data ultimately 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 CDA, discussed in the glossary, and HL7 Fast Healthcare Information
Resource (FHIR), discussed in the glossary, 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 VCAS 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 VCAS federated data environment.
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 practices to manage the
database, performance, and the data lifecycle.
WORKING DRAFT
3/16/2016 9:10 AM, Page 7
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
Figure 4 VistA Core
Figure 4 shows a conceptual view of the OSEHRA VistA system architecture. OSEHRA VistA core 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, OSEHRA 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 OSEHRA application module generates at-least-one 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.
Benefits
The following problems are being addressed by the proposed MEDICS EHRS VCAS 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
WORKING DRAFT
3/16/2016 9:10 AM, Page 8
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
3.
4.
5.
6.
7.
data, terminology, and CDA-FHIR, discussed in the glossary, information exchange standards; multiple
organizations can share and ultimately harmonize Electronic Medical Records.
Transition from legacy systems and data to an interoperable EHRS architecture. Virtualization-Layers of
Federated Standards-Based Services allow new and legacy COTS, GOTS and open-source applications,
scaleable databases and infrastructure to coexist.
Agility to respond to rapid healthcare changes and evolving legislation. Services within a standardsbased component-architecture encourage faster and lower-cost changes to be made and tested within
components without requiring enterprise-wide expertise and testing.
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, and
performance vs. cost, usability and supportability. Built-In-Test-Environment (BITE) identifies faults early,
improving robustness and reducing test costs. .
Patient Safety issues resulting from software changes. Component architecture localizes faults. BITE
identifies faults early, improving system robustness, patient safety.
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.
We recommend that the encapsulated VistA Kernel, Fileman and Database be the MEDICS EHRS
VistA core data repository, as shown in Figure 5 VistA Core Expanded and Figure 5, below
provides an architecture schematic to this approach; and, it be integrated into the ESB/SOA Suite
(currently IBM Web Sphere and MIRTH) as is shown in Figure 6 Proposed MEDICS EHRS VCAS
Logical System Architecture.
WORKING DRAFT
3/16/2016 9:10 AM, Page 9
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
306
307
Figure 5 VistA Core Expanded
308
309
Figure 6 Proposed MEDICS EHRS VCAS Logical System Architecture6
6
Based on Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/16/2016 9:10 AM, Page 10
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
355
356
357
358
359
The Operational and Technical Environment of DoD’s legacy EHRs
1.
The DoD has a tiered healthcare delivery network composed of academic medical centers, community hospitals, and stand-alone 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).
RESPONSE7: Cloud Computing – MEDICS EHRS VCAS SaaS, PaaS, IaaS Open Business Model
SaaS (Software as a Service) realize its full potential when services can be composed into higher level
capabilities for end-to-end value-chain delivery that is user-centric and workflow focused to the particular
business domain and process context. This requires both efficient delivery using standardized IT in an
integration MEDICS EHRS VCAS Platform as a Service (PaaS) built on ESB / SOA Suite Infrastructure as
a Service (IaaS) delivery model. With multiple 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 Software as a Service (SaaS) flexibility for necessary medical-domain workflow variation.
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 within the DOD enterprise architecture providing a path for incremental
enterprise transformation that leverages existing capability within a more flexible IT framework that
promotes agile innovation and evolution.
As health services are refactored to work within the proposed MEDICS EHRS VCAS 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.
7 Edward Ost, Director, Worldwide Technology Alliances, Talend, Open Integration Solutions, 301-666-1039
WORKING DRAFT
3/16/2016 9:10 AM, Page 11
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
401
402
403
404
Without standardization on an open-source, open architecture reference MEDICS EHRS VCAS
implementation the overall enterprise 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 VistA, MIRTH, Apache, etc.
is necessary to provide an end-to-end, certifiable environment for provisioning and composition of services;
where, OSEHRA was established to bring these diverse groups together for EHRS.
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. This effectively limits the
marketplace to those large vendors capable of providing an end-to-end solution, whether best-of-suite,
best-of-breed or not. Monolithic applications lead to monolithic businesses which are slow to innovate and
adapt to specific medical domain user’s needs.
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 MEDICS EHRS VCAS + ESB/SOA
Suite modular framework provide the cloud-based PaaS, IaaS and SaaS foundation for an open market
place of health services.
Open source SaaS delivered on top of MEDICS EHRS VCAS + ESB/SOA Suite open
platform can transform not just the DOD systems; but also, the VA, IHS and potentially the
US health service EHRS marketplace, analogous to the impact of Linux!
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 RLUS API for all legacy and future databases addresses this requirement, as shown in:
 Figure 3 n-tiered Open-Source MEDICS EHRS VCAS Conceptual Architecture
 Figure 6 Proposed MEDICS EHRS VCAS Logical System Architecture
 Figure 10 Immunization Example, where RLUS is used to Integrate with Legacy Systems’ Data
 Figure 11 User Experience (UX) is Thoroughly Integrated into MEDICS EHRS VCAS and Legacy using
RLUS
 Figure 12: Proposed Systems Engineering / Integration Approach
 Figure 13 Proposed Transition-Strategy for MEDICS EHRS VCAS Linkage to Legacy Systems
The Janus GUI is open source, at OSEHRA, and should be adapted to meet user and API needs following
an agile methodology. Equally, OSHERA capabilities are driven to provide open, standardized APIs.
2) The DoD desires a common and configurable UX that can also be used with the VA EHRS.
RESPONSE: An open source MEDICS EHRS VCAS based on OSEHRA VistA core 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. The open-source community8 proposes 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
8
Parsons Institute for Information Mapping (PIIM) is a member of the OSEHRA organization.
WORKING DRAFT
3/16/2016 9:10 AM, Page 12
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
445
446
447
to provide a web services standard that allows for the "plug-n-play" of remote running portlets from disparate
sources/applications. 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 proposed 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 of the more encompassing integrated MEDICS EHRS VCAS and iEHR. 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, discussed below). 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
standardized “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 local VPR caches, to maximize performance.
 For IOC, we recommend that the terminology used for the Immunization capability include federally
approved HHS interoperability standards. As an example, most terminology required by the JIC (Joint
Immunization Capability) 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, such as LOINC and RxNorm; and, those shall be authored in a
manner consistent with the SNOMED standard, and placed in a SNOMED extension namespace controlled
by the MHS MEDICS EHRS VCAS and/or IPO iEHR program.
 For FOC, sets of clinical event-data should be represented in HL7 FHIR (Fast Healthcare Information
Resources) that conform to the evolving FHIM (Federal Healthcare Information Modeling initiative) and the
SNOMED EL++ standard. These models are limited in number; but, they will require initial authoring by
SMEs (subject matter experts) who are guided by informatics-experts. In addition to the actual terminologyand-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 HL7/OMG CTS2 (Common Terminology Services 2) Draft Standard for Trial Use9. Additionally, services
should allow translation between equivalent terms, query of available terms, and exploration of various
code sets, using the HDD CTS2 service. Finally, in order to tractably and effectively host, `author, and
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. MHS IM and IPO S&I branch will work with CDC so that CVX and MVX are represented as SNOMED extensions that can be maintained with the
IHTSDO workbench.
9
WORKING DRAFT
3/16/2016 9:10 AM, Page 13
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
492
493
494
495
496
modify a DOD profile for the FHIR terminology-and-information models are standardized and shared with
trading partners; as they are required by a broad variety of MEDICS EHRS VCAS medical-specialty
capabilities; ultimately, the standardized DOD FHIR profile 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;
(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: OSEHRA will NOT respond to an MEDICS EHRS RFP. These requirements are standard fare for
an RFP response, when detailed requirements-specifications and schedules are provided and will not be
addressed in this OSEHRA’s RFI response; except to note, the RFP must clearly define the boundaries of the
IPO Systems Integrator support, DHIMS engineering support and the MEDICS EHRS required support in order
for the proposing team to provide a realistic time and budget.
2. Purpose / Scope 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 opensource community to form open-source partnerships or consortia and for industry to bid an Open-Source "VistA
Core as Services” (VCAS) solution for the “MEDICS EHRS Core Capabilities” RFP. All information in this opensource MEDICS EHRS 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 VCAS; considering that
schedules are tight and that the governments’ evaluation criteria should be “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 VCAS vision, conceptual architecture and strategy RFI
response, leveraging OSHERA "VistA Core as Services” (VCAS) for MEDICS EHRS.
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 scheduled February 27, 2013 House Veterans Affairs Committee session. Our
understanding is that the iEHR investment by the Departments will be continued for IOC and FOC, 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 VCAS through the SOA ESB/Suite.
4. The Secretaries signed (Feb 14,2013 Memorandum states that: “The IPO will proceed with work to identify
and select joint applications.”
WORKING DRAFT
3/16/2016 9:10 AM, Page 14
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
535
536
537
538
539
540
541
It is our assumption in the OSEHRA response to the RFI; provided below, that MEDICS EHRS VCAS will leverage
the investment(s) already made Jointly to deliver the Core Solution and to “provision” the MEDICS EHRS VCAS
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 VCAS vision and leveragable to that “Vision. “
Why Open Source?
“Maximizing the rate of EHRS 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 community-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 VCAS?
We believe that MEDICS EHRS VCAS 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.”
The MEDICS EHRS VCAS 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 approach10 boils down to:
1. For IOC, the MEDICS EHRS VCAS n-tiered architecture integrates the VistA core, with a SOA façade,
supporting service orchestration; then, adding a DOD business process / workflow & CDS (Clinical
Decision Support) layer and data interoperability CDA-FHIR layer via VLER. This reengineered MEDICS
EHRS VCAS Platform should be done using the IBM Web Sphere/ open-source MIRTH federated n-tiered
ESB / SOA Suite, GUI, Cloud-Based (Data Store and virtual blade processors, PaaS, IaaS, SaaS)
architecture, which is carefully structured, using RLUS APIs and properly componentized (with components
10
Based on VistA Modernization Working Group Report, May 4, 2010, American Council on Technology, Industry Advisory
Council
WORKING DRAFT
3/16/2016 9:10 AM, Page 15
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
from internal VA development, external development by paid contractors, project grants, and open source
community, or commercial off the shelf products).
2. As schedule and budget permits, repurpose the remaining 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.”); noting that, open-source software is not free and that twenty candidate repurposing acquisitionapproaches were suggested within the 2010 VistA Modernization Report.
MEDICS EHRS VCAS Future State FOC Vision11
AHLTA has been condemned by its users12; while, VistA has deserved and earned user acclaim and is known for
user driven innovation. Considering the imminent 2014 IOC milestone this RFI response has two phases:
1. In the 2014 IOC short term13, to minimize risk, we are proposing VistA as a suite of core services (VCAS)
now being produced by OSEHRA plus an ESB / SOA Suite bus-based plug-and-play architecture, built on
the RLUS + HDD CRS2; and, passing around FHIR-CDA XML documents. In this phase, MEDICS EHRS
VCAS is just another piece of legacy … a peer/replacement to AHLTA/CHCS. Fortunately, VistA is versatile
and can also support the future state data-centric approach …
2. In the 2017 long term, we are proposing a migration to an innovative data-centric semantic-web
architecture, where MEDICS EHRS VCAS is the framework for EHRS services including persistence,
supporting a workflow for mapping health care data to RDF and linking it with other Linked Data sources.
as is summarized in this section and further described in the referenced papers
First, we recommend a continuation of stakeholder innovation with an IOC MEDICS VCAS, which supports a
natural FOC migration to …
VistA - the core of a Cloud-based (PooS, IooS, SooS) MEDICS EHRS VCAS
The following is an open source community-based14 recommendation for MEDICS as the core of a Cloud-based
PooS (Platform as a Service), IooS (Infrastructure as a Service) and SooS (Software as a Service) Electronic
Health Record System (EHRS) and how best to link DoD, VA and partner data going forward. These topics are
relevant for the DoD's MEDICS EHRS RFI, specifically for sections 3.2, 3.7a, 3.9.
MEDICS EHRS VCAS - 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
See http://dbooth.org/2013/mu/MU-Stage3-RFC-Simple-Response.pdf , http://dbooth.org/2012/pipeline/
http://dbooth.org/2011/stc-dc/ , http://dbooth.org/2011/pipeline/ , http://dbooth.org/2010/stc-ehr/
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 SOAP and XML rollups that require orchestration using rigid document 'models' to derive machine-computable semantics has some latent
assumptions. (1) we have a perfect document 'model' (2) this 'model' won't change over time and (3) this 'model' is universally applicable to all systems
and (4) the number, type, and configuration of all data producing and consuming systems involved will not be changing over time.
Even if the first three conditions were possible, it is rather unlikely that we could expect any of the mission critical clinical information systems involved
to be simultaneously and indefinitely frozen. The PCAST report is very informative here. It recommends not a document-centric view, but data-centric
view, and specifically recommends a universal exchange language - a common medium for data exchange. In this world, each system a first-class and
equal citizen in the same data space; there is no imposition of one system's 'model' on another system, and all systems evolve independently without risk
of breaking any 'model'. This is because there is no 'model. There is just data. This is a general approach that will work with both VA and DoD systems.
14 Provided by Conor Dowling, Rafael Richards; Carol Monahan; Rick Marshall of Caregraf http://vista.caregraf.info/papers/VistACloudEHRS.html
11
WORKING DRAFT
3/16/2016 9:10 AM, Page 16
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
suffer “data-lockup”, where much of the information of the system remains silo'ed in one application or
another. We propose to “free-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 VCAS
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 transparent and easily 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; where, OSEHRA’s 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 core
framework over a network.
"Networking the Framework" is a sensible strategy - the advantage of retaining existing function 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 decades.
In VistA's case, networked versions of proven framework services - CPOE, Schema-light NoSQL
Storage, Medical Concept Management, Document Template Management, and Basic Clinical
Decision Support - will allow development to focus on novel presentation and higher-level
functions and avoid the waste and churn of re-invention. This will be based upon a full and
comprehensive data definition, and a MEDICS EHRS VCAS 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 VCAS Networked Framework needs to be explicit about what data it needs, stores
and produces; that is where FHIR comes in. What does a Prescription look like? A Problem? A Surgical Procedure?
… These all require Detailed Clinical Models (DCMs) for FHIR data modules/resources. And here OSEHRA can
contribute moving VistA forward by managing the fuller definition of MEDICS EHRS VCAS framework's FHIR data
model using the latest standards and technologies.
WORKING DRAFT
3/16/2016 9:10 AM, 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
Two IOC pieces – ESB/SOA Suite and VistA key/core services (i.e., networking, common, clinical, financial and
administrative) and being explicit about FHIR data - allow VistA to evolve into a federated, Cloud-based MEDICSEHRS, 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 non-core components/capabilities.
FOC 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 had too-little meaningfulexchange that has taken too long to put in place. With Linked-Data - data in the Cloud - this can change.
The iEHR discusses and plans for 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. Meta-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 Facebook’s Cassandra, is composed of URLS pointing to federated VistA NOSQL data stores;
the system-of-record can remain in the federated data stores and not be subject to significant revisions or
reformatting.
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-andSuch a URL? Got data in a relational store? There's a Linked-Data tool to publish it all. In a NoSQL data-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 (meta-data) 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
WORKING DRAFT
3/16/2016 9:10 AM, Page 18
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
mean that the VDR (Virtual Data Repository) can’t ultimately add HDD NCID-VUID-SNOMED link(s), as the need
arises.
After publication, then 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 meta-data links, data joins up. While mutual understanding isn't automatic, just by exposing meta-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 patient 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? Meta-data should be published at USHIC’s meta-data registry; so, partners can interoperate with MEDICS
EHRS VCAS.
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 VCAS 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.
Open Source specialist François Letellier advocates that open source is a natural way of
innovation in the software industry and that it is an exemplary and very effective form of
open innovation – as open-source projects/communities act as innovation intermediaries.
The open-source approach is a Darwinian trial-and-error march to excellence.
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).
Additionally, VistA has even been adapted into a Veterinary Medicine Health Information System (VMACS) at
the veterinary medical teaching hospital at UC Davis15
i. Software, to include licensing arrangements / pricing model
15
“Demonstration of M2Web". UC Davis VMTH (Veterinary Medical Hospital) (Dec 2008). http:/.vmth.ucdavis.edu/notebook/index.
WORKING DRAFT
3/16/2016 9:10 AM, Page 19
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
755
756
757
758
759
760
761
762
763
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 using 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 and security
infrastructure, which the government already plans to deploy at the DISA centers and regional cloud sites.
Obviously, system engineering and performance tuning, of caching vs. communications capabilities, must
be done, over time, to maximize the cost-performance and COOP of the deployment.
It needs to be remembered that the MEDICS EHRS VCAS and a limited Full EHRS is required for the
Theater, Remote (low/no Communications) settings, COOP 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 and
741
COOP strategy. In detached operations, data is pre742
cached in a local VPR and when connectivity is
743
established, standard store-and-forward and
744
standard database-synchronization techniques are
745
used. For mobile displays, secure memory-less
746
HTML-5 can be used. The recommended RLUS, UX
747
framework and (open-source Janus) EHRS platform
748
components make porting capabilities to multiple749
types of mobile or detached-platforms simpler and
750
less costly. This approach also supports LCS (Local
751
Cached Storage) for dynamic performance-tuning
752
and a graceful COOP (Continuity-of-Operations) in
753
the event connectivity is lost to regional DISA
754
centers.
Figure 7 The Recommended MEDICS EHRS VCAS 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
WORKING DRAFT
3/16/2016 9:10 AM, Page 20
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
764
765
766
767
768
769
770
771
772
773
774
775
776
777
Richmond VA and the expansion of the capabilities of the DISA Joint Information Technology Centers in
CONUS and 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 currently engaged in. 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 milestones16, the published iEHR
2014 IOC and 2017 FOC milestones, and Administration mandates, the following milestone schedule is applicable.
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
4/13
5/13
Blue
Button
5/13
8/13
7/13 ESB / SOA Suite
Janus
Sandbox for
GUI Development test
6/13
Authoritative
Sources
6/13
7/13
8/13
9/13
10/13
Development
& Test Center
Environment for
Integration test
10/13
12/13
“DOD & VA GUI Exchanging
Standardized
11/13
Healthcare
DOD MEDICS
Data which Is
EHRS Core
2014 iEHR IOC Ready”
IATO Testing
11/13
12/13
3/1/2013
12/31/2013
1/14
Start
iEHR IOC
Integration
2/14
12/14
10/14
Achievement of the
Start
president's goal in 2014
Deployment
to do everything possible
To academic to try to put the health care systems
& community of both these departments together
MTFs
for the benefit of our troops.
3/14
Start IOC
Deployment
to San Antonio
and Hampton Roads
3/14
4/14
5/14
6/14
7/14
8/14
9/14
10/14
1/1/2014
778
779
780
781
11/14
12/14
12/31/2014
Figure 8 High Level MEDICS EHRS VCAS Milestone Schedule,
Based on Administration plus DOD and VA Secretaries’ Milestones
16
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/16/2016 9:10 AM, Page 21
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
v. Training
Response: OSEHRA will NOT bid on an RFP; rather, this RFI response provides an open-source MEDICS
EHRS VCAS 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 BPR change management needs determination.
vii. Sustainment
Response: The OSEHRA open-source community, including providers, managers and developers, can be a
catalyst for innovation and continual improvement; and, OSEHRA can help manage change, test and
certification.
3. Capability Statement
OSEHRA’s RFI response is limited to a Vision, 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.
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. OSEHRA provides configuration management, change management, problem tracking, test,
system analysis and documentation, test and certification tools and forums. These systems will be freely available
for all EHRS related stakeholders 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 Ki Mun, PhD, President and CEO
OSEHRA - None-Profit Corporation
900 N. Glebe Road, Arlington, VA
571-858-3201, munsk@osehra.org
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 non-profit custodial agent and will not respond to any RFP; where, current certified
business and socioeconomic status specifics will be provided by RFP responding venders.
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 and the OSEHRA VistA details available at:


http://architecture.osehra.org HTML version
http://www.osehra.org/document/osehra-vista-system-architecture-product-definition-and-roadmap-updated-2012-03-06 Word version
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).
WORKING DRAFT
3/16/2016 9:10 AM, Page 22
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
Response: OSEHRA will NOT bid on an RFP; rather, this RFI response provides an open-source MEDICS
EHRS VCAS vision, conceptual architecture and strategic vision for the government and its contractors to
follow.
 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. OSEHRA provides configuration
management, change management, problem tracking, test, system analysis and documentation, test
and certification tools and forums. These systems will be freely available for all EHRS related
stakeholders and – like other successful open source communities – will welcome the contributions of
all kinds of developers.
 See Figure 8 High Level MEDICS EHRS VCAS Milestone Schedule,
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
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.d.
c) Describe your approach to scale the development and integration of complex healthcare systems with
greater than five (5) million members.
Response: See Figure 12: Proposed Systems Engineering / Integration Approach and Figure 13 Proposed
Transition-Strategy for MEDICS EHRS VCAS Linkage to Legacy Systems … plus associated write-ups.
Following is an open-source community member’s testimonial17: A key consideration in deploying an
EHR solution in the DoD is the ability to design a flexible and rapid implementation approach which can
best leverage economies of scale. VistA being open source can provide more options and flexibility in
designing and executing large-scale deployments which can significantly reduce cost and risk and lower
long term TCO. Jordan's national deployment of WorldVistA EHR and Mexico's IMMS 18 are examples of
large-scale deployments which have significantly and successfully leveraged the open source nature of
VistA to reduce cost and risk.
Mexico's IMSS was the first non-VA large-scale deployment of VistA. In total 56 hospitals were deployed in
what was a “brown field” implementation scenario. IMSS developed an innovative, “cookie cutter”
deployment methodology and software architecture that was made possible by the open source nature of
VistA. It also leveraged the unrestricted ability to build and apply internal capacity to facilitate rapid
deployment and provide a foundation for long term support.
Jordan's deployment encompasses the country's entire public health system including the Royal Medical
Services which serves active military personnel, veterans and their families, as well as the Ministry of
Health and other public health delivery system. This initiative spans 46 hospitals and over 800 clinics,
serving a population of 6 million. Jordan leveraged open source in shaping its deployment strategy by
maximizing internal capacity building and developing a reusable software configuration approach. In
addition Jordan has become an active member of the VistA community by both contributing improvements
17
Joseph Dal Molin, President, E-cology Corp., Tel: +1.416.232.1206, Joseph Dal Molin <dalmolin@e-cology.ca>
The Mexican Social Security Institute (Spanish: Instituto Mexicano del Seguro Social, IMSS) is a governmental organization that attends to public
health, pensions and social security in Mexico operating under Secretaría de Salud (Secretariat of Health).
18
WORKING DRAFT
3/16/2016 9:10 AM, Page 23
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
and participating on collaborative innovation such as the adaptation of the VA's emergency room package
and Indian Health Services graphical scheduling package. Jordan established internal capacity to
compliment external expertise in less than a year. It's success has laid the foundation for long term support
and continued collaborative innovation which will further reduce cost and risk.
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) and IaaS (Infrastructure 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 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 and users using BPM/BPEL (Business Process
Modeling / Business Process Execution Language) 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/16/2016 9:10 AM, Page 24
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
907
908
909
910
911
912
913
914
915
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 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.
916
917
918
919
920
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/16/2016 9:10 AM, Page 25
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
921
PaaS architecture also provide project flexibility that enables efficient and timely application of human
922
resources to migrate existing systems in a manner consistent with contract, budget, and enterprise
923
planning constraints.
924
925
3.2 EHRS Solution
926
1) Describe the functionality within your solution. At a minimum:
927
a) Describe how your EHR core addresses the DoD’s definition of an EHRS core as described in paragraph 1. The DoD is
928
interested in industry’s feedback on DoD’s core definition, to include (1) comparing it to how they define their product’s core, (2)
929
describing potential differences and the reasons for those differences, and (3) providing recommendations with regards to the
930
use of the DoD model and how their product core compares to the DoD model.
931
932
RESPONSE: MEDICS EHRS VCAS can support both ambulatory and inpatient care; where the most
933
significant capabilities are computerized order entry (medications, special procedures, X-rays, nursing
934
interventions, diets, and laboratory tests), bar code medication administration, electronic prescribing, and
935
clinical guidelines. The follow-on RFP may choose among the following to augment the Figure 4 VistA Core /
936
Figure 5 VistA Core Expanded MEDICS EHRS VCAS capabilities; because the following capabilities are
937
immediately available; and, they can be used now and refactored / reengineered in an orderly fashion as time
938
and budget are available:
975
34. Laboratory: Electronic Data Interchange (LEDI)
939
976
35. Laboratory: Emerging Pathogens Initiative (EPI)
940
Clinical Capabilities
977
36. Laboratory: Howdy Computerized Phlebotomy Login
941
1. Admission Discharge Transfer (ADT)
978
Process
942
2. Ambulatory Care Reporting
979
37.
Laboratory: National Laboratory Tests (NLT)
943
3. Anticoagulation Management Tool (AMT)
980
Documents and LOINC Request Form
944
4. Automated Service Connected Designation (ASCD)
981
38.
Laboratory: Point of Care (POC)
945
5. Beneficiary Travel
982
39.
Laboratory: Universal Interface
946
6. Blind Rehabilitation
983
40.
Laboratory: VistA Blood Establishment Computer
947
7. Care Management
984
Software (VBECS)
948
8. Clinical Case Registries
985
41.
Lexicon Utility
949
9. Clinical Procedures
986
42.
Medicine
950
10. Clinical/Health Data Repository (CHDR)
987
43.
Mental Health
951
11. Computerized Patient Record System (CPRS)
988
44.
Methicillin Resistant Staph Aurerus (MRSA)
952
12. CPRS: Adverse Reaction Tracking (ART)
989
45.
Mobile Electronic Documentation (MED)
953
13. CPRS: Authorization Subscription Utility (ASU)
990
46.
Nationwide Health Information Network Adapter
954
14. CPRS: Clinical Reminders
991
(NHIN)
955
15. CPRS: Consult/Request Tracking
992
47.
Nursing
956
16. CPRS: Health Summary
993
48.
Nutrition and Food Service (NFS)
957
17. CPRS: Problem List
994
49.
Oncology
958
18. CPRS: Text Integration Utility (TIU)
995
50.
Patient Appointment Info. Transmission (PAIT)
959
19. Dentistry
996
51.
Patient Assessment Documentation Package (PADP)
960
20. Electronic Wait List Pharm: National Drug File (NDF)
997
52.
Patient Care Encounter (PCE)
961
21. Emergency Department Integration Software (EDIS)
998
53.
Patient Record Flags
962
22. Functional Independence Measurement (FIM)
999
54.
Pharm: Automatic Replenish / Ward Stock (AR/WS)
963
23. Group Notes Primary Care Management Module
1000
55.
Pharm: Bar Code Medication Administration (BCMA)
964
(PCMM)
1001
56.
Pharm: Benefits Management (PBM)
965
24. HDR – Historical (HDR-Hx)
1002
57.
Pharm: Consolidated Mail Outpatient Pharmacy
966
25. Home Based Primary Care (HBPC)
1003
58.
Pharm: Consolidated Mail Outpatient Pharmacy
967
26. Home Telehealth
1004
59.
Pharm: Controlled Substances
968
27. Immunology Case Registry (ICR)
1005
60.
Pharm: Data Management (PDM)
969
28. Incomplete Records Tracking (IRT)
1006
61.
Pharm: Drug Accountability
970
29. Intake and Output Scheduling
1007
62.
Pharm: Inpatient Medications
971
30. Laboratory Shift Handoff Tool
1008
63.
Pharm: Outpatient Pharmacy
972
31. Laboratory: Anatomic Pathology
1009
64.
Pharm: Prescription Practices (PPP)
973
32. Laboratory: Blood Bank
1010
65.
Prosthetics
974
33. Laboratory: Blood Bank Workarounds
WORKING DRAFT
3/16/2016 9:10 AM, Page 26
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
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
1112
1113
1114
66. Quality Audiology and Speech Analysis and Reporting
(QUASAR)
67. Radiology / Nuclear Medicine
68. RAI/MDS
69. Remote Order Entry System (ROES)
70. Social Work
71. Spinal Cord Dysfunction
72. Standards & Terminology Services (STS)
73. Surgery
74. Traumatic Brain Injury (TBI)
75. Virtual Patient Record
76. VistA Imaging System
77. VistAWeb
78. Visual Impairment Service Team (VIST)
79. Vitals / Measurements
80. Womens Health
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
Financial-Administrative Functions
1080
1. Accounts Receivable (AR)
1081
2. Auto Safety Incident Surv Track System (ASISTS)
1082
3. Automated Information Collection System (AICS)
1083
4. Automated Medical Information Exchange (AMIE)
1084
5. Clinical Monitoring System Integrated Billing (IB)
6. Compensation Pension Record Interchange (CAPRI) 1085
1086
7. Current Procedural Terminology (CPT) Library
1087
8. Decision Support System (DSS) Extracts
1088
9. Diagnostic Related Group (DRG) Grouper
1089
10. Electronic Claims Management Engine (ECME)
1090
11. Engineering (AEMS / MERS) Police and Security
12. Enrollment Application System Quality Management 1091
1092
Integration Module
1093
13. Equipment / Turn-In Request
14. Event Capture Release of Information (ROI) Manager 1094
1095
15. Fee Basis
1096
16. Fugitive Felon Program (FFP)
1097
17. Generic Code Sheet (GCS)
1098
18. Health Eligibility Center (HEC)
1099
19. Hospital Inquiry (HINQ)
1100
20. ICD-9-CM
21. Incident Reporting
1101
22. Income Verification Match (IVM)
1102
23. Integrated Patient Funds
1103
24. Occurrence Screen
1104
25. Patient Representative
1105
26. Personnel and Accounting Integrated Data (PAID)
1106
27. Record Tracking
1107
28. Veterans Identification Card (VIC/PICS)
1108
29. Voluntary Service System (VSS)
1109
30. WebHR
1110
31. Wounded Injured and Ill Warriors
1111
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.
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)
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,
WORKING DRAFT
3/16/2016 9:10 AM, Page 27
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
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
1151
1152
1153
1154
system, associated add ons (MDWS, Janus, HeathyVet) and unlimited ongoing updates (500–600 per year) are provided
as public domain software.[22] This has been 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) and pharmacy. 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]
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: “Out-of-the-box”, the proposed MEDICS EHRS VCAS = VistA core + ESB/SOA Suite = 4+ Gartner criteria.
VistA inherently exceeds the Figure 9 Gartner defined Evidence-Based Level 3 CPR19 system containing patient-centric,
electronically maintained information about an individual's health status and care, focused on tasks and events directly
related to patient care and optimized for use by clinicians. Out of the box, VistA can meet DOD’s MEDICS EHRS, legal
and administrative requirements for the clinical process. As a start, the recommended MEDICS EHRS VCAS 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.
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.
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.
19
WORKING DRAFT
3/16/2016 9:10 AM, Page 28
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1155
1156
Figure 9: Gartner Level 3 Evidence Based Medicine (EBM) CPR System Criteria
1157
WORKING DRAFT
3/16/2016 9:10 AM, Page 29
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
As listed in Table 1, “out-of-the-box” MEDICS EHRS VCAS can deliver a Gartner Level 4+ advanced system that
provides substantial functionality for nurses, physicians, pharmacists, laboratory and imaging technicians. MEDICS
EHRS VCAS plus the ESB (Enterprise Service Bus) / SOA Suite, VPR (Virtual Patient Record) and RLUS-fronted
federated Virtual Data-Repositories will have decision support, workflow capabilities and tools that permit the DOD
MHS to more easily bring EBM (Evidence Based Medicine) to the point of care; where, this out-of-the-box Level 4+
MEDICS EHRS VCAS platform is the perfect foundation to evolve the MHS to a full Level 5 EBM enterprise.
CDS is the essential key to achieving MEDICS EHRS VCAS Gartner level 4 and then 5.
WORKING DRAFT
3/16/2016 9:10 AM, Page 30
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1. IOC CDS should be implemented, using the ESB’s “ILOG” Business Rules Service; but, for COOP-or-detached
JIC operations, the equivalent open-source Drools business-rules-engine service should be used. The standard
design for EHRS’ CDS has been to use an event-processor to monitor state change, value change, and time
change to trigger rules. CDS to alert clinicians to potential adverse effects of shots on a particular patient’s
allergies or medical condition can potentially use the Pharmacy CDS, when it becomes available.
2. FOC CDS, should include CEP (Complex Event Processing) and SEP (Simple Event Processing) using an
RLUS fronted NoSQL DB for richer near real-time analytics. We need to couple this with predictive analytics,
based on salient features of the individual patient to generate a decision tree. This is something which can be
easily done w/ available technology (but not with available data from COTS systems, unfortunately, as the
granularity and data structures in existing commercial vendor systems is still years behind). The DOD FHIR
profile defined patient-context meta-data should be used, i.e. given all that is known about a person, what are
the important properties used to generate historic cohort which is used to derive predictions specific to this
patient—we cannot just use naive Bayes assumptions, as there are non-co-association attributes which have
interactions, i.e. they behave from an observational point of view to be independent, but in reality they have
biological associations which contribute to hidden interactions that require domain knowledge to detect and
explain). E.g. if you cannot look at just the medications someone is on and apply predictions of outcome based
on each—you need to consider individual permutations as separate variables in many cases, and it is often
more than just the need to compensate for a hidden variable. Good example, if you just look at bacterial
sensitivity to sulfa, sensitivity to trimethoprim, and try to predict which UTIs will respond to combined therapy,
you miss out on the sequential molecular inhibition of the two drugs of bacterial enzymes. This results in the
overall rate of mutation leading to resistance being inversely proportionate to the product, not the sum. Crude
example, but in real clinical medicine we are going to find out that there are dozens of these types of complex
interactions, which is why Evidence Based Medicine will continue to flounder (#1 reason—limited or no
evidence), as the various studies are done on (more or less) cohorts which are selected to remove this
additional complexity. E.g. if I know that treatment regime “A” is best for patients with CHF and ESRD because
of a study which excluded diabetics, and my patient is a diabetic, I cannot conclude that “A” is best for my
patient with CHF and ESRD. In particular, since I have domain knowledge that both heart disease and renal
disease have different pathophysiology. What is needed, is an analysis of everyone in the system who has
diabetes, ESRD, CHF, and whatever other relevant (this is the next hurdle to define!) comorbidities, genomics,
prior response to therapy, concomitant medications, etc. In conclusion, case series and comparative outcome
studies need to become historic artifacts of the medical literature; Analytics Based Medicine is
emerging, custom analysis done on a patient-by-patient basis, in real time, before the provider gets to any
decision making. Even when we have real-time analytics guiding decision support, we will always still need a
rules-based expert system to coordinate between different modalities of expert systems (e.g. Bayesian systems
are not going to stop being useful, regression equations, ANN (Artificial Neural Networks), and other
technologies are going to be called on, often in concert, by a Rules-Based Expert System). We also will have
knowledge based (fuzzy, ontological, weighted value, heuristic, causal) decision support, which also requires
some aspect of rules to operationalize.
3. “A fool-with-a-tool is still a fool” … In all these tools, getting the information into a formalism which properly
represents the context of the data, while expressing semantics independent of context, has turned out to be
pretty hard. This is what should scare us the most with all this talk (but not all that much experience) of
WORKING DRAFT
3/16/2016 9:10 AM, Page 31
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
“agile”. Agile, without MDA (Model Driven Architecture) principles, is a recipe for disaster in medical-specialty
domains with complex information. Even things which seem simple (e.g. patient weight) turn out to have
dozens of properties that are required for different use cases, and variations in how they can be represented
and modeled. Without centrally governed data representation, you end up with similar data in legions of
formats useful in only a single user context (i.e. because they were built using the Pollyanna view of “agile”) and
spending 80% of the time reinventing the wheel. This is why the HDD needs to be up front as a critical
enterprise asset for clinical information complexity management. With FHIR information models we can use
“agile” very effectively—esp. if you are smart and leverage the infrastructure like the RLUS (you don’t worry
about how /where to store data—that is someone else’s concern), CTS (Common Terminology Service),
information models, workflow/rules, etc. Using agile methods, you use the various machinery in the enterprise
to assemble capabilities via selection/refinement/constraint of information models which define all of the data
you can use, write your execution logic in business rules, you route data using the workflow system, etc.—no
hand written source code needed!. In this way we use the agile methodology to integrate workflow supported
by tools, such as the CPOE, CDS and inventory management tools.
WORKING DRAFT
3/16/2016 9:10 AM, Page 32
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1228
1229
1230
1231
1232
1233
1234
1235
1236
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
1281
1282
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Generation 2 Gartner's 2007 CPR Clinical Decision Support Criteria
Generation 3 Gartner's 2007 CPR Clinical Decision Support Criteria
Generation 4 Gartner's 2007 CPR Clinical Decision Support Criteria
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 rule sets 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/16/2016 9:10 AM, Page 33
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
3.3 Test of open-source software
Response: The recommended open-source MEDICS EHRS VCAS will be a flexible system that supports multiple
test methodologies. OSEHRA can support DOD to implement 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 OSEHRA supported 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 and are tested and certified by OSEHRA as shown in Figure 1 OSEHRA Open Source CM, Problem
Tracking, Test and Certification Processes.
Agile development requires flexible test tools that can be rapidly configured for the tasks in each sprint. In
addition to OSEHRA tools, VA has developed two additional tools for use in VistA development and
deployment: an automated system test platform and a tool for system data analysis, which are available.
A platform for automated system-level functional test allows developers and testers to rapidly script
functional tests that focus on the features under test to provide 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 VCAS 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.
All test tools are available via OSEHRA.
WORKING DRAFT
3/16/2016 9:10 AM, Page 34
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
3.4 Integration
Describe your approach to integrating your EHRS into the DoD environment as described in paragraph 1.
Figure 10 Immunization Example, where RLUS20 is used to Integrate with Legacy Systems’ Data21
RESPONSE: The recommended solution illustrated in Figure 10 above and detailed-out directly below should be
fully integrated and use both legacy VA/DoD systems, user interfaces and the MEDICS EHRS VCAS 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 VCAS 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.
there is a different opinion, which we recommend as phase 2, one that says w3c Semantic Web standards should be used and that Health-care should
not be developing its own standards for commonplace data exchange functions. In these places reference the "Just Publish and Link" attachment. (see
http://vista.caregraf.info/papers/VistACloudEHRS.html)
20
21
From Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/16/2016 9:10 AM, Page 35
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
Clinical
Template
Repository
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
Figure 11 User Experience (UX) is Thoroughly Integrated into MEDICS EHRS VCAS and Legacy using
RLUS22
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 VCAS 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
22
From Technical Specification Summary available at www.tricare.mil/iEHR
WORKING DRAFT
3/16/2016 9:10 AM, Page 36
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1362
1363
1364
1365
1366
1367
1368
1369
1370
Figure 12: Proposed Systems Engineering / Integration Approach23
3.5 Transition
a)
b)
c)
1371
1372
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 13 Proposed Transition-Strategy for MEDICS EHRS VCAS Linkage to Legacy Systems24
23
24
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/16/2016 9:10 AM, 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
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
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 VCAS 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 Virtual Lifetime Electronic Record (VLER) Connect and Direct protocols.
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 VDR/RLUS+HDD 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 VCAS 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 VCAS UX 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 VCAS 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., RLUS API, SNOMED-CT, LOINC, RxNorm
terminologies) 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 MEDICS EHRS VCAS Program (s) move forward, the
need for translation services is diminished for partners who elect to implement HDD access25 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 VCAS 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 /
MEDICS EHRS VCAS 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 VCAS objective
state
The MEDICS EHRS VCAS 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
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.
25
WORKING DRAFT
3/16/2016 9:10 AM, Page 38
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
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
EHRS VCAS integration architecture design takes 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)
b)
c)
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.
Describe your approach to disconnected operations. How does your EHRS support continued operations in a disconnected (low (256KB) or no
bandwidth) mode?
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 VCAS 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 VCAS 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 VCAS 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 5 VistA Core Expanded running on the Windows/Cache’ or Linux/GT.M environment within
the Figure 3 n-tiered Open-Source MEDICS EHRS VCAS 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) MEDICS EHRS VCAS CDW (NOSQL Clinical Data Warehouse)
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 VCAS will integrate into the IEHR ESB/SOA Suite, as shown
in Figure 3 n-tiered Open-Source MEDICS EHRS VCAS Conceptual Architecture. From a hardware
perspective, the MEDICS EHRS VCAS can run on the DOD commodity blade processors running loadmanaged Virtual-Machines to provide the best cost-performance at DISA centers, regional sites and local
or deployed systems. Obviously, performance tuning will need to be done, as shown in Figure 8 High Level
MEDICS EHRS VCAS Milestone Schedule,
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 12. Multiple regional data
WORKING DRAFT
3/16/2016 9:10 AM, Page 39
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
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 3, is an additional cache, which is critical to managing the cost-performance and
disaster capability recovery of the Figure 3 architecture. Ultimately, a COOP or TMIP type solution may rely
on a PC or clinic or hospital resident local VPR cache, PaaS, IaaS and SaaS.
d) Describe your approach to disaster recovery.
 Response: The recommended MEDICS EHRS VCAS 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.
 Ultimately, a COOP or TMIP type solution may rely on a PC or clinic or hospital resident local VPR cache, PaaS,
IaaS and SaaS, in accordance with scope-of-practice, organizational policy, governance and jurisdictional
law.
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 VCAS 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 Identity Access Management (IAM) services should separate the user
identity, established through various electronic measures (PIV, CAC, and Federation Partners - including DS26
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.
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.
26
WORKING DRAFT
3/16/2016 9:10 AM, Page 40
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
Response: The recommended MEDICS EHRS VCAS 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.
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 VCAS 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 VCAS 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 CDA and HL7 Fast Healthcare Information Resource (FHIR) 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.
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 roleWORKING DRAFT
3/16/2016 9:10 AM, Page 41
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
based 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
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.
WORKING DRAFT
3/16/2016 9:10 AM, Page 42
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1604
1605
1606
1607
1608
1609
1610
1611
1612
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
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 VCAS 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 VCAS 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?
Response: The proposed MEDICS EHRS VCAS inherently supports continued support of legacy systems
during the migration of data, as is shown in Figure 6 Proposed MEDICS EHRS VCAS Logical System
Architecture and Figure 10 Immunization Example, where 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.
WORKING DRAFT
3/16/2016 9:10 AM, Page 43
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
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
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 VCAS inherently supports continued support of legacy systems
during the migration of data, as is shown in Figure 6 Proposed MEDICS EHRS VCAS Logical System
Architecture and Figure 10 Immunization Example, where 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.
Response: The proposed MEDICS EHRS VCAS inherently supports both federated instances of MEDICS
EHRS VCAS 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.
WORKING DRAFT
3/16/2016 9:10 AM, Page 44
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
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 VCAS proposes the Figure 3 n-tiered Open-Source MEDICS EHRS
VCAS 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), we27
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
framework would also be capable of growing to support existing MEDICS system architecture requirements while
allowing flexibility in their appearance.
27
CHRISTOPHER GORANSON l THE NEW SCHOOL. Director, Parsons Institute for Information Mapping, 68 5th Avenue,
Suite 200, New York, NY 10011
WORKING DRAFT
3/16/2016 9:10 AM, Page 45
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1736
1737
1738
Figure 14 HealthBoard button homepage example.
1739
1740
Figure 15 HealthBoard widget view from the patient’s perspective.
WORKING DRAFT
3/16/2016 9:10 AM, Page 46
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1741
1742
1743
1744
1745
1746
1747
Figure 16 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/16/2016 9:10 AM, Page 47
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
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
1774
1775
1776
1777
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 VCAS 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 CDA,
discussed in the glossary, and HL7 Fast Healthcare Information Resource (FHIR), discussed in the
glossary, to define semantically interoperable documents, which can be exchanged or printed.
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
WORKING DRAFT
3/16/2016 9:10 AM, Page 48
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
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.
Glossary
Consolidated CDA
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.
FHIR
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 CDA 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; such as, the
requirements gathering, analysis and cross mapping, currently being done for the FHA Federal Health Information Model
(FHIM). 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 http-based RESTful protocol where each resource
has a predictable URL; where possible, open internet standards are used for data representation.
Semantic Web
"The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise,
and community boundaries."[2] Ultimately, a Semantic Web is "linked data that can be processed directly and indirectly by
machines." By encouraging the inclusion of semantic content in web pages, the Semantic Web aims at converting the current
web dominated by unstructured and semi-structured documents into a "web of linked data". The Semantic Web stack builds
on the W3C's Resource Description Framework (RDF).2]
WORKING DRAFT
3/16/2016 9:10 AM, Page 49
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
MEDICS EHRS RFI Attachment (1) – Anticipated MEDICS EHRS 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 VCAS 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
3. Provide patient facing view of record, supporting data entry and secure messaging
4. Provide team management tools to improve efficiency and collaboration
5. 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 VCAS 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 VCAS 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 VCAS 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.
WORKING DRAFT
3/16/2016 9:10 AM, Page 50
OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
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
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 pre-deployment 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 VCAS meets or exceeds these objectives, as presented above
OSEHRA VistA System Architecture
OSEHRA 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 HTML version
 http://www.osehra.org/document/osehra-vista-system-architecture-product-definition-and-roadmap-updated-2012-03-06 Word
version
WORKING DRAFT
3/16/2016 9:10 AM, Page 51