osehra-response to medics ehrs ht0012-rfi-0008€¦ · web viewosehra-response to medics ehrs...

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 K. Mun, PhD, President and CEO, OSEHRA, not-for-profit LLC900 N. Gelbe 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 24-Feb DRAFT-I

Contents1. OVERVIEW / EXECUTIVE SUMMARY................................................................................................................................ 22. PURPOSE OF THIS RFI RESPONSE................................................................................................................................ 13

FULL DISCLOSURE / DISCLAIMER / ACKNOWLEDGEMENT.................................................................................................................13ASSUMPTIONS......................................................................................................................................................................... 13WHY OPEN SOURCE?...............................................................................................................................................................14WHY OSEHRA?..................................................................................................................................................................... 14WHY OPEN-SOURCE MEDICS EHRS/VISTA CORE?......................................................................................................................14INNOVATION AND A MEDICS EHRS/VISTA FUTURE STATE VISION..................................................................................................15

VistA - the core of a Cloud-based MEDICS EHRS..................................................................................................................16MEDICS EHRS - from Piecemeal to the Cloud.......................................................................................................................16VistA - evolving to a Cloud-based MEDICS EHRS..................................................................................................................16DoD, VA and Partner Data - Just Publish and Link.................................................................................................................17

3. CAPABILITY STATEMENT SUBMISSION SCOPE.............................................................................................................. 213.1 GENERAL...........................................................................................................................................................................213.2 EHRS SOLUTION................................................................................................................................................................243.3 TEST OF OPEN-SOURCE SOFTWARE........................................................................................................................................303.4 INTEGRATION......................................................................................................................................................................313.5 TRANSITION.......................................................................................................................................................................333.6 NETWORK AND SECURITY ARCHITECTURE................................................................................................................................353.7 ARCHITECTURE/SYSTEMS ENGINEERING (A/SE).......................................................................................................................353.8 IDENTITY MANAGEMENT........................................................................................................................................................363.9 DATA................................................................................................................................................................................373.12 USER INTERFACE..............................................................................................................................................................413.13 WORKFLOW..................................................................................................................................................................... 44

MEDICS EHRS RFI ATTACHMENT (1) – ANTICIPATED MEDICS EHRS/VISTA OBJECTIVES.....................................................451. GENERAL OBJECTIVES...........................................................................................................................................................452. CLINICAL OBJECTIVES............................................................................................................................................................453. BUSINESS OBJECTIVES..........................................................................................................................................................464. PROGRAM MANAGEMENT OBJECTIVES......................................................................................................................................465. TECHNICAL OBJECTIVES.........................................................................................................................................................46

OSEHRA/VISTA SYSTEM ARCHITECTURE......................................................................................................................... 47

WORKING DRAFT 5/8/2023 1:42 PM,

123456789

101112131415161718192021222324252627282930313233343536373839404142434445

http://www.osehra.org/


ForwardThe following diagram highlights the OSEHER’s current Open Source engagement with federal agencies, private sector, and academia (ACAD) and proposed option for MEDICS EHRS.

As shown in the Figure, OSEHRA houses DOD Open AHLTA, Janus, as well as code contributed by the US Air Force. Additional, OSEHRA houses the IHS (Indian Health Services) RPMS (Resource and Patient Management System) and VA VistA code bases.

As a part of VA’s Open Source initiative, VA has announced that all current VistA software supported at the national level will be certified by OSEHRA. Additionally, all VA Medical Centers (VAMCs) will use the certified VistA software. A key component of VA’s Open Source Initiative is the VistA Standardization Project, which has been chartered to ensure all instances of VistA national software use the OSEHRA certified version for each VistA product at all VAMCs. This project is currently completing its pilot phase. Another Open Source Initiative is expansion and enhancement of the VistA programming environment through addition of open source Application Programming Interfaces.

VA Blue Button Continuity of Care Document (CCD) and then My HealtheVet (MHV) Open Source Platform, as part of the customer facing aspect of the Open Source Initiative are being extended to accommodate open source platforms and projects. The goal of this effort is to implement a new architecture leveraging open source as a means of enabling HITSP/C32 functionality as a part of CCD (C32 is a type of CCD which focuses on the patient's summary information.) By leveraging this technology the open source development is able to provide MHV a 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 VA software is being developed, the developers, Project Managers (PM) will contribute their codes and artifacts to OSEHRA. A symmetric aspect of the VA Open Source Initiative is adoption and incorporation of code and products from OSEHRA. Project Managers, requirements analysts and software developers are encouraged to investigate existing certified code and products in the OSEHRA repository for incorporation into future projects or to address agency business needs requirements.

We envision that DOD MEDICS EHRS can be constructed from an OSEHRA certified open-source core, and potentially additional capabilities, which are housed at OSEHRA and are available to all contractors, at no cost.

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


464748

4950515253545556575859606162636465666768697071727374757677787980818283


1. Overview / Executive SummaryThe OSEHRA Open Source Community believes that an open-source Medical Electronic DoD Integrated Core System (MEDICS) EHRS/VistA can deliver to the warfighter an electronic health record (EHR) with the most capability in the shortest period of time for the least cost. Open-Source MEDICS EHRS/VistA will be an open, modular EHRS SOA Platform using standards-based / non-proprietary interfaces, which can cost-effectively replace DoD legacy electronic health records systems (e.g., Armed Forces Health Longitudinal Technology Application (AHLTA), Composite Health Care System (CHCS), and Inpatient System Essentris®) with a Gartner Generation 4 EHRS for clinical and business applications. When fully implemented, the open-source MEDICS EHRS/VISTA can provide a single “logical” authoritative source, within a federated EHRS deployment, of health information for DoD beneficiaries; help improve the health of our population; improve patient safety and quality of care provided; help control health care costs; and contribute to the medical readiness for our military. The proposed MEDICS EHRS/VistA conceptual architecture and strategic vision is proven to be scalable and can support DoD’s direct care population of more than 3 million beneficiaries, and 70,000 clinicians who practice in 56 hospitals, 364 medical clinics, and 282 dental clinics1. The proposed MEDICS EHRS/VISTA architecture and strategy can maintain, and support enhancements to, ongoing data exchange between DoD and the Department of Veterans Affairs (VA), and all external partners.

The MEDICS EHRS/VistA core and iEHR ESB/SOA Suite platform together provide the common infrastructure, clinical and business for a Best of Suite (BoS) application, which would be followed by the addition of Best of Breed (BoB) applications until final operating capability is deployed. OSEHRA’s open-source MEDICS RFI response provides analyses, alternatives, timelines, and recommendations as to this approach. For the purposes of this RFI, the OSEHRA open-source MEDICS EHRS/VistA response supports and can greatly exceed the DoD defined EHRS core as containing, at a minimum, the following components:

1) System Management: Includes support for security (while balancing the need for legitimate access), identity management, disaster recovery, and business continuity

2) Interoperability: Ability to communicate and interact with other systems 3) Data Model: Permanent data store that guarantees that information is stored for the legally required time

and can be retrieved rapidly and flexibly 4) Clinical Workflow: Support for the processes involved in clinical care as well as the information needed 5) Clinical Documentation, Document Management, and Data Capture: Capture all clinically relevant

information at the point of care 6) Clinical Display / Dashboard (part of clinical applications): Present data in a meaningful manner that

contributes to the clinician’s ability to use the data effectively 7) Clinical Decision Support (CDS): Ability to incorporate rules and decisions 8) Order Management (including Computerized Physician Order Entry or CPOE): Support a variety of

mechanisms for entry and management of all types of clinician orders

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

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

1 See VA response to DOD MEDICS EHRS RFI for details WORKING DRAFT 5/8/2023 1:42 PM,

84858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

1

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


System (RPMS) and Electronic Dental Record (which is a Dentrix product) and the Veterans Administration’s VistA Dental Record Manager Plus. The VistA system is certified as a module, while the IHS product is certified as a full EHR.”

Perhaps most critical, is the ROM description in the RFI document which reads as follows with emphasis applied: iv. Deployment, with your timeline, for the following:

a) Development and Test Center environment for test prior to 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)

The Question raised from the above is Where Are the 364 medical clinics, and equally Where are the 282 Dental Clinics?

Conceptual ArchitectureThe recommended MEDICS EHRS/VistA is intended to be a Healthcare Services Platform emphasizing the reuse of high quality clinical/business, infrastructure services, a User Experience (UX) framework, a Virtual Patient Record (VPR) and virtual data repository (VDR). The recommended MEDICS EHRS/VistA is intended to be an interoperability-framework for COTS (Commercial Off-The-Shelf), GOTS (Government Off-The-Shelf) and 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 has its own data-and-terminology models, business-rules, workflows, reports and displays in accordance with scope-of-practice, organizational policy, governance and jurisdictional law.

We recommend the following two MEDICS EHRS/VistA specific 1) technical and 2) risk mitigation strategies:

1. We recommend that MEDICS EHRS/VistA establish the FOC foundation and the legacy transition strategy by focusing on VDR legacy-system data integration using the HL7/OMG specified RLUS (Retrieve, Locate, and Update Service) database front-end; and to insure interoperability, IOC must include a requirement to use the underlying EHRS Platform HDD (Health Data Dictionary), to implement RLUS), Janus UX framework, VPR and VDR. IOC should, ideally, use MEDICS EHRS/VistA clinical/business services, initially provided by legacy-system’ service-facades. If IOC includes a turn-key COTS or GOTS component, it must have exit ramps (e.g., service invocations) enabling the use of the HDD, UX framework, VPR and VDR. FOC (Final Operating Capability) should exclusively use MEDICS EHRS/VistA platform services.

2. We recommend a three-phase risk mitigation strategy, where the EHRS integration contractor coordinates and demonstrates the MEDICS EHRS/VistA core platform solution; first, in the Service Oriented Architecture (SOA) Suite/ESB (Engineering Service Bus) sandbox; secondly, at the DOD integration and Test facility in Richmond or Maui and finally at Dec 2014 IOC.


133134135136137138139140141

143144145146147148149150151152153154155156157158159160161162163164165166167168169170

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

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

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


Figure 1 Benefits of MEDICS EHRS/VistA including iEHR ESB / SOA Suite

TECHNICAL STRATEGY RECOMMENDATION #1, shown in Figure 1, emphasizes the MEDICS EHRS/VISTA solution as being an orchestration of EHR clinical/business, SOA Suite/ESB, UX Framework, VPR and VDR services; at IOC, the core MEDICS EHRS/VISTA clinical/business services should, ideally, be provided by legacy-systems’ service-façades; at FOC, the same EHR services should be exclusively provided by MEDICS EHRS/VISTA components / capabilities. Most importantly, the key clinical/business services are:

1. Virtual Patient Record (VPR) Service to collate data from all legacy sources and use it as if it were coming from one source a. RLUS (Retrieve, Locate Update Service) fronted databases and COOP (continuity-of-operation) and

performance cachesb. HDD (3M Healthcare Data Dictionary) information-and-terminology models and services supporting

VPR.2. Care Coordination Services2 enabling “medical-home” type patient-care management

a. Problems , including Diagnosis and 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 Service, ideally, provided by the Pharmacy capability.6. 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

portlets3

2 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 3 SSO/CM/AM/ID=SSO (single sign on), CM (context management), AM (access management), ID (identification). Portlets are pluggable user interface components


171172173174175176177178179180181182183184185186187188189190191192193194195196197198

2345

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


Figure 2 n-tiered Open-Source MEDICS EHRS/VISTA Conceptual Architecture4

The MEDICS EHRS/VISTA conceptual architecture specifies an n-tiered federated deployment topology. The (virtual) patient record tier, is already available in VistA components, the ESB / SOA Suite services bus tier, the VLER gateway, and Janus GUI define the MEDICS EHRS/VISTA Platform (aka “ IOC capability 0”) upon which EHRS Core will be constructed by incrementally adding healthcare-related capabilities/applications.

The VDR (aka, federated database system) is a type of metadata-tagged database management system (DBMS), which transparently maps multiple autonomous database systems into a single logical data repository and provides a standard Retrieve, Locate and Update Service (RLUS). The driver in MEDICS EHRS/VISTA using this approach is the longitudinal nature of the data involved, whereby the mandate that the data must be sustained for more than 75 years. The MEDICS EHRS/VISTA VDR can be a logical or physical partitioning of data among multiple databases which apply to one or more capabilities / applications. It can support operational data store, data mart, and data warehouse type queries.

The VDR should support the following requirements:• To continue “good” care, historical clinical data that currently reside in legacy data bases must be

accessible from the source data repository or an appropriate data warehouse via the VDR. • Commercial products, like ancillary services, inpatient, and emergency department systems have their own

DBMS that must be accessible via the VDR. • VDR constituent databases may be geographically decentralized where data may be partitioned by types

(e.g., pharmacy, laboratory, images).

As a whole, the VDR must support key performance parameters. • The VDR must support a single RLUS.

4 Based on Technical Specification Summary available at www.tricare.mil/iEHR WORKING DRAFT 5/8/2023 1:42 PM,

199200201202203204205206207208209210211212213214215216217218219220221222223224

6

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, a federated database system must be able to decompose each query into sub-queries for submission to the relevant constituent Data Base Management Systems (DBMS), after which the system must composite the resulting sets of the sub-queries. Because various DBMS employ different query languages, federated database systems can apply wrappers to the sub-queries to translate them into the appropriate query languages.

MEDICS EHRS/VISTA common data implies the native use of a single logical database, specified by the HDD. The HDD manages information and terminology models, a concept dictionary and translation models; where we recommend the use of the new HL7 Consolidated CDA5 and HL7 Fast Healthcare Information Resource (FHIR)6 information exchange payload models, schemas, and Schematron. These design-time components provide MDR (Metadata Repository) services to the run-time CTR (Clinical Template Repository) and Built-In Test Environment (BITE). The HDD provides terminology services that enables semantic interoperability among healthcare trading partners. BITE enables run-time performance and payload-data-integrity testing of MEDICS EHRS/VISTA ad-hoc trading partners and plug-and-play applications. BITE uses Schematron, which is a rule-based validation language. RLUS (Retrieve, Locate and Extraction) provides a data extraction service, a data translation service, an information exchange mediation service, and BITE services. RLUS relies on identification, authentication, authorization, access, and secure data transport services. RLUS and HDD “harmonize” the MEDICS EHRS/VISTA federated data environment.

It is important to look at each tier in conjunction with the other tiers. The capabilities / applications and ESB interactions with each other exist, and the database will influence the way ahead for best approach(es) to managing the database, performance, and the data lifecycle.

5 The proposed rule for Meaningful Use Stage 2 and its companion rule for standards and certification criteria for EHR technology promote the use of single standards for communicating information in certain transactions. The proposed rule establishes the Consolidated Clinical Document Architecture (CDA) as the single standard for communicating the summary of care. The Consolidated CDA is based on components of two standard formats that were previously required for certified EHRs: the Continuity of Care Record (CCR) and the Continuity of Care Document (CCD). This format was chosen as the standard for communicating the summary of care since it can accommodate all data elements that CMS proposes providers give their patients after office visits. Health Level 7 (HL7), an accredited standards development organization, created a single implementation guide for the Consolidated CDA, which was released in December 2011 in an effort to reduce ambiguity and eliminate conflicts in documentation; where, the Consolidated CDA solution encompasses a library of reusable CDA templates, setting the stage for streamlined development and quicker implementation. The templates allow for incremental interoperability and easier machine-to-machine communication, thereby facilitating the transfer and storage of more data.6 Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "Resources" that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for a range of interoperability problems. The simple direct definitions of the resources are based on thorough requirements gathering, formal analysis and extensive cross-mapping to other relevant standards. A workflow management layer provides support for designing, procuring, and integrating solutions. Technically, FHIR is designed for the web; the resources are based on simple XML, with an http-based RESTful protocol where each resource has a predictable URL; where possible, open internet standards are used for data representation.


225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256

789

10111213141516

17181920212223

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


Figure 3 VistA Core

Figure 3 shows a conceptual view of the 2011 OSEHR system architecture. Legacy OSEHR is predominantly coded in Ansi MUMPS (M) and can be run within the open source GT.M Linux/UNIX environment or within the InterSystems Cache Windows environment. At the conceptual level, OSEHR has the following major components:

Applications, such as Scheduling, Pharmacy (Rx), Laboratory, Radiology, ADT plus 100+ other packages Kernel/Tools, such as Security, Menu Management, TaskMan, MailMan, Package Manager, etc. FileMan, which contains set of APIs, search, inquire, edit, print, utility functions, data dictionary utilities,

transfer entries, etc. “Database”, which is composed of FileMan, which manages the M global namespaces and the Data

Dictionary, which defines OSEHR’s hierarchical file layout for Apps., Rx, Lab, Images, Common Data, Plus over 100+ other files.

Typically, each OSEHR application module generates at-least-one global data file. Within these files are the clinical, administrative, and computer infrastructure-related information that supports day-to-day operations and contain patients' medical and healthcare utilization histories, including data on demographics, episodes of care, medicines, practitioner information, diagnoses, procedures.

The following problems are being addressed by the future-state architecture:1. Innovation . Services within a standards-based component-architecture encourage lower-cost component

innovation without requiring enterprise-wide expertise and extensive testing. SDK empowers individuals and avoids stovepipes.

2. Interoperability among DoD, VA, IHS and purchased care partners. Canonical information and terminology models can be used to map among heterogeneous system information exchanges. By adopting common HDD data, terminology, and communications standards; multiple organizations can share and ultimately harmonize Electronic Medical Records.


257258259260261262263264265266267268269270271272273274275276277278279280281282283


3. Transition from legacy systems and data to an interoperable EHR architecture. Virtualization-Layers of Federated Standards-Based Services allow new and legacy COTS, GOTS and open-source applications, scaleable databases and infrastructure to coexist.

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

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

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

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

Response: We suggest that the VistA Kernel, Fileman and Database be encapsulated into a VistA core with a set of Services as shown in Figure 4 VistA Core Expanded.

Figure 4 VistA Core Expanded


284285286287288289290291292293294295296297298299300301

302303


Figure 5 Proposed MEDICS EHRS/VISTA Logical System Architecture7

Operational and Technical environment that the DoD’s legacy EHRs operate in.1. The DoD has a tiered healthcare delivery network composed of academic medical centers, community hospitals, and 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).

RESPONSE8: Service-Centric Open Business Model for MEDICS EHRS/VISTA7 From Technical Specification Summary available at www.tricare.mil/iEHR8 Edward Ost, Director, Worldwide Technology Alliances, Talend, Open Integration Solutions, 301-666-1039


304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333

334335

242526



In order for DoD MHS and VA to successfully deliver and modernize health services, it is necessary to not only provide an integrated Electronic Health Record system, but to deliver services using an open architecture as the foundation of an agile ecosystem of health IT vendors. Ensuring modular, composable business functionality aligned with the VA enterprise architecture provides a path for incremental enterprise transformation that leverages existing capability within a more flexible IT framework that promotes innovation and evolution.

As health services are refactored to work within the new open architecture, modularity provides flexibility for local customization and extension to be balanced with standardization for efficiency. Modular, open business architectures also promote more rapid and sustainable innovation. New functionality can be more rapidly implemented, integrated, and provisioned, and assessed without undue impact to the broader delivery system of systems.Realizing the full value proposition for the information supply chain requires addressing multiple domains from operating systems, to application servers, to integration technology, to business domain applications. Open Source provides the intellectual property foundation for a richer, more diverse, and efficient IT and health services marketplace.

Services realize their full potential when they can be composed into higher level capabilities for end-to-end delivery that is user-centric and task focused to the particular business domain and process context. This requires both efficient delivery using standardized IT in an integration PaaS (Platform as a Service) delivery model. With multiple open source vendors competing and cooperating in the market place, the value of individual services is multiplied through re-use that is not limited to a single vendor’s technology. This preserves SaaS (Software as a Service) flexibility for necessary variation. Without standardization on an open-source, open architecture reference implementation the solution implementation is slowed by fruitless variation in IT layers that do not provide value to the end user. At the same time, competition and innovation at the IT layer must be preserved. An open source solution based on a truly open community such as Apache is necessary to provide an end-to-end, certifiable environment for provisioning and composition of services; where, the VA has established OSEHRA to bring those groups together for this purpose.

Use of proprietary infrastructure, even when it supports open standards for interfaces, restricts the options for composition of the business components. Vendors must expend additional cycles on supporting multiple proprietary platforms. Often times the architecture is less flexible as well, running only on JEE servers. This effectively limits the marketplace to those large vendors capable of providing an end-to-end solution, whether west-of-suite, best-of-breed or not. Monolithic applications lead to monolithic businesses which are slow to innovate and adapt.

If the health services are not sufficiently modular and compose-able, or if they are not interoperable, scalable, and pluggable with IT infrastructure, then the ability to compose solutions is severely constrained. In contrast, when open source health applications work together using an open source integration framework the true promise of open source is achieved. Open source, modular frameworks provide the foundation IaaS and PaaS for an open market place of health services. Open source SaaS delivered on top of that open platform can transform not just individual systems, but the health service EHR marketplace.

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 Janus GUI is open source, at OSEHRA, and should be adapted to meet user and API needs following an agile methodology.

2) The DoD desires a common and configurable UX that can also be used with the VA EHRS. WORKING DRAFT 5/8/2023 1:42 PM,

336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386


RESPONSE: An open source MEDICS EHRS/VISTA core based on open-source VistA will inherently interoperate with the VA’s VistA configuration. The DOD and VA Secretaries stated that the IOC GUI will be Janus, which is available as open-source, at OSEHRA. We9 propose the extension of Janus into an open GUI framework that will support a modular, interchangeable, and reusable open source GUI, using the JAVA standard GUI API (JSR 168, JSR 186). The purpose of the Web Services for Remote Portlets protocol is to provide a web services standard that allows for the "plug-n-play" of remote running portlets from disparate sources. Many sites allow registered users to personalize their view of the website by turning on or off portions of the webpage, or by adding or deleting features. This is sometimes accomplished by a set of portlets that together form the portal. The Java Portlet Specification (JSR168, JSR286) enables interoperability for portlets between different web portals. This specification defines a set of APIs for interaction between the portlet container and the portlet addressing the areas of personalization, presentation and security.

The open GUI framework will provide structural support for existing GUI systems such as Janus and others by providing best-practice design and usability guidelines for their expansion and enhancement to meet the needs of the more encompassing integrated EHR. The open GUI framework will promote a modular solution, where modules can be easily interchanged and integrated into GUIs suitable for various Healthcare settings. The open GUI framework will promote system usability and support the ability to test GUI designs both before and after implementation to gauge effectiveness. The open GUI framework will consolidate in one location the advances made through the redesign efforts of AHLTA, Essentris and others, developing a common interface that evolves out of all the GUI efforts. OSEHRA has seen some growth in new GUI systems for specific uses (HealthBoard for the Patient Centered Medical Home). Well designed GUI contributions hold the key to a number of usability and adoption challenges now faced by existing EHR systems. The open GUI framework would take advancements made in the OSEHRA community and implement them through a universal interface.

3) The DoD healthcare data must be interoperable with the VA, and vice versa, supporting the care delivery to shared or transferring patients. The VA data can be normalized and standardized using the 3M Healthcare Data Dictionary (HDD) and other appropriate standards. RESPONSE: All databases should have an standard RLUS API façade, which uses the 3M HDD and

Common Terminology Service (CTS) to harmonize data into the local VPR cache. For IOC , we recommend that the terminology used for the Immunization capability include federally

approved interoperability standards. Most terminology required by the JIC will map directly to the CDC (Centers for Disease Control) CVX and MVX (immunization substance and manufacturer names) code sets, wrapped into a SNOMED extension. Other terminology extensions may be required, and those shall be authored in a manner consistent with the SNOMED standard, and placed in a SNOMED extension namespace controlled by the IPO iEHR program.

For FOC , sets of clinical event-data should be represented in Simple Information Models (SJICs) that conform to the evolving CJICI (Clinical Information Modeling Initiative) and the SNOMED EL++ standard. These models are limited in number; and, they will require authoring by SMEs (subject matter experts) who are guided by IPO’s Standards and Interoperability (S&I) Branch informatics-experts. In addition to the actual terminology-and-information models, a surrounding set of terminology services is required. These services must provide a variety of application program interface and query capabilities as defined, at a minimum, by the HL-7/OMG CTS2 (Common Terminology Services 2) Draft Standard for Trial Use10. Additionally, services should allow translation between equivalent terms, query of available terms, and exploration of various code sets. Finally, in order to tractably and effectively host, `author, and modify both

9 Parsons Institute for Information Mapping (PIIM) is a member of the OSEHRA organization.10 Currently, the HL7 CTS 2 draft standard does not provide full support for SNOMED CT structures; it will need some evolution to bring it where it needs to go. IPO S&I branch will work with CDC so that CVX and MVX are represented as SNOMED extensions that we can maintain with the IHTSDO workbench.


387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432

27282930

31


the Immunization Capability terminology-and-information models, a Standards and Interoperability Terminology Workbench is required. Some of these elements, such as the Terminology Services, the Workbench, and the Simple Information Model/CJICI models are shared, as they are required by a broad variety of MEDICS EHRS/VISTA medical-specialty capabilities; ultimately, the terminology workbench should be used by medical department proponents and clinical users allowing user-centric agile-processes, ultimately managed, in accordance with scope-of-practice, organizational policy, governance and jurisdictional law.

4) The DoD anticipates that the overall replacement EHRS effort may include, but not be limited to: (1) system and software engineering; (2) system integration; (3) installation, testing, and deployment; (4) lifecycle logistics support to include user training; (5) system and data hosting; (6) operations and maintenance (O&M) support; and (7) business intelligence and research.

RESPONSE: These requirements are standard fare for an RFP response and will not be addressed here; except to note, the RFP must clearly define the boundaries of the IPO Systems Integrator support, DHIMS engineering support and the MEDICS EHRS/VISTA required support in order for the vender team to provide a realistic time and budget.

2. Purpose of this RFI 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-based solution for the “MEDICS EHRS/VISTA Core Capabilities” RFP. All information developed in this open-source MEDICS Vision and Strategy RFI response is public and is freely available to everyone, on the OSEHRA web-site. OSEHRA believes its open-source MEDICS vision, conceptual architecture and strategic vision will result in a compelling (faster, better and cheaper) Business Case for an open-source MEDICS EHRS/VISTA; considering that schedules are tight and that the governments’ evaluation criteria is “Best Value to the Government”.

Full Disclosure / Disclaimer / 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 conceptual architecture and strategic vision RFI response, leveraging OSHERA VistA (OV) to the core and extended vision of the RFI.

Assumptions“OSEHRA is fully aware of the DOD and VA Secretaries’ February 5, 2013 announced changes to the iEHR project. We are equally aware of the pending (February 27, 2013) session to be conducted under the House Veterans Affairs Committee. Our understanding is that the iEHR investment by the Departments will be continued to the described schedule for IOC and FOC as described, which includes:

1. The further maturation of the iEHR “User Experience” based on the JANUS GUI which is in 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 through the SOA ESB/Suite.

4. We have not seen any update to the clinical capability deployment plan for the ESB/SOA project WORKING DRAFT 5/8/2023 1:42 PM,

433434435436437438439440441442443444445446447448

449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484


It is our assumption in the OSEHRA response to the RFI; provided below, that MEDICS EHRS core will leverage the investment(s) already made Jointly to deliver the Core Solution and to “provision” the MEDICS EHRS Core through application, clinical and business capabilities sequentially, prioritized by need and availability. The reasons for our assumption are that the above items have already been invested by DoD, and that they are both consistent with the MEDICS EHRS core vision and leveragable to that “Vision. “

Why Open Source? “Maximizing the rate of EHR innovation” means engaging the best minds in government, industry, and academia. Developers must be comfortable contributing their innovations and users must be comfortable relying on the software to run their enterprise. A well-constructed open source model provides the relationship between developers, users, vendors, and service providers and provides the infrastructure for their efficient interaction.

Why OSEHRA?OSEHRA simply and powerfully establishes an organized framework for all kinds of companies and creative individuals – users, developers, service providers, researchers, universities and for-profit companies – to communicate, collaborate, and share. The open source ecosystem is a transparent, rapid and safe way to accelerate progress in creating an ever improving, and highly functional EHRS for the beneficiaries of healthcare, and more broadly, the nation as a whole.

Why Open-Source MEDICS EHRS/VistA Core?We believe that MEDICS EHRS/VistA supports a faster, better, cheaper business case to meet

1) the DOD and VA Secretaries objectives a. to select a “core set of IEHR capabilities no later than March of 2013” b. to support 2014 iEHR IOC (Initial Operating Capability) c. to be the foundation for 2017 iEHR FOC (Final Operating Capability) and

2) the President’s and Congressional objectives for an integrated DOD and VA EHRS.

VistA was designed by clinicians for clinicians, VistA is patient-centric and embodies the clinical workflow processes that support VA’s models of care; where it has enabled measurable improvements in health outcomes and is central to the VA’s ability to deliver high quality lifetime care to a large and varied Veteran population. “Clinicians consider VistA the best health information system in the world, bar none; at the same time, VistA is very old, very hard to maintain, hard to manage and manipulate, and incredibly expensive to maintain.”

MEDICS EHRS/VistA Core can be “reengineered” in the sense of using iEHR’s n-tiered architecture and OSEHRA’s, open-source, open-standards ecosystem within which the proven functional capabilities of VistA can be replicated, modernized, and enhanced in a sustainable, scalable, and secure environment

The recommended quick-win approach11 boils down to:1. Starting with the iEHR n-tiered architecture; then, encapsulating VistA core with a SOA façade and a

service orchestration adding a DOD business process / workflow & CDS (Clinical Decision Support) layer and data interoperability layer. This reengineered system should be done using a contemporary federated n-tiered SOA ESB, GUI, Cloud-Based (Data Store and processor, Communications) architecture, which is more structured and properly componentized (with components from internal VA development, external development by paid contractors, project grants, and open source community, or commercial off the shelf products).

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


485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530

3233


2. Restructuring the existing VistA system, piece by piece, into a more modular and well behaved application while still using it. (“Change the tires, while the car is still on the road.”) Open-Source software is not free… Twenty approaches were suggested within the VistA Modernization Report:

Innovation and a MEDICS EHRS/VISTA Future State VisionAHLTA has been condemned by its users12; while, VistA has a fervent user acclaim and is known for user driven innovation. We recommend a continuation of stakeholder innovation with an IOC MEDICS core, based on VistA, which supports a natural FOC migration to …

VistA - the core of a Cloud-based MEDICS EHRSThe following is an open source community-based13 recommendation for MEDICS as the core of a Cloud-based Electronic Health Record System (EHRS) and how best to link DoD, VA and partner data going forward. Both topics are relevant for the DoD's MEDICS EHRS RFI, specifically for sections 3.2, 3.7a, 3.9.

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

Secondly, and until recently, the only alternative to such a system was the integrated suite of applications. Like the traditional Microsoft Office, Suite EHRS are built around a common framework, which allows and promotes a great deal of data and component reuse, and they come from a single vendor like Epic, or like the VA's VistA or the DoD's AHLTA, they originate in-house at large institutions. But here what you gain in reuse, you lose in the ability to introduce outside components.

Now there's a third EHRS type, the Cloud-Based. With the advent of high capacity networks and cloud storage which can enable mobile applications that leverage common services and UX framework over a network. An EHRS built this way would have the component reuse and data sharing of the traditional suite, while being open to multiple vendors.

VistA - evolving to a Cloud-based MEDICS EHRSFortunately those who have deployed Suite EHRS can evolve to this more flexible architecture, just as Microsoft made the latest Office a cloud-based suite. Select framework functions needed to move into a cloud equivalent and the current obscure data models need to be comprehensively defined and made easially upgradable.

Is VistA the easiest Suite EHRS to migrate to the Cloud? Consider this - Epic, the other major Suite EHRS, has embedded a great deal of logic in its Visual Basic coded client. VistA, on the other hand, has most of its logic in its server framework. This choice - and the choice of the now obsolete Visual Basic - will make it significantly harder to migrate Epic.

In the EHRS world, VA VistA is an example of this evolution. A networked service (e.g., First Data Bank) for checking drug-interactions has replaced an equivalent in VistA's self-contained, locally accessible framework and that is now working at OSEHRA. This ambitious vision is to fully open VistA up to allow applications from many

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 This section provided by Conor Dowling, Rafael Richards; Carol Monahan; Rick Marshall of Caregraf


531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577

3435

36

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


parties, of all shapes and sizes, in any programming language, to leverage VistA's proven framework over a network.

"Networking the Framework" is a sensible strategy - the advantage of retaining existing functionality is that it is proven. It is often cost-prohibitive to re-engineer all of the special cases and particulars accounted for by a comprehensive framework built over many years.

In VistA's case, networked versions of MEDICS EHRS/VISTA core services - Lexicon, Document Template Management, Order Management, Lab and Drug type mapping services - should free up third parties to focus on novel presentation and newer capabilities. Which leaves full and comprehensive data definition, a MEDICS EHRS/VISTA core Framework's Data Architecture. While it is acceptable to "just know" the shape of data when applications are all local, are all in one programming language, all by one party, a federated networked system requires clear-cut, complete data definition.

The federated MEDICS EHRS/VISTA Networked Framework needs to be explicit about what data it needs, stores and produces. What does a Prescription look like? A Problem? A Surgical Procedure? … these all require Detailed Clinical Models (DCMs). And here OSEHRA can contribute moving VistA forward by managing the fuller definition of MEDICS EHRS/VISTA core framework's data model using the latest standards and technologies.

Two pieces – ESB key services (i.e., networking, common, clinical, financial and administrative) and being explicit about data - allow VistA to evolve into a federated, Cloud-based MEDICS-EHRS, which is open to outside developers and better able to interoperate with other systems. It also makes VistA much more applicable outside the VA, in part because there's no need to adopt it wholesale - it can now mix and match.

DoD, VA and Partner Data - Just Publish and 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 have too-little meaningful-exchange that has taken too long to put in place. With Linked-Data - data on the Web - this can change.

iEHR talks about a Common Information Interoperability Framework (CIIF) for ensuring data compatibility. In Linked-Data, this framework would be a mechanism for analyzing and adding data linkage as would the Concept Manager like 3M's HDD. iEHR also talks about data mobility using a Retrieve Locate Update Service (RLUS); where, in the Linked-Data approach, such a service would be implemented using W3C standards for data update, construction and retrieval.

In Linked-Data, data exchanges use the same architecture and technologies that have proven so successful for hyperlinked documents. Data doesn't hide behind APIs and wrappers. It is fully exposed, as is, with each piece given a URL linked to other URL-carrying data. Every Patient gets a URL, every Vital Measurement gets one too. So does every type of Drug or Observation, every Physician, every Clinic. In this model, an enterprise database, such as Cassandra, is composed of URLS pointing to federated VistA NOSQL data stores; hence, the system-of-record can remain the federated data stores.

On top of this publication is a query mechanism that, like SQL for relational stores, lets analytical CDS systems ask questions, such as What Patients took Drug Such and Such for a particular set of conditions and what were their outcomes? Or in Linked-Data terms, what is the URL of the Patient who took the Drug identified with such and such a URL? Got data in a relational store? There's a Linked-Data tool to publish it all. In a NoSQL store, like VistA's FileMan? There's a tool for that too.


578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628


As the name suggests, Linked-Data is all about Links. The question of whether data is well structured reduces to how many links does it have? The question of whether two data sets are compatible reduces to how interlinked are they? When you publish data this way, you expose its nature and can see how to improve it.

The approach here is "publish everything now and improve as you use", rather than honing a pristine, all-too-small view of data. Exchange of pristine subsets of what's available is replaced by interlinking of fully published data.

Of course not everything that should link links right away. For example, if a Prescription in DoD identifies a drug with a URL based on a HDD NCID, and the VA equivalent has URLs with VA VUIDs, they won't link because both prescriptions identify the same drug using different URLs. But just because they don't immediately link doesn't mean that the VDR (Virtual Data Repository) can’s ultimately add NCID-VUID-SNOMED link(s), as the need arises.

After publication comes analysis of "dead ends", islands of data unlinked outside an organization. How could it link? What data in one organization is the same as data in another and as a result can link up? Bit by bit, through new links, data joins up. While mutual understanding isn't automatic, just by exposing data on the web, the points and amount of misunderstanding, of where links are lacking, becomes clear, and can be automatically quantified and incrementally fixed. Obviously, we don’t expose protected patient data; rather, we are exposing publically available HDD metadata links, which correspond to the data structure.

A data exchange mechanism that can publish both data like the DoD's that is in relational stores and like the VA's that is in noSQL, that supports measurable and incremental improvement - isn't this what both the DoD and VA require?

The DoD is performing market research to ascertain the interest, capabilities, Rough Order of Magnitude (ROM) life cycle costs, and available solutions within the healthcare industry to provide the following:

1. An EHRS core, as defined in paragraph 1, or as recommended by the interested party to meet the purposes of the core.

2. A full EHRS system capable of adding, upgrading, and interfacing with BoB products

RESPONSE: Estimating a rough order of magnitude (ROM) for open-source MEDICS EHRS/VISTA core and capabilities, well before concrete technical information is available on the program being developed, can only be based on a desired capability—or even on an abstract concept—rather than a concrete technical solution plan to achieve the desired capability. Hence the role and modeling of assumptions becomes more challenging. OSEHRA recommends the CMU (Carnegie Mellon University) approach to Quantifying Uncertainty in Early Lifecycle Cost Estimation (QUELCE) conducted by the SEI Software Engineering Measurement and Analysis (SEMA) team.

It should be noted that open-source does not mean free; but rather, many of the DOD specific integration and deployment costs will be the same; regardless of the specific EHRS. However, licensing cost are eliminated for open-source components and innovation is increased; because of transparency to any interested party, be they a clinician at a hospital or a computer scientist in industry. The open-source approach is a Darwinian trial-and-error march to excellence.

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


629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678

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

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


OSEHRA in its established processes.

To Comment on the potential gap in the RFI with respect to Dental, please note that the Veterans Administration’s VistA Dental Record Manager Plus is an enhancement to the base VistA dental record module developed by DSS Inc. who is a contributing member of OSHERA

ii. H a rd w a re Response: Open-source Vista will run on virtual machines, hosted on the blade servers, which the government already plans to deploy at the DISA centers and regional sites. Obviously, system engineering and performance tuning must be done, over time, to maximize the cost-performance of the deployment.

It needs to be remembered that the Core and a limited Full EHRS is required for the Theater, Remote (low/no Communications) settings and there will be a hardware investment, or more likely a coordination of hardware Refresh to the current DoD planning to those sites and much of the above.

Inherently, the recommended VistA solution, with RLUS fronted databases supports the TMIP (Theater Medical Information Program) data integrity approach to a disconnected (no network available) mode. In

detached operations, data is pre-cached in the 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 6 The Recommended MEDICS EHRS/VISTA core 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 particularly in the Military Health System's Pacific Joint Information Technology Center (P-JITC) in Maui. This approach is selected both to save considerable costs and to integrate the parallel paths and phasing that the DoD is engaged in currently. Equally, this is an approach that is focused upon leveraging the current investment in DISA cited in the RFI. Finally, DTC Richmond and the P-JITC are already “equipped” with instances of VistA-CPRS and CHCS, with other external systems linkages either in execution or planning to include DEERS testing instance(s) from DMDC.

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


679

681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726

728729

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


b) 13 academic medica l cen te rs wi th 144,692 admiss ions , 214 ,812 procedures c) 43 community hospitals with 95,017 admissions, 119,875 procedures Response: Considering the 5 February 2013 DOD and VA Secretaries stated milestones14 and the published iEHR 2014 IOC and 2017 FOC milestones, the following milestone schedule is applicable.

Figure 7 High Level MEDICS EHRS/VistA 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/VistA 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 14 On 5 February 2013, the DOD and VA Secretaries stated that “in the short term, that we've agreed to

1. Improve data interoperability to that integrated electronic health record before the end of this year, by standardizing health care data no later than December 2013,

2. Creating health data authoritative source no later than September of 2013, 3. Accelerating the exchange of real-time data between V.A. and DOD no later than December of 2013, and 4. Allowing V.A. and DOD patients to download their medical records , what we call our Blue Button Initiative, no later than May of 2013, and,

finally, 5. Upgrading the graphical user interface , this thing we call the GUI, to display the new standardized V.A. and DOD health care data no later than

December of 2013, 6. Expand the use of the Janus graphical user interface, the GUI , to seven additional sits and its expansion of two DOD sites no later than July

2013 … 7. Select a core of -- core set of IEHR capabilities no later than March of 2013 … 8. Achievement of the president's goal in 2014 … to do everything possible to try to put the health care systems of both these departments

together for the benefit of our troops.”


730731732733

734736737738739740741742743744

3738394041424344454647484950

51


Response: OSEHRA can provide a forum to support change management needs determination.

vi i . S ustainm e nt Response: The OSEHRA open-source community, including providers and developers, can be a catalyst for continual improvement; and, OSEHRA can help manage change, test and certification.

3. Capability Statement Submission ScopeOSEHRA’s RFI response is limited to a conceptual architecture and strategic concepts deems applicable by the open source community, with the expectations that one-or-more commercial venders will provide the tactical details in their RFP responses. This section describes how OSEHRA and the open-source community general approach and capability to respond to the MEDICS EHRS RFP.

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. These systems will be freely available for all medical beneficiaries and – like other successful open source communities – will welcome the contributions of all kinds of developers.

1) Provide the business name and / or team name, a point of contact (POC), address, and DUNS number.Seong K. Mun, PhD, President and CEOOSEHRA - None-Profit Corporation900 N. Gelbe Road, Arlington, VA571-858-3201

2) Provide an indication of current certified business and socioeconomic status; this indication should be clearly marked on the first page of the capability statement.

Response: OSEHRA is a custodial agent and will not respond to any RFP; specifics will be provided by the responding vender.

3) Provide a description of the proposed core capability set, and the full EHRS, that meets the objectives provided in this RFI.

Response: Please see response 3.2.1.a and the VistA description attachment. 4) Provide a description of the company or team’s background, technical expertise, experience, staffing, and other

capabilities that demonstrate its capability to provide the anticipated objectives listed in Attachment (1). Specifically: a) Describe your approach, with a corresponding timeline, to support an initial deployment of two separate

and distinct hospital sites using at least the core, and possibly the entire EHRS, and then to all the remaining DoD medical facilities (i.e., hospitals and clinics). Response: OSEHRA will NOT bid on an RFP; rather, this RFI response provides an open-source MEDICS EHRS/VistA vision, conceptual architecture and strategic vision for the government and its contractors to follow.

b) Describe your Agile approach and timeline to configure and deploy the EHRS at multiple sites and in multiple healthcare environments across multiple time zones, scaling up to world-wide deployments. The Government will provide a product owner who will be embedded in each Scrum team. Describe your management approach to using two-week sprints ending in demonstrations. Response: same as 4.a.

c) Describe your approach to scale the development and integration of complex healthcare systems with greater than five (5) million members. Response: See Figure 11: Proposed Systems Engineering / Integration Approach and Figure 12 ProposedTransition-Strategy for MEDICS EHRS Linkage to Legacy Systems plus associated write-ups.


745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795


d) Describe your approach to implement, configure, deploy, and / or develop, an EHRS using Agile Scrum processes. RESPONSE: OSEHRA and its community, focus on how open source and open architecture can be applied to middleware servers to provide an incremental but rapid path to enterprise transformation that enables development of SaaS (Software as a Service) capability using Service Oriented principles. The convergence of open ESB platforms with Service Oriented Architecture (SOA) principles delivered using Cloud delivery models realizes the vision of Platform as a Service (PaaS) to transform the delivery of IT 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 applications is desired. These adaptors should provide location transparency and service virtualization to all enterprise systems in order to provide business and technical agility. Elastic scalability and high availability are necessary IT attributes for responsive infrastructure. In addition, service virtualization must extend the reach of the SaaS experience to business analysts using BPM (Business Process Modeling) tools to re-engineer and compose new processes. In order for this to succeed, all service endpoints should be optimized to share a common set of management infrastructure. These services must be available regardless of the application servers being used to host the existing business systems. Finally, it must also apply to both service providers and service consumers in order to accurately manage workload and service level agreements (SLA).

Agile Development is more than process. Open Source Software (OSS) follows a federated agile development and test process encompassing engineering agility via modularity. This results in an Open Business Model = OSS + Open Architecture.


796797798799800801802803804805806807808809810811812813814815816817818819

820821822823


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-source ESB can provide portable, embedded smart endpoints that span heterogeneous application servers. These smart endpoints provide a common service management infrastructure independent of the application server. When dedicated integration servers make sense.

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


824825826827828829830831832

833834835836837838


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/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. Details are available at: http://architecture.osehra.org and an MS Word version is available at: http://www.osehra.org/document/osehra-vista-system-architecture-product-definition-and-roadmap-updated-2012-03-06 The follow-on RFP may choose among the following to augment the Figure 3 VistA Core / Figure 4VistA Core Expanded MEDICS EHRS/VISTA Core capabilities; because the following capabilities are immediately available; and, they can be 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 Management8. 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 List18. 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 Process

37. Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form

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


839840841842843844845846847

848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895

896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934


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 Tools

2. Duplicate Record Merge: Patient Merge Name Standardization

3. 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 Unwinder16. 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 Generator33. 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 was done by the US government in an effort to make VistA available as a low cost Electronic Health Record (EHR) for non-governmental hospitals and other healthcare entities.


935936937938939940941942943944945

946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979

980981982

983984985986987988989990991992993994995996997998999

1000100110021003100410051006100710081009101010111012101310141015101610171018

101910201021102210231024102510261027102810291030

1031103210331034103510361037103810391040

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


With funding from The Pacific Telehealth & Technology Hui, the Hui 7 produced a version of VistA that ran on GT.M in a Linux operating system, and that was suitable for use in private settings. VistA has since been adapted by companies such as Blue Cliff, DSS, Inc., Medsphere, and Sequence Managers Software to a variety of environments, from individual practices to clinics to hospitals, to regional healthcare co-ordination between far-flung islands. In addition, VistA has been adopted within similar provider environments worldwide. Universities, such as UC Davis and Texas Tech implemented these systems. A non-profit organization, WorldVistA, has also been established to extend and collaboratively improve the VistA electronic health record and health information system for use outside of its original setting.

VistA (and other derivative EMR/EHR systems) can be interfaced with healthcare databases not initially used by the VA system, including billing software, lab databases, and image databases (radiology, for example).

VistA implementations have been deployed (or are currently being deployed) in non-VA healthcare facilities in Texas,[23] Arizona,[24] Florida, Hawaii,[25] New Jersey,[26] Oklahoma,[25] West Virginia,[27][28] California,[29][30] New York,[31] and Washington, D.C.[25][32]

In one state, the cost of a multiple hospital VistA-based EHR network was implemented for one tenth the price of a commercial EHR network in another hospital network in the same state ($9 million versus $90 million for 7–8 hospitals each). (Both VistA and the commercial system used the MUMPS database).15

Additionally, VistA has even been adapted into a Veterinary Medicine Health Information System (VMACS) at the veterinary medical teaching hospital at UC Davis

International 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: VistA inherently exceeds the Figure 8 Gartner defined Evidence-Based Level 3 CPR16 system containing patient-centric, electronically maintained information about an individual's health status and care, focused on tasks and events directly related to patient care and optimized for use by clinicians. Out of the box, VistA can meet DOD’s MEDICS EHRS/VISTA, legal and administrative requirements for the clinical process. An MEDICS EHRS/VistA CPR system is composed of 10 integrated —— not interfaced —— core capabilities: clinical systems management, interoperability, clinical data repository, Controlled Medical Vocabulary, clinical workflow, clinical decision support, clinical documentation and data capture, clinical display (including clinician dashboards), clinical order management (including computer-based physician order entry), and knowledge management; where, the CPR is also be able to adequately meet the varying needs of all of the MHS care venues, as well as the wide array of clinician types.

15 “Demonstration of M2Web". UC Davis VMTH (Veterinary Medical Hospital) (Dec 2008). http://vista.vmth.ucdavis.edu/notebook/index. 16 To avoid complications, especially as it relates to data ownership issues, Gartner restricts the scope of a CPR system to a single organization; and, the key Gartner findings were:1. Clinical decision support is the single most important CPR capability to assist in the avoidance of medical errors.2. Over time, the CDS system must be able to interact seamlessly with all other CPR components.3. The CDS rule engine must be coupled with an adequate notification system to ensure that critical decisions are made available to caregivers as

soon as possible. WORKING DRAFT 5/8/2023 1:42 PM,

104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082

5253545556

5758

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

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

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

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

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


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


10831084

10851086


As listed in Table 1, “out-of-the-box” MEDICS EHRS/VistA can deliver a Gartner Level 4+ advanced system that provides substantial functionality for nurses, physicians, pharmacists, laboratory and imaging technicians. MEDICS EHRS/VistA plus the iEHR Enterprise Service Bus (ESB) / SOA Suite, Virtual Patient Record and RLUS-fronted federated Virtual Data-Repositories will have decision support, workflow capabilities and tools that permit the DOD MHS to more easily bring EBM to the point of care; where, this out-of-the-box Level 4 MEDICS EHRS/VistA core CPS platform is the perfect foundation to evolve the MHS to a full Level 5 CPS enterprise.

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


10871088

1089109010911092109310941095109610971098


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 the current rule set 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/VistA will be a flexible system that supports multiple test methodologies. DOD can implements a complete spectrum of test methodologies that support development and maintenance of a complex EHRS system, including developer unit test, functional system test, interoperability testing,


10991100

110111021103110411051106110711081109111011111112111311141115111611171118111911201121

1122112311241125112611271128112911301131113211331134113511361137113811391140

11411142114311441145114611471148114911501151

115211531154115511561157


performance testing, 508 accessibility testing, DOD 8500.2 IA and system stress testing, many of these can first be done transparently at OSEHRA for minimum cost and maximum effectiveness.

a) Provide / describe any empirical test evidence that your EHRS performs as expected in the intended user or similar environment. Describe the scalability of your EHRS. Response: The production implementation of VistA at VA’s scale, across more than 1500 facilities and more than 6 million patients, achieving high quality health care outcomes and exceptional system reliability, demonstrates the ability of VistA to perform in DoD’s intended user environment.

b) Describe your capability to support an Agile testing process that requires early inclusion of users and Government technical specialist operating in a team to manage and report on development / integration / testing activities in two-week sprints. What program(s) have you supported in this capacity and what were the associated products(s) / capability? Response: Most VA software development, as well as contracted software development, is performed according to Agile processes. Core VistA development and significant new programs such as the hi2 Health Management Platform, My HealtheVet, and the Connected in Health platform are all developed using sprint-based Agile processes, including test at the developer and system level.

Agile development requires flexible test tools that can be rapidly configured for the tasks in each sprint. VA has developed two such tools for use in VistA development and deployment: an automated system test platform and a tool for system data analysis.

A platform for automated system-level functional test allows developers and testers to rapidly script functional tests that focus on the features under test provides a powerful tool for Agile test practices. Test scripts can be written in a simple scripting language or they can be automatically generated by recording user actions during test scenarios. All test scripts, custom and auto-generated, may be run as fully automated regression tests.

Analyzing and testing the MEDICS EHRS/VistA involves more than the checking of code; much of the power of VistA is captured in system data: templates, menu options, data dictionaries, file structures, etc. VA engaged the open source community to develop a tool that analyzes system data and compares two VistA instances (for example, a “gold” version vs. a unit under test), allowing developers to rapidly verify that any changes to system data are appropriate.

Both test tools are available via OSEHRA.


1158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191


3.4 Integration Describe your approach to integrating your EHRS into the DoD environment as described in paragraph 1.

Figure 9 RLUS is used to Integrate with Legacy Systems’ Data17

RESPONSE: The recommended solution illustrated directly above and detailed-out directly below should be fully integrated and use both legacy VA/DoD systems, user interfaces and the MEDICS EHRS/VISTA system, as a whole, including the IOC and FOC JSR 286 standard portal/portlet UX frameworks with WSRP (OASIS Web Service for Remote Portlets). All data will be written back to legacy system and MEDICS EHRS/VISTA IOC and FOC repositories using RLUS, Mirth and Level7 SSG with standard data XML content formats, based on the canonical information and terminology models and transformations appropriate to the respective repositories. The 3M-HDD will manage the data semantics/ quality among systems.

17 From Technical Specification Summary available at www.tricare.mil/iEHR WORKING DRAFT 5/8/2023 1:42 PM,

11921193

119411951196119711981199120012011202

59



Figure 10 User Experience (UX) is Thoroughly Integrated into MEDICS EHRS/VISTA and Legacy using RLUS18

The following annotation applies to the figure above:[1] User Experience (UX) Standard XML Form Language (XForms) Generation[2] Multiple Display Platforms[3] Clinician and Patient Sourced Data Updates[4] Use of Common Information Interoperability Templates and Value Sets[5a] Communication between UX and Care Coordination Capability[5b] Use of Analytics Capability within UX[6] Coordination with Care Record Capability[7] Coordination with Health Concern Tracking Capability[8] Coordination with Care Plan Management Capability[9a] Interaction between Care Record Capability and Care Plan Management Capability[9b] Interaction between Care Record Capability and Health Concern Tracking Capability[9c] Interaction between Care Plan Management and Health Concern Tracking Capabilities[10a] Data Management via Retrieve Locate and Update Service (RLUS)[10b] Communication with Legacy Systems via RLUS[10c] Communication with MEDICS EHRS/VISTA Integrated Clinical Data Repository via RLUS[11a] Use of Enterprise Data Warehouse by Analytics Capability[11b] Real-time Population of Enterprise Data Warehouse (EDW) by RLUS[12a] Inputs and Outputs of Clinical Decision Support (CDS) Capability[12b] Generation of Alerts Reminders and Notifications by CDS Capability[12c] Order Management Capability Interactions with the Care Coordination Capability

18 From Technical Specification Summary available at www.tricare.mil/iEHR WORKING DRAFT 5/8/2023 1:42 PM,

Clinical Template

Repository

120312041205

120612071208120912101211121212131214121512161217121812191220122112221223122412251226

1227

60



Figure 11: Proposed Systems Engineering / Integration Approach19

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 12 Proposed Transition-Strategy for MEDICS EHRS Linkage to Legacy Systems20

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

19 Adapted from Technical Specification Summary available at www.tricare.mil/iEHR20 Adapted from Technical Specification Summary available at www.tricare.mil/iEHR


12281229123012311232123312341235

12361237123812391240

6162




potential gateways on the security boundaries of each system / organization. The common GUI and common services may reside in some new joint security domain, where data stores are federated across 6–8 regional DISA data centers. There will likely be local data caches to meet performance requirements. Using the RLUS and HDD, the MEDICS EHRS/VISTA initiative will allow the retirement of the legacy Clinical Data Repository/Health Data Repository (CHDR), Bidirectional Health Information Exchange (BHIE), and the Federal Health Information Exchange (FHIE) information-sharing systems, and will ultimately allow appropriate computable information sharing with VA and external partners, via VLER .

Most legacy applications cannot be just turned off immediately. It is possible with current technology to replace the front-end aspect of most legacy applications. Initially, legacy inclusion is essential with a phased sunset or refactoring of legacy applications either from a front-facing GUI and backend data store aspect. There will be a plan for rolling out new capabilities that replace or repurpose legacy capabilities with some phased approach to access to historical data and intermingling of capabilities during the phase-in period. In some cases, there is benefit to moving to a commercial application and replacing its front-face because the application does not present a unified MEDICS EHRS/VISTA view to the user. As commercial applications begin to be included, work with those vendors must be provided in tandem to provide a unified “style” to the application front end, within the iEHR / MEDICS EHRS presentation GUI.

The advantage of the RLUS + HDD approach is that it decouples complex implementation schemas, allowing the DOD to choose when and how they upgrade their legacy systems to the MEDICS EHRS/VISTA common GUI, common services, common information structure, and common terminology approach. This is also practical path to DOD-VA integration, resulting in a single logical Virtual Patient Record (VPR) for each patient. The approach is based on freely available national and international standards (e.g., SNOMED-CT, LOINC, RxNorm) and allows the reuse and repurposing of existing components, supporting the independent transition of each agency’s healthcare IT. Common tools can centrally manage the accumulation of knowledge within the information and terminology models and services. As the iEHR / MEDICS EHRS/VISTA Program (s) move forward, the need for translation services is diminished for partners who elect to implement HDD access21 natively in their products. Note that there is always a need to harmonize different versions of terminologies, code sets, and value sets, which evolve over time.

Currently, the agency systems, their existing and required information exchanges, and a high-level specification of the necessary MEDICS EHRS/VISTA system functions, capabilities, and services are known. Simulations and appropriate prototypes to add fidelity to the interoperability specifications, performance parameters, capacity planning, and independent government cost estimates will need to be done. This must be done for the iEHR / EHRS final state, as well as the need to simulate and appropriately prototype the legacy systems transition phases from the as-is state through a sequence of transition states to the MEDICS EHRS/VISTA objective state

The MEDICS EHRS/VistA architecture can be designed to comply with the DOD and VA information security requirements and take into account the allowable ports and protocols allowed to transition across the Information Assurance (IA) boundaries. Additionally; as DOD reacts to different IA threats, stricter Information Operations Condition (INFOCON) controls and restrictions will be imposed at the DOD IA boundary. At the highest INFOCON level, there is a possibility that all communications through the DOD IA boundary will be curtailed. The MEDICS EHRS/VistA integration architecture design must take this into account, as a part of the Continuity of Operation Plan (COOP), with local Virtual Patient Record caches.

3.6 Network and Security Architecture a) Describe your approach to network and security solutions. The Government intends to use a dedicated

health network that will run on the Defense Information Systems Network (DISN) as a logical network as 21 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.


124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288

636465


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

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

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

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

the implementation of an EHRS and its integration into the DoD environment. Response: The recommended MEDICS EHRS/VistA core database (fileman) is written in MUMPS and has Service wrappers, which support Java or C++ or C# .net or Delphi calls. This strategy supports the flexibility to integrate “Best-of-class” component integration. MEDICS EHRS/VistA can be run on a proprietary Windows/Cache’ environment or an open-source Linux/GT.M environment; where, both environments have had extensive use and testing. From a hardware perspective, the MEDICS EHRS/VistA can run on the DOD commodity blade processors running load-managed Virtual-Machines to provide the best cost-performance at DISA centers, regional sites and local or deployed systems. The system architecture starts with the Figure 4 VistA Core Expanded running on the Windows/Cache’ or Linux/GT.M environment within the Figure 2 n-tiered Open-Source MEDICS EHRS/VISTA Conceptual Architecture federated across DISA centers and MHS Regional sites and hospitals. Database shadowing will be used to put local data within the MHS Clinical Data Repository (CDR) and/or iEHR enterprise data store.

b) Describe any hardware or software requirements that are necessary to implement your EHRS (e.g., databases, severs, bandwidth, etc.). RESPONSE: The proposed MEDICS EHRS/VistA core will integrate into the IEHR ESB/SOA Suite, as shown in Figure 2 n-tiered Open-Source MEDICS EHRS/VISTA Conceptual Architecture.

c) Describe your approach to data storage solutions. The Government is interested in your assessment of using multiple regional data centers in a federated architecture, with multiple virtualization sites located closer to the care delivery organizations (CDOs). Response: The key to practical federation is having an HL7/OMG specified Standard RLUS (Retrieve, Locate, Update Service) API façade for all databases, as is shown in Figure 11. Multiple regional data centers in a federated architecture, with multiple virtualization sites located closer to the care delivery organizations (CDOs) is essential to cost-performance tuning. Additionally, the Virtual Patient Record (VPR), shown in Figure 2, is an additional cache, which is critical to managing the cost-performance and disaster capability recovery of the Figure 2 architecture.

d) Describe your approach to disaster recovery. Response: The recommended MEDICS EHRS/VistA core supports LCS (Local Cached Storage) aka VPR

for dynamic performance-tuning and a graceful COOP (Continuity-of-Operations) in the event connectivity is lost to regional DISA centers.

Additionally, the recommended solution supports the TMIP (Theater Medical Information Program) data integrity approach to a disconnected (no network available) mode. In detached operations, data is 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


12891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338


recommended RLUS, UX framework and (ideally open-source) HSP components make porting capabilities to multiple-types of mobile or detached-platforms simpler and less costly.

3.8 Identity Management a) Describe your approach to using an external identity management system in your EHRS. The Government

intends to use the Defense Manpower Data Center (DMDC) who provides an external identity management service and a unique electronic data interchange personal identifier (EDIPI).

Response: The recommended MEDICS EHRS/VistA architecture treats DMDC as a service provider, augmented with disaster recovery and detached operations caching capabilities.

b) Describe your approach to identity management and access control for individuals who have more than one role (patient, provider, dependent, etc.).

Response: As in the VA, DOD EHRS/VistA Identity Access Management (IAM) services should separate the user identity, established through various electronic measures (PIV, CAC, and Federation Partners - including DS22 Logon), from management of roles. When a user authenticates, the user’s credentials are mapped to their roles. In this manner, support is provided for both coarse and fine grain access controls enforceable from various points in the architecture. Services for Role Provisioning, Role Attribute Query, and Role Enforcement are designed with open standards such as LDAP, SAML, XACML, SPML and others to meet the highest interoperability goals. For example, AcS Specialized Access Control (SAC) service can provide fine-grained access control for applications and services like a doctor’s attempt to self-prescribe medication.

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

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

Response: The recommended MEDICS EHRS/VistA approach for the IAM (Identity Access Management) internal Single Sign-On is for the UX component be the entry portal to support both legacy and new application development efforts. Legacy applications can be SSO-enabled through the use of the Identity Access Management (IAM) Single Sign-On Internal (SSOi) service. The key to the IAM SSOi solution is the flexibility to support both existing and new applications with varying degrees of integration to support the specific business need. The IAM SSOi service supports certificate-based authentication including VA PIV and DOD CAC and is partnered with the Specialized Access Control (SAC) service to provide an end-to-end security solution.

d) Describe your approach to Context Management capability and the ability to extend it to products that might be added in the future.

Response: The recommended MEDICS EHRS/VistA approach for context management is for the UX component to be the entry portal to support both legacy and new application development efforts. In the short term, MEDICS EHRS/Vista might use the Sentillion patient context management in a centralized and/or decentralized manner. Via the UX framework, applications are integrated with the context manager in order to set the patient context; on the backend, the context manager integrates with the patient identity management to verify and validate the identity of the patient context and set all other relative identifiers (i.e. EDIPI, ICN, VistA IEN, CHCS IEN) in context. As we integrate into iEHR, context Management should include session management and the development of SOA based services that will streamline integration with new COTS products.

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


133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386

6667


3.9 Data a) Describe your data strategy, including storage, persistence, data model, architecture, security, distribution,

transformation, and presentation; and how you will provide standardized and normalized data sharing between the DoD and VA using with the 3M HDD. Response: The recommended approach to run-time configurable reporting is to use the new HL7 Consolidated CDA23 and HL7 Fast Healthcare Information Resource (FHIR)24 to define semantically interoperable documents, which can be exchanged or printed.

The VistA data model is open and in the open source community. The Data Architecture Repository allows searching of data fields and allows developers to maintain data integrity; honoring parent/child relationships, for example. Descriptions of the VistA data model can be found under the Architecture link at http://architecture.osehra.org.

VA uses ICD-9 (with work underway to move to ICD-10), CPT, DRG, DSM, HCPCS, CDT, NDC, LOINC and other terminologies for the coding of medical records and data fields. SNOMED for problem list is currently in beta testing with CPRS 29; full deployment will occur in 2013. This accelerates DOD’s ability to meet Meaningful Use Stage 2 standards.

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

23 The proposed rule for Meaningful Use Stage 2 and its companion rule for standards and certification criteria for EHR technology promote the use of single standards for communicating information in certain transactions. The proposed rule establishes the Consolidated Clinical Document Architecture (CDA) as the single standard for communicating the summary of care. The Consolidated CDA is based on components of two standard formats that were previously required for certified EHRs: the Continuity of Care Record (CCR) and the Continuity of Care Document (CCD). This format was chosen as the standard for communicating the summary of care since it can accommodate all data elements that CMS proposes providers give their patients after office visits. Health Level 7 (HL7), an accredited standards development organization, created a single implementation guide for the Consolidated CDA, which was released in December 2011 in an effort to reduce ambiguity and eliminate conflicts in documentation; where, the Consolidated CDA solution encompasses a library of reusable CDA templates, setting the stage for streamlined development and quicker implementation. The templates allow for incremental interoperability and easier machine-to-machine communication, thereby facilitating the transfer and storage of more data.

24 Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "Resources" that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for a range of interoperability problems. The simple direct definitions of the resources are based on thorough requirements gathering, formal analysis and extensive cross-mapping to other relevant standards. A workflow management layer provides support for designing, procuring, and integrating solutions. Technically, FHIR is designed for the web; the resources are based on simple XML, with an http-based RESTful protocol where each resource has a predictable URL; where possible, open internet standards are used for data representation.


138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419

68697071727374757677

78798081828384

http://architecture.osehra.org/



is indexed to optimally support the Solr search engine. The VPR is populated from all VistA databases and can accept data from multiple other sources.

VA’s CDW supports enterprise-wide analytics. Individual VistA instances update regional data warehouses; the regional data stores are aggregated in the CDW. Data is normalized in the CDW and the warehouse is optimized for analytic use; this database design facilitates the development and support of multiple data marts that can be developed quickly to meet the needs of the end users.

Should DoD adopt VistA as its core EHRS, data sharing between VA and DoD medical facilities can be easily accomplished via the enterprise architecture employed by VA. Each MTF/VAMC has rapid access to patient data in its local data store; patient data stored at non-local facilities can be located via the MVI. While patient data can be shared via electronic exchange of Blue Button or continuity of care documents, perhaps via eHealth Exchange, a database-level sharing of data is far superior. Sharing of data for analytics can be accomplished by federating VA’s CDW and DoD data stores such as the CDR and the Air Force Health Services Data Warehouse.

b) Describe your data management approach to address scale, data format (structured, unstructured, 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.).


14201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469


Response: VistA’s data model makes all system and patient data available to applications. No export, import, or explicit exchange of data between system components such as Pharmacy, Lab, etc. is required. This level of integration allows workflow, orders, and decision support to operate with a complete view of patient data, decreasing opportunities for errors that may impact quality of care and patient safety.

Handling legacy data, specifically integrating CDR data with MEDICS EHRS/VistA instances, is handled in two phases. In the first phase, legacy data resides in CDR and is extracted and displayed with VistA data using the Janus user interface. Note that in this scenario, all VA data and all new (post-DoD deployment of VistA) is handled in VistA; only legacy DoD data in CDR requires integration in the clinical display.

In the second phase, CDR data is extracted and loaded into one or more VistA databases. Once loaded, the legacy data is available to any interconnected MEDICS EHRS/VistA system and is thus available throughout the DoD network and the VA network (providing appropriate network connectivity and RLUS integration is implemented).

d) Describe the ability of your EHRS to support data operations offline (if appropriate), to include data availability, replication of data between servers, resynchronization of data, automatic conflict resolution for concurrency issues, and modification of the data. Response: Mobile Electronic Documentation (MED) provides staff in non-connected environments the ability to view a medical record, document, and place orders when connectivity is not possible; data is synchronized when connectivity is restored. Both VistA and Master Veteran Index (MVI) support this capability; if the enterprise MVI is not available, local identifiers are created and used at the disconnected VistA site until the centralized system is available. When the MVI is again reachable, all identities and identifiers are reconciled and any anomalies are resolved.

e) Describe how your EHRS would support data federation across repositories external to the boundaries of your EHRS, and how you would approach data migration from the Clinical Data Repository (CDR) to your EHRS data store, and federation of your EHRS data store with VA and other systems. How would you account for data volume and performance requirements? Response: The proposed MEDICS EHRS/VistA inherently supports continued support of legacy systems during the migration of data, as is shown in Figure 5 Proposed MEDICS EHRS/VISTA Logical System Architecture and Figure 9 RLUS is used to Integrate with Legacy Systems’ Data.

It is worth noting that VA’s enterprise-wide VistA implementation is, in effect, a federation of individual VistA instances, each with its own local data store. Patient data that is stored in multiple locations, or patient data that must be accessed from a remote location, can be located via the MVI, which has a record of the sites at which patients receive care.

Should DoD adopt VistA as its core EHRS, all post-VistA-deployment patient data would be in a common system and both VA and DoD data could be accessed in the same way that VA accesses data today.

Legacy CDR data can be handled in two phases.First, while the legacy data resides in the CDR, the Janus GUI is used to retrieve data from the CDR and from VistA and present it together. It is transparent to the clinician whether the patient data is coming solely from VistA, solely from the CDR, or some combination of the two. Unlike the current deployment in joint 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


14701471147214731474147514761477147814791480148114821483148414851486148714881489149014911492149314941495149614971498149915001501150215031504150515061507150815091510151115121513151415151516151715181519


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/VistA inherently supports continued support of legacy systems during the migration of data, as is shown in Figure 5 Proposed MEDICS EHRS/VISTA Logical System Architecture and Figure 9 RLUS is used to Integrate with Legacy Systems’ Data.

Once DoD facilities are up and running with VistA, it is not necessary to maintain support of legacy systems. Since VistA can be brought up at each site independently, each legacy system can be shut down independently when the local facility is comfortable that the VistA instance is fully operational and that staff are ready. There is no need to coordinate a network-wide switchover.

Describe either the use of a federated data model that serves as the single authority for patient data, or a single physical data repository that provides global access, and the expected performance of your recommended EHRS.

The VistA database serves as the single authority for patient data. Because patient data can be accessed remotely, and the MVI maintains the local of patient data, it is not necessary to build a single, central data repository in order to provide global access. The performance of the EHRS is, for the vast majority of interactions, determined by the performance of the local VistA instance and not a clinician concern, even at VA’s largest installations.

g) Describe either the use of a federated data model that serves as the single authority for patient data, or a single physical data repository that provides global access, and the expected performance of your recommended EHRS.

Response: The proposed MEDICS EHRS/VistA inherently supports both federated instances of MEDICS EHRS/VistA at regional and local, including detached, environments and shadow database transactions to a centralized “cloud-based” “big-data” NOSQL Central Data Warehouse (CDW). Local VistA database instances support high performance Operational Data Store needs and the VistA NOSQL CDW supports CDS analytics and reporting.

VA is an active participant in the eHealth Exchange effort and has developed VA connectors to enable exchange of VA data via Direct and Connect.

VA has developed code to handle the extraction of patient data from VistA and the formatting of exchangeable health summary documents. This code has been wrapped as a web service (as part of the MDWS suite) and is used by the MyHealtheVet platform to build a C32 Continuity of Care Document version of the Blue Button personal health record.

VA also has a pilot project that has implemented the transmission of medical images (from VistA imaging) to external providers using Direct protocols. We expect that the ability to exchange Blue Button files, including images, via Direct to be launched in production later this year.

h) Describe your approach to using the eHealth Exchange from the Office of the National Coordinator (ONC), Health and Human Services (HHS), and the Connect protocol and the Direct protocol to exchange data with the private sector.

Response: The proposed MEDICS EHRS/VistA proposes the Figure 2 n-tiered Open-Source MEDICS EHRS/VISTA Conceptual Architecture, This architecture incorporates the DOD and VA VLER capabilities; where, VLER uses the eHealth Exchange from the Office of the National Coordinator (ONC), Health and


152015211522152315241525152615271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555155615571558155915601561156215631564156515661567156815691570


Human Services (HHS), and the Connect protocol and the Direct protocol to exchange data with the private sector. The more recent secure SMTP Direct protocol can be easily added within VLER.

3.12 User Interface Describe your approach for the system user interface, to include, but not limited to, the ability to support the user interface configuration and customization. Describe your approach to implementing a third-party user interface with the EHRS. Response: Building on the recent establishment of Janus as an open-source Graphical User Interface (GUI), we25 propose the adoption of a flexible, open GUI framework that will support a number of complementary modular, interchangeable and reusable interfaces. Due to the complexity of user-based needs and specialties that requires a flexible interface design, this framework will help establish best-practice designs but provide flexibility in allowing users to customize the modules most appropriate for their needs within a widget-based framework.

Much like a smart phone or tablet’s interface allows for a great deal of customization of buttons or widgets relevant to the end user, so must an EHR establish the same level of usability amongst both patients and providers. HealthBoard is one example of a new open-source GUI framework available through OSEHRA. Originally developed for the Patient Centered Medical Home, HealthBoard can complement Janus by providing additional modules. An open GUI framework would support such an exchange of interface designs and modules. The framework would also be capable of growing to support existing MEDICS system architecture requirements while allowing flexibility in their appearance.

Figure 13 HealthBoard button homepage example.

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


15711572157315741575157615771578157915801581158215831584158515861587158815891590

15911592

8586


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

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


15931594

15951596


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.


1597159815991600

1601160216031604160516061607


Response: The proposed MEDICS EHRS/VistA integrated with iEHR’s IBM ESB / SOA Suite and the open-source Druels provide the Business Logic integration Platform which provides a unified and integrated platform for Rules, Workflow and Event Processing, which can be configured through a UX portlet GUI.

The recommended approach to run-time configurable reporting is to use the new HL7 Consolidated CDA 26 and HL7 Fast Healthcare Information Resource (FHIR)27 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.

26 The proposed rule for Meaningful Use Stage 2 and its companion rule for standards and certification criteria for EHR technology promote the use of single standards for communicating information in certain transactions. The proposed rule establishes the Consolidated Clinical Document Architecture (CDA) as the single standard for communicating the summary of care. The Consolidated CDA is based on components of two standard formats that were previously required for certified EHRs: the Continuity of Care Record (CCR) and the Continuity of Care Document (CCD). This format was chosen as the standard for communicating the summary of care since it can accommodate all data elements that CMS proposes providers give their patients after office visits. Health Level 7 (HL7), an accredited standards development organization, created a single implementation guide for the Consolidated CDA, which was released in December 2011 in an effort to reduce ambiguity and eliminate conflicts in documentation; where, the Consolidated CDA solution encompasses a library of reusable CDA templates, setting the stage for streamlined development and quicker implementation. The templates allow for incremental interoperability and easier machine-to-machine communication, thereby facilitating the transfer and storage of more data.27 Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "Resources" that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for a range of interoperability problems. The simple direct definitions of the resources are based on thorough requirements gathering, formal analysis and extensive cross-mapping to other relevant standards. A workflow management layer provides support for designing, procuring, and integrating solutions. Technically, FHIR is designed for the web; the resources are based on simple XML, with an http-based RESTful protocol where each resource has a predictable URL; where possible, open internet standards are used for data representation.


160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640

88899091929394959697

9899

100101102103104



BIRT also supports reusability by allowing common data and graphical components to be shared across reporting artifacts. These library components are referenced by reports, meaning changes are automatically reflected to the end user without the need to update reports.

BIRT specifically or in part addresses points 2.1, 2.3, 2.9, 2.10, 2.11, 2.12, 2.14, 2.15, 3.4, 5.2, 5.3, 5.4, 5.6 of Attachment (1) Anticipated Electronic Health Record System Objectives.

MEDICS EHRS RFI Attachment (1) – Anticipated MEDICS EHRS/VistA Objectives The following paragraphs provide a list of anticipated objectives to be met by the DoD EHRS.

1. General Objectives The general objectives include the following:

1. Replace the current DoD systems with an EHRS that is at least a Generation 3 EHRS, or later generation, as defined in Gartner's “Criteria for the Enterprise CPR”, Published: 29 June 2007

2. Provide better performance than existing DoD EHRs 3. Provide longitudinal medical record for each beneficiary that is globally available across all time zones (24/7/365) and full range

of military operations 4. Improve electronic exchange of medical and patient data between the DoD and their external partners

Response: The proposed MEDICS EHRS/VistA meets or exceeds these objectives, as presented above

2. Clinical Objectives The clinical objectives include the following:

1. Provide ability to view legacy and external data 2. Provide a configurable user interface to enable tailoring of the clinician workflow 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


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


16411642164316441645164616471648164916501651165216531654165516561657165816591660166116621663166416651666166716681669167016711672167316741675167616771678167916801681168216831684168516861687168816891690169116921693169416951696



4. Program Management Objectives The program management objectives include the following:

1) Ensure the program has a well-defined risk management approach 2) Plan and execute a user acceptance and adoption strategy that mitigates identified adoption risks and is responsive to the

changing needs of DoD’s clinician workforce 3) Provide a transition strategy that minimizes disruption to operations 4) Provide and eventually move all inter-related components of the EHRS to the appropriate DoD sustainment activity 5) Provide a program approach that utilizes the Agile Scrum methodology to include product configuration, development,

integration, and clinical, technical, and management engagements Response: OSEHRA will NOT bid on an RFP; rather, this RFI response provides an open-source MEDICS EHRS/VistA vision, conceptual architecture and strategic vision for the government and its contractors to follow; in which, the Program Management Objectives (listed above) should be achievable.

5. Technical Objectives The technical objectives include the following:

1) Configure the EHRS to interface with medical devices and respective data 2) Deploy an EHRS that has the ability to exchange data in non-proprietary formats, using federally approved health data exchange

standards 3) Deploy an EHRS that uses an open and standards-based information / data model 4) Deploy an EHRS that has standardized and open Application Program Interfaces (APIs) 5) Deploy an EHRS whose underlying and supporting technologies are designed to support extensibility, and supports

interoperability with separately developed capabilities 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


169716981699170017011702170317041705170617071708170917101711171217131714171517161717171817191720172117221723172417251726172717281729173017311732173317341735173617371738173917401741174217431744174517461747174817491750175117521753175417551756



OSEHRA/VistA System Architecture Core MEDICS EHRS/VistA can support both ambulatory and inpatient care; where the most significant capabilities are computerized order entry (medications, special procedures, X-rays, nursing interventions, diets, and laboratory tests), bar code medication administration, electronic prescribing, and clinical guidelines. OSEHRA/VistA details are available at: http://architecture.osehra.org and an MS Word version is available at: http://www.osehra.org/document/osehra-vista-system-architecture-product-definition-and-roadmap-updated-2012-03-06 The separate system architecture summarizes the OSEHR Product Definition, VistA subsystems, GT.M and Caché environments, LINUX and MS Windows platforms and optional components. In summary, the attached "Product Definition" is the inventory of modules, which comprise OSEHRA/VistA, where:

The FOIA release is the “core” set of modules. We flag FOIA modules, no longer used by the VA (e.g., HealtheVet) We list non-mumps modules used by the VA with appropriate comments. We list non-FOIA open-source and commercial modules used by the VA with appropriate comments/links. We list the 4 regional and 1 administrative class 2 modules with appropriate comments. We list VA approved class 3 modules, used by individual hospitals with appropriate comments/links. We list re-factored and in-flight modules with appropriate comments. We list the Cache environment & related modules as the primary VA platform. We list the GT.M environment & related modules as the available open-source platform. We include links to the Visual Cross Reference tool, source code/package directory, documentation Wikis, discussion groups,

tests and entries per package.

Note that a particular build will require the selection of a subset from the OSEHRA/VistA Product Definition; as an example there may be alternative modules, which do the same function (e’g’, graphical user interfaces).

For each module, we define: Module grouping (e.g., Clinical, Admin/Finance/ HealtheVet) Class (e.g., 1, 2, 3) Core FOIA (yes/no) Module Name FOIA Package Name) Version Namespace Patch Number Comment


17571758

175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791