Electronic Health Record-Q and A.pdf

PDF 229 KB Posted

Attached to
RFQ 80JSC025Q7001 Electronic Health Record
Solicitation number
80JSC025Q7001
Issued by

About this file

This is a Q&A document for NASA Johnson Space Center's RFQ seeking to replace their current Electronic Health Record (EHR) system. The document contains 47 questions and answers covering technical requirements, implementation, security compliance, and procurement details.

Key details include: NASA currently uses athenaFlow as their core EHR and is upgrading from v22 to v24. The new EHR must be an on-premises implementation with go-live no later than 7/7/2026. NASA requires on-site support during go-live and will not consider cloud-hosted solutions, as previous cloud migration attempts were determined to be inferior in performance and cost. The system must support Multi-Factor Authentication and integrate with existing pharmacy systems (currently using Frameworks LTC). Data migration will be jointly performed by the vendor and NASA IT staff. The procurement is being competed under FAR part 13, and there will be no opportunity for oral discussions or revisions after initial quote submission. Virtual demonstrations must be conducted via Microsoft Teams. While NASA does not have a preferred EHR vendor, products must be ONC HIT certified at the time of proposal submission. The current EHR system is managed by NASA and NASA's IT support contractor with minimal vendor assistance.

View the file

Other files

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Electronic Health Record

Q & A

General Clarifica ons

1) Could you provide the details of exis ng EHR systems/COSTs products? NASA currently u lizes athenaFlow as the core EHR and is in the process of upgrading from v22 to v24 to support the meline to transi on to the new EHR (athenaFlow sunsets versions roughly every three years). Numerous other programs are u lized to provide func onality to the broader EHR. The provided language combined with figures and diagrams within A achment A: NASA EHR Replacement PWS should provide addi onal insight.

2) Could you also share the pain areas and challenges in exis ng EHR systems/COSTs?

The current EHR is func onal but presents some challenges for NASA. It lacks Mul ‐ Factor Authen ca on required by the government, requires mul ple third‐party modules to meet the government’s needs, and given that the system is twenty years old, it lacks some of the func onality of modern EHR systems. These factors contribute to a system that requires significant effort to maintain.

3) What are the specific areas of need, or shortcomings, that lead JSC to iden fy its exis ng EHR systems needs to be replaced? NASA began exploring an EHR so ware replacement when the current vendor indicated that the exis ng applica on may fully sunset in the future.

4) Could you confirm if NASA has a preferred EHR vendor or an incumbent provider currently in place? And Who is the incumbent managing the current EHR system? NASA does not have a preferred EHR vendor. The current EHR so ware system is managed by NASA and NASA’s IT support contractor with minimal assistance from the vendor.

5) Are there any mandatory cer fica ons or regulatory compliance requirements (e.g., FedRAMP, HIPAA, NIST 800‐53)? Mandatory cer fica ons are listed in A achment A:

NASA EHR Replacement PWS.

6) This effort has PoP of Base +4 Op on Periods, is it NASA’s intent to migrate this data repository to the cloud? If yes, what is the planned meline? NASA does not have a meline for moving the EHR into the cloud.

7) The PWS states, “The deployment of a COTS EHR so ware solu on at Johnson Space Center, with an effec ve go‐live date no later than 7/7/2026, using an on‐premises implementa on.” Please describe any par cular advantages gained by NASA by maintaining an on‐premises implementa on versus a cloud implementa on. NASA JSC a empted a complete cloud migra on of JSC Clinic applica ons, which included the Electronic Health Record applica on, approximately three years ago. It was determined that integrated performance and recurring cost of running clinic applica ons in the cloud was inferior to the legacy on‐premises implementa on.

Challenges not directly involving the EHR applica on must be addressed before another a empt to migrate the Clinic‐to‐the‐cloud is a empted. There is currently no projected meline to address these challenges.

8) What has driven your replacement of your current vendor, other than specified procurement regula ons? NASA began exploring an EHR so ware replacement when the current vendor indicated that the exis ng applica on may fully sunset in the future.

9) What specific procurement rules are driving your decision to change your Electronic Health Record? Procurement rules are not driving the decision to change to a new EHR. NASA began exploring an EHR so ware replacement when the current vendor indicated that the exis ng applica on may fully sunset in the future.

Technical Requirements

10) Can you provide clarifica on on the minimum hardware and infrastructure requirements outlined in PWS Sec on 2.2? The hardware listed in 2.2 is the Virtual Environment that contains the current EMR and other servers.

11) Regarding HL7 bidirec onal data exchange, are there specific security protocols NASA expects beyond the standard HL7 FHIR and WSDL integra on? In general, we require protec on of Data‐At‐Rest (DAR) and Data‐In‐Transit (DIT). SSL/TLS is required for all connec ons to ensure data is encrypted in transit.

12) Are there any addi onal legacy systems or third‐party applica ons that must be integrated with the proposed EHR solu on apart from PACS and ImmTrac2?

Informa on on legacy systems and third‐party integra on is provided in the language, figures and diagrams within A achment A: NASA EHR Replacement PWS.

13) What are the data migra on expecta ons from the exis ng EHR system? Will NASA provide historical data, or is data extrac on part of the vendor’s responsibility? Data migra on is expected to be part of installa on and implementa on jointly performed by the vendor and the NASA IT staff.

14) Should the proposed EHR support mul ‐tenancy, or will it be a dedicated single‐ tenant environment? Dedicated single tenant.

15) The Technical Specifica ons require compliance with ONC HIT cer fica on. Would NASA consider a solu on for a COTS EHR product that is in the process of being cer fied? Products shall be ONC HIT cer fied in the categories iden fied within A achment A: NASA EHR Replacement PWS at the me of proposal submission.

16) Will there be an opportunity to conduct a technical assessment of the current EHR infrastructure before migra on begins to be er understand requirements for the system/workflow and data migra ons? This will be done during the implementa on phase of the project.

17) Can you please describe how you order medica ons from each satellite loca on?

NASA currently u lizes Dr. First for prescribing. Many prescrip ons are filled in NASA’s local or satellite pharmacies, but NASA also provides the op on to send prescrip ons electronically to retail pharmacies in the local area. Several satellite pharmacies locally dispensed from clinic stock (e.g. sample dispensing).

a. Are they are using a specific pharmacy? The default is the onsite pharmacy (JSC Pharmacy), but prescribers have the ability to prescribe to external pharmacies through Dr. First (including controlled substances).

b. What program that pharmacy uses to process their orders? Frameworks LTC

c. Is it a direct connec on? It is not a direct connec on.

18) Does the EHR need to integrate into JSC’s current preferred pharmacy system or is the intent to replace it under a newly implemented EHR system? The current verbiage is slightly vague surrounding the capabili es needed (under the pharmacy sec on). Integra on into the JSC pharmacy system is not required.

19) The RFQ PWS document (A achment A page 7) describes the exis ng NASA infrastructure suppor ng the current electronic health record so ware that includes a SAN with both SSD and ered “slow” spindle storage. The replacement Electronic Health Record will require storage to migrate exis ng data for the new on‐premises centralized data repository.

a. Please clarify that this procurement will use the exis ng infrastructure iden fied in the PWS. Use of the current infrastructure, or the current infrastructure with minimal addi ons and/or upgrades is preferred.

b. Please clarify how NASA will procure updated on premises infrastructure separate from this RFQ to support data migra on and data backup for the new so ware. Any updates required will go through the normal NASA procurement process for IT infrastructure.

Security and Compliance

20) Does NASA require FedRAMP cer fica on for cloud‐hosted components, even if the primary system is on‐premises? NASA is not seeking a hybrid solu on with cloud‐ hosted components.

21) What authen ca on methods are mandatory for compliance (e.g., PIV, CAC, MFA, SAML, OAuth, OpenID)? Requirements for authen ca on methods are listed in A achment A: NASA EHR Replacement PWS.

22) Are there any addi onal data encryp on standards that must be followed beyond the standard FIPS 140‐2 encryp on? No.

23) Will NASA require specific cer fica ons or clearances for personnel working on the project, such as FedRAMP or addi onal security clearances? Any on‐site visits will be covered using guest access. Aside from standard HIPAA and Privacy Act requirements regarding medical data, no addi onal security clearances or cer fica ons are required.

24) Is the assump on correct that because this is on premise and not cloud hosted that the FedRAMP does not apply? FedRAMP does not apply.

25) Will this solu on go through an Authority to Operate (ATO) review and approval?

What is the planned meline to achieve ATO? ATO will be required, which includes comple on of security control ques ons from the vendor. The ATO process will begin a er the contract awarded and prior to the established go‐live date.

Implementa on & Support

26) Could you provide further details on the expected virtual assist implementa on outlined in PWS sec ons 2.2, 3.0, and sec on 7 Figure 5? The general concept and basic responsibili es of the virtual assist implementa on are explained in the listed PWS sec ons. Specific details of how NASA’s IT support contractor and the selected EHR vendor will interact to jointly implement the so ware will be addressed post award when the NASA and EHR vendor teams are able to openly communicate.

27) Will NASA provide any internal IT resources to assist with the implementa on?

NASA’s IT support contractor will substan ally assist with implementa on as described in the PWS, including sec ons 2.2, 3.0, and sec on 7 figure 5.

28) What level of training and knowledge transfer is expected for NASA’s staff? The expecta on is that the selected vendor will provide full training for the different clinical staff disciplines that interact with the EHR as well as maintenance, updates, and other sustaining ac vi es that will be performed by NASA’s IT support contractor over the period of performance of the contract.

29) Is it the intent of NASA to leverage their current investments, such as G5 and PowerPla orm, to gain efficiencies during the Contract’s total performance period?

Will NASA consider this approach in order to automate workflows, processes and provide mobile access? NASA is recep ve to any proposed implementa on provided those proposals demonstrate the case that they will support exis ng clinic needs and workflows while being technically sound, cost effec ve, and opera onally reasonable.

Demonstra on and Evalua on

30) Will NASA provide test data for the demonstra on of features listed in A achment B Demo Script.xlxs? NASA will not provide any specific test data for the demonstra on;

vendors should prepare their own as needed to address the proposed system’s capability to meet the elements iden fied in A achment B: Demo Script.

31) Will NASA provide specific test cases, or scenarios for the demonstra on, or should vendors prepare their own? NASA will not provide any specific test cases or scenarios for the demonstra on; vendors should prepare their own as needed to address the proposed system’s capability to meet the elements iden fied in A achment B: Demo Script.

32) Will the government consider addi onal evalua on criteria, such as system scalability, cybersecurity risk assessment, or ease of customiza on? refer to A achment D ‐ Evalua on Instruc ons and Criteria.

Pricing and Contractual Terms

33) Can you confirm whether pricing should be structured per‐user, per‐provider, or per‐ license /subscrip on basis? NASA does not have a preference for pricing structure.

Pricing informa on should be clearly explained, effec vely ar cula ng what is included in pricing, and account for the EHR user counts, types, and defini ons included in sec on 3.0 of A achment A: NASA EHR Replacement PWS. Vendors should provide their best pricing.

34) Can you confirm whether on‐site support during go‐live is required, or if remote support is acceptable? On‐site support during go live is required as iden fied in sec on 3.1.4.1.1 of A achment A: NASA EHR Replacement PWS.

Ques ons for Procurement

35) Is there an an cipated budget range for this procurement? This procurement is being competed under FAR part 13.

36) Will there be an opportunity for oral discussions or revisions a er the ini al proposal submission? There will be no opportunity for oral discussions or revisions a er the ini al quote submission.

37) Are there restric ons on subcontrac ng for implementa on and post‐go‐live support? There are no restric ons on a subcontrac ng plan for implementa on and post‐go‐live support.

38) Can the real me virtual demonstra on (A achment B) be conducted via any preferred pla orms (e.g., Zoom, Microso Teams)? No, real me virtual demonstra ons shall be conducted using Microso Teams.

39) Can you provide addi onal details on evalua on criteria weigh ng for Technical, Past Performance, and Price? For any ques ons regarding evalua on criteria please see A achment D – Evalua on Instruc ons and Criteria

40) Is there flexibility in contract structure (e.g., milestone‐based payments vs. fixed‐ price deliverables)? Please refer to the RFQ.

41) How should pricing be managed for op onal future enchancements or feature customiza ons beyond the base requirements? Please refer to the RFQ.

42) Background: Many companies are structured with mul ple divisions or mul ple legal en es that individually perform Prime Contracts but fall under a broader corporate umbrella. Recognizing such corporate structures exist across the industry, the procurement rules and numerous GAO decisions have made clear that procuring agencies may evaluate and credit an offeror with the past performance and corporate experience of sister subsidiary companies where the offeror’s proposal demonstrates that the resources of the sister subsidiary (e.g., workforce, management, facili es, or other resources) will be meaningfully contributed to contract performance. See GM–Bulltrack, B‐ 414591.6 (Comp. Gen. Oct. 30, 2018) (holding that an agency may properly a ribute the experience or past performance of a sister subsidiary), and Iyabak Construc on, LLC, B‐409196 (Comp. Gen. Feb.6, 2014) (holding that the agency failed to ar culate a ra onal basis for solicita on’s refusal to consider experience and past performance of sister subsidiaries).

a. Ques on: Would the Government please clarify that the Offeror may cite the prime contract past performance and corporate experience of a sister subsidiary company so long as the Offeror demonstrates how the resources of the sister subsidiary will meaningfully contribute to the performance of the opportunity? Refer to the RFQ A achment D – Evalua on Instruc on and Criteria.

b. Will the government allow offerors to reference relevant past performance from teammates and subcontractors? Refer to the RFQ A achment D –

Evalua on Instruc on and Criteria.

43) The Solicita on reads: “The contractor shall ensure a func onal system is ready for use and system go‐live is completed no later than 7/7/2026” will this date be adjusted based on any delays, including the scheduled award date? Refer to the RFQ.

44) Is NASA looking for a contractor to provide solu ons tailored to the outlined func ons, or is the requirement specifically for a contractor that already has a ready‐ made product? Please see A achment A – NASA EHR PWS.

45) Is working with a third‐party contractor something you’d consider for this requirement? Refer to the RFQ and A achment D – Evalua on Instruc on and

Criteria.

46) Can you please confirm if the es mated budget for this RFQ is $34M for the One (1) base year with four (4) one (1) year op ons or 34M for the One (1) base year. Please see A achment D – Evalua on instruc ons and Criteria Part 2.0. EVALUATION

CRITERIA.

47) Will JSC allow Offerors to propose a modern, cloud‐hosted solu on that meets your stringent security requirements? No.

File details come from the government source that posted it. Updated .