osehra-response to medics ehrs ht0012-rfi · web viewsource development is able to provide mhv...

OSEHRA-Response to MEDICS EHRS HT0012-RFI-0008

TO: [email protected], no later than 5:00 pm EST, on (Wed) 27-Feb-13.

FROM: Seong Ki Mun, PhD, President and CEO, OSEHRA, not-for-profit corporation900 N. Glebe Road, Arlington, VA, 571-858-3201, [email protected]

SUBJ: Response to DOD MEDICS EHRS HT0012-RFI-0008

DATE: 27 February 2013 Final Version, where, this version is 26-Feb DRAFT-M

ContentsFORWARD........................................................................................................................................................................ 21. OVERVIEW / EXECUTIVE SUMMARY................................................................................................................................ 32. PURPOSE / SCOPE OF THIS RFI RESPONSE................................................................................................................... 14

FULL DISCLOSURE / DISCLAIMER / ACKNOWLEDGEMENT.................................................................................................................14ASSUMPTIONS......................................................................................................................................................................... 14WHY OPEN SOURCE?...............................................................................................................................................................15WHY OSEHRA?..................................................................................................................................................................... 15WHY OPEN-SOURCE MEDICS EHRS VCAS?..............................................................................................................................15MEDICS EHRS VCAS FUTURE STATE FOC VISION.....................................................................................................................16

VistA - the core of a Cloud-based (PooS, IooS, SooS) MEDICS EHRS VCAS...........................................................................16MEDICS EHRS VCAS - from Piecemeal to the Cloud.............................................................................................................16VistA - evolving to a Cloud-based MEDICS EHRS VCAS........................................................................................................17FOC DoD, VA and Partner Data - Just Publish and Link..........................................................................................................18

3. CAPABILITY STATEMENT............................................................................................................................................. 223.1 GENERAL...........................................................................................................................................................................223.2 EHRS SOLUTION................................................................................................................................................................263.3 TEST OF OPEN-SOURCE SOFTWARE........................................................................................................................................343.4 INTEGRATION......................................................................................................................................................................353.5 TRANSITION.......................................................................................................................................................................373.6 NETWORK AND SECURITY ARCHITECTURE................................................................................................................................393.7 ARCHITECTURE/SYSTEMS ENGINEERING (A/SE).......................................................................................................................393.8 IDENTITY MANAGEMENT........................................................................................................................................................403.9 DATA................................................................................................................................................................................413.12 USER INTERFACE..............................................................................................................................................................453.13 WORKFLOW..................................................................................................................................................................... 48

GLOSSARY..................................................................................................................................................................... 49CONSOLIDATED CDA................................................................................................................................................................49FHIR..................................................................................................................................................................................... 49SEMANTIC WEB........................................................................................................................................................................49

MEDICS EHRS RFI ATTACHMENT (1) – ANTICIPATED MEDICS EHRS OBJECTIVES...............................................................501. GENERAL OBJECTIVES...........................................................................................................................................................502. CLINICAL OBJECTIVES............................................................................................................................................................503. BUSINESS OBJECTIVES..........................................................................................................................................................504. PROGRAM MANAGEMENT OBJECTIVES......................................................................................................................................505. TECHNICAL OBJECTIVES.........................................................................................................................................................51

OSEHRA VISTA SYSTEM ARCHITECTURE......................................................................................................................... 51

WORKING DRAFT 5/6/2023 6:10 AM,

123456789

10111213141516171819202122232425262728293031323334353637383940414243444546474849

http://www.osehra.org/


ForwardOn 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 ProcessesAs 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


50515253545556575859

606162636465666768697071727374757677787980


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 open-source core, and potentially additional capabilities, which are housed at OSEHRA and are available to all contractors, at no cost.

Seong Ki Mun, President and CEOOSEHRA, 501(C)-6 not-for-profit corporation

1. Overview / Executive SummaryThe 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 / non-proprietary interfaces, which can cost-effectively replace DoD legacy electronic health records systems (e.g., Armed Forces Health Longitudinal Technology Application (AHLTA), Composite Health Care System (CHCS), and Inpatient System Essentris®) with a Gartner Generation 4+ EHRS for clinical and business applications. When fully implemented, the open-source MEDICS EHRS 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 4) Clinical Workflow: Support for the processes involved in clinical care as well as the information needed


81828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128


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 GapOSEHRA 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 deploymentb) 13 a c a d e m i c m e dic a l c e nte r s with 144,692 admissions, 214,812 procedures (2012 data)c) 43 c om m uni t y 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 ArchitectureMEDICS 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 interoperability-framework 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-and-terminology models, business-rules, workflows, reports and displays in accordance with scope-of-practice, organizational policy, governance and jurisdictional law.


129130131132133134135136137138139140141142143144145146147148149150151152153154155156

158159160161162163164165166167168169

http://www.dssinc.com/dss-drm.htm?id=d

http://www.doh.ihs.gov/edr/documents/EDR%20Fact%20Sheet%20May%202009.pdf

http://www.doh.ihs.gov/edr/documents/EDR%20Fact%20Sheet%20May%202009.pdf

http://www.hrsa.gov/exitdisclaimer/hrsaexitdisclaimer.html


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 legacy-systems’ 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 cachesb. 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 Allergiesb. Treatments , including Medication List and Proceduresc. 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 Preferences3. Orders Management Service, ideally, provided within the Care Coordination Service4. Note Writer Service, ideally, provided within the Care Coordination Service 5. Inventory Management Service6. CDS (Clinical Decision Support), possibly built from the Business Rules Service7. 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 ElectronicHealth Record System Letter Report. 2003. National Academies Press, Washington DC., http://www.nap.edu/catalog.php?record_id=10781 4 SSO/CM/AM/ID=SSO (single sign on), CM (context management), AM (access management), ID (identification). Portlets are pluggable user interface components


170171172173174175176177178179180181182183184185186187188189190191192193194195196197

1

2345678

http://www.nap.edu/catalog.php?record_id=10781

http://vista.caregraf.info/papers/VistACloudEHRS.html

http://dbooth.org/2008/soas/slides.ppt


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 healthcare-related capabilities/applications.

The VDR (aka, federated database system) is a type of metadata-tagged database management system (DBMS), which transparently maps multiple autonomous database systems into a single logical data repository and provides a standard Retrieve, Locate and Update Service (RLUS). The driver in MEDICS EHRS 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. • 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.

5 Based on Technical Specification Summary available at www.tricare.mil/iEHR WORKING DRAFT 5/6/2023 6:10 AM,

198199200201202203204205206207208209210211212213214215216217218219220221222223

9

http://www.tricare.mil/iEHR


• 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.


224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255


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.

BenefitsThe 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 data, terminology, and CDA-FHIR, discussed in the glossary, information exchange standards; multiple organizations can share and ultimately harmonize Electronic Medical Records.


256257258259260261262263264265266267268269270271272273274275276277278279280281282283


3. 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.

4. Agility to respond to rapid healthcare changes and evolving legislation. Services within a standards-based component-architecture encourage faster and lower-cost changes to be made and tested within components without requiring enterprise-wide expertise and testing.

5. High Costs of change and sustainment. Virtualization-Layers of Federated Standards-Based Services make plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeable-components can compete based, on functionality, quality, and performance vs. cost, usability and supportability. Built-In-Test-Environment (BITE) identifies faults early, improving robustness and reducing test costs. .

6. Patient Safety issues resulting from software changes. Component architecture localizes faults. BITE identifies faults early, improving system robustness, patient safety.

7. Open Source Community Enablement Virtualization-Layers of Federated Standards-Based Services support alternate configurations of applications, databases and infrastructure, which may be combinations of MUMPS, COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities.

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.

Figure 5 VistA Core Expanded


284285286287288289290291292293294295296297298299300301302303304305

306307


Figure 6 Proposed MEDICS EHRS VCAS Logical System Architecture6

The Operational and Technical Environment of DoD’s legacy EHRs1. 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

6 Based on Technical Specification Summary available at www.tricare.mil/iEHR7 Edward Ost, Director, Worldwide Technology Alliances, Talend, Open Integration Solutions, 301-666-1039


308309310311

312313314315316317318319320321322323324325326327328329330331332333334

335336337338339340

101112



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.

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!

Requirements1) 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


341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391


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 SystemsThe 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 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

8 Parsons Institute for Information Mapping (PIIM) is a member of the OSEHRA organization. WORKING DRAFT 5/6/2023 6:10 AM,

392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440

13


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 terminology-and-information models, a surrounding set of terminology services is required. These services must provide a variety of application program interface and query capabilities as defined, at a minimum, by the HL-7/OMG CTS2 (Common Terminology Services 2) Draft Standard for Trial 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 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 ResponseOSEHRA is acting to bring a wide range of community stakeholders’ input into a coherent RFI response at the vision, conceptual and strategic architecture level. This Information is provided to stimulate the government’s interest and venders’ open-source response to the MEDICS RFP; specifically, OSEHRA is facilitating the open-source community to form open-source partnerships or consortia and for industry to bid an Open-Source "VistA Core as Services” (VCAS) solution for the “MEDICS EHRS Core Capabilities” RFP. All information in this open-source 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 / AcknowledgementOSEHRA 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:

9 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.


441442443444445446447448449450451452453454

455456457458459460461

462463464465466467468469470471472473474475476477478479480481482483484485486487488

141516

17


1. The further maturation of the iEHR “User Experience” based on the JANUS GUI which is in pilot2. 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 area3. 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.”

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:

10 Based on VistA Modernization Working Group Report, May 4, 2010, American Council on Technology, Industry Advisory Council


489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535

1819


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 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 acquisition-approaches 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 VCASThe 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 CloudBroadly there are three classes of EHRS:

11 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.html13 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


536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573

2021

2223

2425262728293031

32


http://www.aafp.org/fpm/20091100/10the2.html

http://dbooth.org/2012/pipeline/

http://dbooth.org/2013/mu/MU-Stage3-RFC-Simple-Response.pdf

http://dbooth.org/2010/stc-ehr/

http://dbooth.org/2011/pipeline/

http://dbooth.org/2011/stc-dc/


First there’s the collection of loosely coupled, self-contained applications each performing an exclusive function, such as Pharmacy, Radiology, Lab or Scheduling. Here you have limited data-exchange that relies on the widely deployed HL7 V2 protocol and individual applications come from different vendors. Such a Piecemeal EHRS is typical in private-sector hospitals. Yes, you have vendor choice but you also suffer “data-lockup”, where much of the information of the system remains silo'ed in one application or another. We propose 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 VCASFortunately 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.


574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624


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 MEDICS-EHRS, which is open to outside developers and better able to interoperate with other systems. It also makes VistA much more applicable outside the VA, in part because there's no need to adopt it wholesale - it can now mix and match non-core components/capabilities.

FOC DoD, VA and Partner Data - Just Publish and LinkTraditionally 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 meaningful-exchange 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-and-Such 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 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


625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675


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. S o f tw a r e , to i n c lude li c e nsing a r r a n g e m e nts / pri c ing model Response: Since the “core software” of the OSHERA VistA EHRS solution is an Apache-2.0 open-source license and is based upon the fully acquirable VistA, MDWS, VPR, Janus software, there is no licensing cost to the current core capability over the life-cycle. Through OSEHRA developers and partners, there will be potential costs to enhancements and extensions, which are often shared across stakeholders. These updates to the OSERHA VistA core are added as further capabilities and are tested and certified by OSEHRA using its established processes.

15 “Demonstration of M2Web". UC Davis VMTH (Veterinary Medical Hospital) (Dec 2008). http:/.vmth.ucdavis.edu/notebook/index. WORKING DRAFT 5/6/2023 6:10 AM,

676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722

33

http://vista.vmth.ucdavis.edu/notebook/index

http://vista.vmth.ucdavis.edu/notebook/index

http://en.wikipedia.org/wiki/University_of_California,_Davis_School_of_Veterinary_Medicine

http://en.wikipedia.org/wiki/Fran%C3%A7ois_Letellier

http://www.sei.cmu.edu/measurement/index.cfm

http://www.sei.cmu.edu/measurement/index.cfm


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. H a rd w a re 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

COOP strategy. In detached operations, data is pre-cached in a local VPR and when connectivity is established, standard store-and-forward and standard database-synchronization techniques are used. For mobile displays, secure memory-less HTML-5 can be used. The recommended RLUS, UX framework and (open-source Janus) EHRS platform components make porting capabilities to multiple-types of mobile or detached-platforms simpler and less costly. This approach also supports LCS (Local Cached Storage) for dynamic performance-tuning and a graceful COOP (Continuity-of-Operations) in the event connectivity is lost to regional DISA centers.

Figure 7 The Recommended MEDICS EHRS VCAS supports Mobile Displays, Detached Operations and COOP

iii. I mp l e men t a t i o n , to include d e v e lop m e nt, tes t , a n d in t e g r a t i on ( e . g ., n e t w o r k, external devices, external systems)

Response: OSEHRA is already a “self-organized” and functioning development, test and integration environment. The replication of the current AHLTA-CHCS +Essentris instance to the OSEHRA environment would follow the pattern that has been engaged under the maturation of the Development Test Center in Richmond VA and the expansion of the capabilities of the DISA Joint Information Technology Centers in 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. D e pl o y m e nt, wi t h y our t i meline, for the f ol l owi n g: a) Development and Test Center environment for test prior to deploymentb) 13 academic medica l cen te rs wi th 144,692 admiss ions , 214 ,812 procedures


724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770

772773774

http://www.dssinc.com/dss-drm.htm?id=d


c) 43 community hospitals with 95,017 admissions, 119,875 procedures Response: Considering the 5 February 2013 DOD and VA Secretaries stated milestones 16, the published iEHR 2014 IOC and 2017 FOC milestones, and Administration mandates, the following milestone schedule is applicable.

Figure 8 High Level MEDICS EHRS VCAS Milestone Schedule,

Based on Administration plus DOD and VA Secretaries’ Milestones

v. Tr a in i ng 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. B usiness pro c e ss r e e n g ine e ri n g a nd c h a n g e m a n a g e ment Response: OSEHRA can provide a forum to support BPR change management needs determination.

vi i . S ustainm e nt 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.

16 On 5 February 2013, the DOD and VA Secretaries stated that “in the short term, that we've agreed to1. 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.”


775776777

778779780781782783784785786787788789790791792793794

3435363738394041424344454647

48


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 GeneralOSEHRA 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 CEOOSEHRA - None-Profit Corporation900 N. Glebe Road, Arlington, VA571-858-3201, [email protected]

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). 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,

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


795796797798799800801802803804805806807808809810811812813814815816817818819820

821822

823824825826827828829830831832833834835836837838839840841842843844


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 ProposedTransition-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 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 CaseConsider 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

17 Joseph Dal Molin, President, E-cology Corp., Tel: +1.416.232.1206, Joseph Dal Molin <[email protected]>18 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).


845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892

495051

http://en.wikipedia.org/wiki/Secretariat_of_Health

http://en.wikipedia.org/wiki/Social_security

http://en.wikipedia.org/wiki/Pension

http://en.wikipedia.org/wiki/Public_health

http://en.wikipedia.org/wiki/Public_health

http://en.wikipedia.org/wiki/Federal_government_of_the_United_Mexican_States

http://en.wikipedia.org/wiki/Spanish_language


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.

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-to-peer 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


893894895896897898899900901902

903904905906

907908909910911912


provide a common service management infrastructure independent of the application server. When dedicated integration servers make sense.

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 PaaS architecture also provide project flexibility that enables efficient and timely application of human resources to migrate existing systems in a manner consistent with contract, budget, and enterprise planning constraints.

3.2 EHRS Solution1) Describe the functionality within your solution. At a minimum:

a) Describe how your EHR core addresses the DoD’s definition of an EHRS core as described in paragraph 1. The DoD is interested in industry’s feedback on DoD’s core definition, to include (1) comparing it to how they define their product’s core, (2) describing potential differences and the reasons for those differences, and (3) providing recommendations with regards to the use of the DoD model and how their product core compares to the DoD model.

RESPONSE: MEDICS EHRS VCAS 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. The follow-on RFP may choose among the following to augment the Figure 4 VistA Core / Figure 5 VistA Core Expanded MEDICS EHRS VCAS capabilities; because the following capabilities are immediately available; and, they can be used now and refactored / reengineered in an orderly fashion as time and budget are available:

Clinical Capabilities1. Admission Discharge Transfer (ADT)2. Ambulatory Care Reporting3. Anticoagulation Management Tool (AMT)4. Automated Service Connected Designation (ASCD)5. Beneficiary Travel6. Blind Rehabilitation7. Care Management

8. Clinical Case Registries9. Clinical Procedures10. Clinical/Health Data Repository (CHDR)11. Computerized Patient Record System (CPRS)12. CPRS: Adverse Reaction Tracking (ART)13. CPRS: Authorization Subscription Utility (ASU)14. CPRS: Clinical Reminders15. CPRS: Consult/Request Tracking16. CPRS: Health Summary17. CPRS: Problem List


913914915

916917918919920921922923924925926927928929930

931932933934935936937938939940941942943944945946947

948949950951952953954955956957


18. CPRS: Text Integration Utility (TIU)19. Dentistry20. Electronic Wait List Pharm: National Drug File (NDF)21. Emergency Department Integration Software (EDIS)22. Functional Independence Measurement (FIM)23. Group Notes Primary Care Management Module

(PCMM)24. HDR – Historical (HDR-Hx)25. Home Based Primary Care (HBPC)26. Home Telehealth27. Immunology Case Registry (ICR)28. Incomplete Records Tracking (IRT)29. Intake and Output Scheduling30. Laboratory Shift Handoff Tool31. Laboratory: Anatomic Pathology32. Laboratory: Blood Bank33. Laboratory: Blood Bank Workarounds34. Laboratory: Electronic Data Interchange (LEDI)35. Laboratory: Emerging Pathogens Initiative (EPI)36. Laboratory: Howdy Computerized Phlebotomy Login

Process37. Laboratory: National Laboratory Tests (NLT)

Documents and LOINC Request Form38. Laboratory: Point of Care (POC)39. Laboratory: Universal Interface40. Laboratory: VistA Blood Establishment Computer

Software (VBECS)41. Lexicon Utility42. Medicine43. Mental Health44. Methicillin Resistant Staph Aurerus (MRSA)45. Mobile Electronic Documentation (MED)46. Nationwide Health Information Network Adapter

(NHIN)47. Nursing48. Nutrition and Food Service (NFS)49. Oncology50. Patient Appointment Info. Transmission (PAIT)51. Patient Assessment Documentation Package (PADP)52. Patient Care Encounter (PCE)53. Patient Record Flags54. Pharm: Automatic Replenish / Ward Stock (AR/WS)55. Pharm: Bar Code Medication Administration (BCMA)56. Pharm: Benefits Management (PBM)57. Pharm: Consolidated Mail Outpatient Pharmacy58. Pharm: Consolidated Mail Outpatient Pharmacy59. Pharm: Controlled Substances60. Pharm: Data Management (PDM)61. Pharm: Drug Accountability62. Pharm: Inpatient Medications63. Pharm: Outpatient Pharmacy64. Pharm: Prescription Practices (PPP)65. Prosthetics66. Quality Audiology and Speech Analysis and Reporting

(QUASAR)67. Radiology / Nuclear Medicine68. RAI/MDS69. Remote Order Entry System (ROES)70. Social Work71. Spinal Cord Dysfunction72. Standards & Terminology Services (STS)

73. Surgery74. Traumatic Brain Injury (TBI)75. Virtual Patient Record76. VistA Imaging System77. VistAWeb78. Visual Impairment Service Team (VIST)79. Vitals / Measurements80. Womens Health Financial-Administrative Functions1. Accounts Receivable (AR)2. Auto Safety Incident Surv Track System (ASISTS)3. Automated Information Collection System (AICS)4. Automated Medical Information Exchange (AMIE)5. Clinical Monitoring System Integrated Billing (IB)6. Compensation Pension Record Interchange (CAPRI)7. Current Procedural Terminology (CPT) Library8. Decision Support System (DSS) Extracts9. Diagnostic Related Group (DRG) Grouper10. Electronic Claims Management Engine (ECME)11. Engineering (AEMS / MERS) Police and Security12. Enrollment Application System Quality Management

Integration Module13. Equipment / Turn-In Request14. Event Capture Release of Information (ROI) Manager15. Fee Basis16. Fugitive Felon Program (FFP)17. Generic Code Sheet (GCS)18. Health Eligibility Center (HEC)19. Hospital Inquiry (HINQ)20. ICD-9-CM21. Incident Reporting22. Income Verification Match (IVM)23. Integrated Patient Funds24. Occurrence Screen25. Patient Representative26. Personnel and Accounting Integrated Data (PAID)27. Record Tracking28. Veterans Identification Card (VIC/PICS)29. Voluntary Service System (VSS)30. WebHR31. Wounded Injured and Ill Warriors Infrastructure Functions1. Capacity Management Tools2. Duplicate Record Merge: Patient Merge Name

Standardization3. Electronic Error and Enhancement Reporting (E3R)4. Enterprise Exception Log Service (EELS)5. FatKAAT6. FileMan7. FileMan Delphi Components (FMDC)8. Health Data Informatics9. HL7 (VistA Messaging)10. Institution File Redesign (IFR)11. KAAJEE12. Kernel13. Kernel Delphi Components (KDC)14. Kernel Toolkit15. Kernel Unwinder


958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999

1000100110021003100410051006100710081009101010111012101310141015101610171018

10191020102110221023102410251026

1027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060

106110621063106410651066106710681069107010711072107310741075107610771078


16. List Manager17. M-to-M Broker18. MailMan19. Master Patient Index (MPI)20. Medical Domain Web Services (MDWS) (MWVS*2)21. National Online Information Sharing (NOIS)22. National Patch Module23. Network Health Exchange (NHE)24. Patient Data Exchange (PDX)25. Remote Procedure Call (RPC) Broker26. Resource Usage Monitor27. Single Signon/User Context (SSO/UC)28. SlotMaster (Kernel ZSLOT)29. SQL Interface (SQLI)30. Standard Files and Tables31. Statistical Analysis of Global Growth (SAGG)32. Survey Generator

33. System Toolkit (STK)34. VistA Data Extraction Framework (VDEF)35. VistALink36. XML Parser (VistA) Patient Web Portal Functions1. Clinical Information Support System (CISS)2. Electronic Signature (ESig) Person Services3. HealtheVet Web Services Client (HWSC) Registries4. My HealtheVet Spinal Cord Injury and Disorders

Outcomes (SCIDO)5. National Utilization Management Integration (NUMI)6. Occupational Health Record-keeping System (OHRS)7. Patient Advocate Tracking System (PATS)8. VA Enrollment System (VES)9. 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, 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 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 deploymentsVistA 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,

19 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.


10791080108110821083108410851086108710881089109010911092109310941095

1096109710981099

110011011102110311041105110611071108110911101111

11121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146

52535455

http://en.wikipedia.org/wiki/World_Health_Organization

http://en.wikipedia.org/wiki/WorldVistA

http://sequencemanagers.com/

http://www.medsphere.com/

http://www.docstorsys.com/

http://www.bluecliffinc.com/

http://en.wikipedia.org/wiki/Operating_system

http://en.wikipedia.org/wiki/Linux

http://en.wikipedia.org/wiki/GT.M

http://en.wikipedia.org/wiki/Electronic_Health_Record


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.

Figure 9: Gartner Level 3 Evidence Based Medicine (EBM) CPR System Criteria

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.


11471148114911501151115211531154

11551156

5657



11571158

11591160


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. 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


11611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192


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 “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.


1193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226


Generation 1 Gartner's 2007 CPR Clinical Decision Support Criteria None.

Generation 2 Gartner's 2007 CPR Clinical Decision Support Criteria Basic rule capability for a limited set of data items (for example, drug-drug interactions and drug allergies).

Generation 3 Gartner's 2007 CPR Clinical Decision Support Criteria1. 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).2. CDS rules are based on normalized concepts represented in the CMV.3. CDS toolset supports both vendor and client creation and maintenance of rules.4. It is possible for a CDS rule to include a pointer to relevant knowledge management supporting content.5. Supports full Boolean logic rule expressions.6. The output of one rule can trigger the evaluation of a subsequent set of rules.7. "Proactive" alerts (for example support, "Your patient on gentamicin now has worsening renal function. Do you want to lower

dose?").8. Supports basic rule editing and management functions (for example, find all rules that deal with hip fractures).9. Supports at least minimal interactions with the other CPR core capabilities, especially CMV, workflow, order entry and clinical

documentation.10. Other CPR components (for example, workflow and order entry) can trigger evaluation of CDS rules.11. 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).12. Ability to create time-based alerts.13. 3 Ability to escalate alerts if the original notification is not acknowledged in a specified14. time period.15. Generation 3 Patient status indicators (for example, "at risk for renal failure") can be created and then used in CDS functions.16. Logging and auditing tracks the execution of rules and the resulting decision results.

Generation 4 Gartner's 2007 CPR Clinical Decision Support Criteria1. There must be an architecturally distinct CDS system rule engine.2. The rule engine must be capable of dealing with a variety of rule types, including Boolean logic, set theory and fuzzy logic

algorithms.3. Ability to handle all decision support functions needed for clinical, operational and financial activities.4. CDS rules use a standardized syntax for all rules executing on the CPR rule engine.5. Able to fully participate in clinical care protocols, including actively monitoring all relevant data input streams.6. All data in rules and messages must be normalized by interaction with a CMV vocabulary server (VOSER).7. Supports complete rule-management capabilities for the creation, indexing, testing and maintenance of rules.8. Supports a full suite of alerting and notification capabilities.9. Ability to perform clinical simulation functions.10. Must provide basic integrity-checking capabilities to ensure that a given version of the institution’s rule set is logically consistent.11. Has basic capabilities to support the import of new rules from external sources.12. 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.13. 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.14. Sufficient power to provide sub-second response times despite the existence of a large number (thousands) of rules.15. Existence of "wizards" and libraries to assist nontechnical staff in the design of new rules.

Generation 5 Gartner's 2007 CPR Clinical Decision Support Criteria1. CDS functions are fully integrated with all other CPR capabilities.2. Single unified management environment for all CDO decision support capabilities.3. Support for artificial intelligence applications when needed and appropriate.4. 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.5. 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.6. Robust facilities to manage rule sets and ensure the logical integrity and consistency of the currently operating set of rules.7. 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

3.3 Test of open-source softwareResponse: 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


12271228

12291230

123112321233123412351236123712381239124012411242124312441245124612471248124912501251

1252125312541255125612571258125912601261126212631264126512661267126812691270

1271127212731274127512761277127812791280

12811282128312841285


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.


128612871288128912901291129212931294129512961297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321132213231324


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.

20 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)21 From Technical Specification Summary available at www.tricare.mil/iEHR


13251326

1327132813291330133113321333133413351336

585960

61




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 5/6/2023 6:10 AM,

Clinical Template

Repository

133713381339

134013411342134313441345134613471348134913501351135213531354135513561357135813591360

1361

62



Figure 12: Proposed Systems Engineering / Integration Approach23

3.5 Transition a) Describe your approach to transitioning from a legacy EHRS to a new core and / or EHRS. b) Describe your approach to a typical deployment and implementation of the EHRS, including key activities, tasks, timelines,

resources, and dependencies. c) 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

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 23 Adapted from Technical Specification Summary available at www.tricare.mil/iEHR24 Adapted from Technical Specification Summary available at www.tricare.mil/iEHR


13621363136413651366136713681369

13701371137213731374

6364




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 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.

25 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.


1375137613771378137913801381138213831384138513861387138813891390139113921393139413951396139713981399140014011402140314041405140614071408140914101411141214131414141514161417141814191420

656667


3.6 Network and Security Architecture a) Describe your approach to network and security solutions. The Government intends to use a dedicated health network that will run on the

Defense Information Systems Network (DISN) as a logical network as part of the Non-classified Internet Protocol Router Network (NIPRnet). The Government will be responsible for the network from the datacenters down to the end user devices.

b) Describe your approach to disconnected operations. How does your EHRS support continued operations in a disconnected (low (256KB) or no bandwidth) mode?

c) Describe your approach to access control. Is it role-based, attribute-based, or both? Response: VistA integrates seamlessly with network security measures implemented by the deploying enterprise. VA, for example, segregates VistA-related network traffic using industry-standard MPLS services to implement regional VPNs with inter-regional routing. Network boundary protection and monitoring occurs at Trusted Internet Connections (per Department of Homeland Security policy) and a tightly controlled business process governs network access. No changes are required to VistA software in order to gain the benefit of robust network security practices.

3.7 Architecture/Systems Engineering (A/SE) a) Describe your approach to software, languages used, hardware, and systems architectures that will support

the implementation of an EHRS and its integration into the DoD environment. Response: The recommended MEDICS EHRS 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 cost-performance 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 load-managed 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 LevelMEDICS 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 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.


1421142214231424142514261427

14281429143014311432143314341435143614371438143914401441144214431444144514461447144814491450145114521453145414551456145714581459146014611462146314641465146614671468146914701471


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 pre-cached and when connectivity is established, standard store-and-forward and standard database-synchronization 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 DS 26 Logon), from management of roles. When a user authenticates, the user’s credentials are mapped to their roles. In this manner, support is provided for both coarse and fine grain access controls enforceable from various points in the architecture. Services for Role Provisioning, Role Attribute Query, and Role Enforcement are designed with open standards such as LDAP, SAML, XACML, SPML and others to meet the highest interoperability goals. For example, AcS Specialized Access Control (SAC) service can provide fine-grained access control for applications and services like a doctor’s attempt to self-prescribe medication.

For individuals who have multiple roles, the role or personal selection is tied to the authenticated session or queried through the distributed system by the application being accessed. User menus, keys, and file access are assigned and enforced on an individual user and role basis.

c) Describe your approach to Single Sign On capability and the ability to extend it to products that might be added in the future.

Response: The recommended MEDICS EHRS 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

26 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.


1472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517151815191520

6869


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 role-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


152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562156315641565156615671568156915701571

http://architecture.osehra.org/


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, multi-media, 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.

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.


15721573157415751576157715781579158015811582158315841585158615871588158915901591159215931594159515961597159815991600160116021603160416051606160716081609161016111612161316141615161616171618161916201621


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.

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 VA-DoD 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 clinician-facing 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.


16221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671


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.

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.


16721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721


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.

Figure 14 HealthBoard button homepage example.

27 CHRISTOPHER GORANSON l THE NEW SCHOOL. Director, Parsons Institute for Information Mapping, 68 5th Avenue, Suite 200, New York, NY 10011


1722172317241725172617271728172917301731173217331734

173517361737

7071


Figure 15 HealthBoard widget view from the patient’s perspective.

Figure 16 HealthBoard’s widget example used in a provider’s portal.


17381739

174017411742


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.

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.


1743174417451746

1747174817491750175117521753


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 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.

GlossaryConsolidated CDAThe 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


175417551756175717581759176017611762176317641765176617671768176917701771177217731774177517761777177817791780178117821783178417851786178717881789179017911792179317941795179617971798179918001801180218031804


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.

FHIRFast 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]


18051806180718081809181018111812181318141815181618171818181918201821182218231824

http://en.wikipedia.org/wiki/Resource_Description_Framework

http://en.wikipedia.org/wiki/Semantics

http://wiki.hl7.org/index.php?title=Resource


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.

5. Technical Objectives The technical objectives include the following:

1) Configure the EHRS to interface with medical devices and respective data


18251826182718281829183018311832183318341835183618371838183918401841184218431844184518461847184818491850185118521853185418551856185718581859186018611862186318641865186618671868186918701871187218731874187518761877187818791880188118821883188418851886188718881889


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


18901891189218931894189518961897189818991900190119021903190419051906190719081909191019111912191319141915191619171918191919201921192219231924192519261927192819291930

1931193219331934193519361937